SCADA, DCS & Control Application Development

What does SCADA software development for machine builders cover?

SCADA software development for machine builders covers the application layer and the middleware above a machine's real-time control.

That means supervisory logic, the diagnostics that explain what went wrong, the HMI through which both are reached, and the data collection that feeds the systems above. DCS work runs alongside it on this page and achieves a different goal. SCADA supervises and reports on a process that a controller runs. A DCS distributes the control itself across the process, and what we build there is a component inside it, while you own the architecture. The engagement is usually one of these shapes:

• A supervisory application for a machine. SCADA software that ships as part of the product instead of being specified at the site.
• A component inside a distributed architecture. DCS system design and component development, where you own the architecture and need one part of it built.
• Soft-PLC work. IEC 61131-3 soft-PLC development, or soft-PLC runtime integration and migration where a runtime targets a different platform or is embedded into your own product, including running it as the controller on a PROFIBUS, PROFINET, EtherCAT or EtherNet/IP network.
• One application, several PLC brands. Multi-vendor PLC integration for machine builders, which is nearly always a customer-driven requirement.
• Diagnostics and HMI. Machine diagnostics and monitoring application development, and industrial HMI application development, usually together.
• The data collection layer. Data collection application development where the machine has to feed an MES, an ERP or a historian above it. The edge-to-cloud half of that path is described in industrial IoT.

The data model is the part most often underestimated. A tag list assembled during commissioning works until someone adds a machine variant, integrates an MES, or has to explain why two screens disagree. Designing the model at the start keeps the next variant an extension instead of a rebuild.

We do not commission control systems on a plant floor. The application layer inside your machine or your product is ours to build, and we integrate and test it with your engineers onshore and remotely.

How do you design one supervisory application to work across several PLC brands?

We treat the controller interface as a normalised hand-off boundary, so the brand-specific part is an adapter.

The application above it does not change. A machine builder selling into several plants meets several controller estates, and the alternative is a maintained variant per brand. The abstraction is usually attempted late, after a few variants are already integrated and have drifted apart. Designed in from the start it is a bounded design exercise. Retrofitted, it first requires working out what each variant actually does, which is the time-consuming part.

Where does safety application software fit?

Safety application software sits alongside machine control, developed against the functional-safety standards the machine has to meet, such as IEC 61508 and IEC 62061.

• Developed to the functional-safety standard. Safety application software follows the same engineering discipline as machine control, plus what the standard adds for the target safety integrity level: a defined safety lifecycle, independent verification and validation, and documentation for each phase.
• Evidence built from the start. That evidence is normally built against a certification body’s guidance from the start of the project rather than assembled at the end. Bodies such as TÜV SÜD offer paid assessment support during development, which is the usual pattern and is what keeps late deviations small. We develop the software and prepare the evidence; we do not issue the certificate.
• Safety over the network is part of network design. A safety layer proving itself end to end over an ordinary control network is engineered as part of the network design, and sits with real-time Ethernet and device and network integration.

Where does a control application for a process transmitter fit?

The control software covers the control application that consumes a transmitter's measurement and acts on it.

Because a process transmitter project splits across three of our service pages, the transmitter’s own communication stack is covered in fieldbus and device networks, and the device itself, meaning the board, sensor front end, firmware and enclosure, is covered in embedded systems. Most transmitter projects need at least two of the three.

What do you cover as part of the control application development service?

We cover development of the control software and middleware and support what we built; we do not cover plant-scale commissioning.

• What we cover. We design, build, integrate and test the application, and we support what we built for as long as the support agreement runs. That includes the data model, the runtime work, the diagnostics and the HMI, and it includes working alongside your engineers through integration and acceptance.
• What we do not. Plant-scale commissioning, floor maintenance, or generalist management consultancy around an automation estate. Where a project needs a plant-side integrator, we say so at the proposal stage. On multi-vendor work we build a proof of concept, turn it into a deployable solution, and hand it to the party that commissions it, with onshore integration support where it is needed.