Application Engineering / Control Software Engineering
Control software engineering is the core of our business. Once the system boundaries of the system are identified, the next step is to prepare the control software to operate all equipment present in the system. The system could be small like just a bare fuel controller interfacing to a BOP/DCS/PLC sequencer or it can be very extensive to also include other site equipment.
Any type of control system can be engineered when all appropriate functional specifications are available for use. However, based on our experience we know what features are required for a gas or steam turbine package. This allows us to also act as a partner should information be limited or not available in situations of a system upgrade or an installation bought for upgrade on the market.
What we see in the field is that during an upgrade, the “old” software is just ported to a new hardware platform while existing system problems are not addressed. We always aim to modernize the software if possible to bring the system reliability up to modern standards. A good example is adding individual ESD items to the ESD latch and the HMI for visibility. In old systems there usually is just a single ESD message that can contain a huge number of individual ESD causes. This makes troubleshooting difficult and thus has a negative impact on the unit downtime. Another example, an alarm indicating “Signal I/O fault” does not narrow down to the level of I/O board, channel or even ma out-of-range problems. In our systems this granularity comes as a standard.
Our design philosophy – How ?
Depending on the application there typically are functional modules that can be identified in the system at site. These could be regarded as modules for mineral oil, synthetic oil, ventilation, gas fuel, liquid fuel, fuel forwarding, steam injection, water injection, etc. Between systems these usually are quite similar with redundant pumps and a DC backup for example. In addition, logic modules for the fuel control and system sequencing are required. As a result, the typical software modules we have created are :
- Main operating sequence including timers and settings.
- Alarm bus handling including first-out processing.
- Hardware definition and signal forcing.
- Gas turbine instrumentation (type specific).
- Fuel control.
- Air flow handling.
- Steam turbine instrumentation (type specific).
- Extraction / Admission logic.
- Steam maps.
- Enclosure and ventilation.
- Lubrication oil skids.
- Gas and liquid fuel systems.
- Steam injection systems.
- Liquid fuel forwarding system.
- Generator or surge control details.
- Process gas control loops.
- Datalog facility for system fault finding.
- HMI / DCS / BOP interfacing.
For the above, we use dedicated software modules that are re-used in other applications. As a result, all new projects will have a carry-over from previous experience. Using this modular approach also results in a very clear
structure in the software where all related logic is grouped together. An example of the modular approach is the package ventilation. All packages have an enclosure ventilation system, we have a dedicated piece of logic to match the related functionality. Although site specific details will differ (timers, level settings, etc.), the overall concept of the function remains the same and still can fit inside this specific software module.
Our design philosophy – Why ?
Typically the software we encounter tends to be an unclear collection of nonrelated blocks and ladders that are difficult to debug by anyone else but the original software engineer – Spaghetti logic. This approach makes it impossible for anyone to easily navigate and understand the software. In addition, it prevents any database tooling from interacting with the software.
We use database tooling to automate creation of items like modbus/OPC lists and event bus structures. By automating these actions, the generated data that is typically provided to third parties such as a DCS vendor are always 100% accurate and allow for precise revision control. The combination of the modular software approach and the use of database tools provide a very rugged way of software engineering that will reduce engineering time and commissioning effort. By utilizing the database tools, also the HMI interface is created. Each of the software modules connects to the HMI on a library basis, again improving engineering quality.
Supported systems
Based on our original Woodward background, we have always specialized in Woodward equipment. However, over time we did encounter other systems such as the GE MK5, MK6, Fanuc, Siemens S7, Allan Bradley, etc. In these cases we would usually be limited to troubleshooting existing systems rather then creating a new system from the ground up. Note that in our network we also have connections familiar with these systems if required.
Woodward hardware we regularly encounter includes :
- Netcon
- Micronet
- Micronet Plus
- Atlas (SC, PC, II)
- MSM (safety system)