PLC and SCADA programming

What we do for the client's line

We write control programs for industrial controllers and SCADA systems that run the customer's already-installed equipment: conveyors, presses, dosers, pump groups and furnaces. The machines and drives themselves cut, press and move the product physically, while our area of responsibility is the logic of their operation, the data exchange and the visualization on the operator panels. As part of the service we analyze the line's process flow, describe the controller's inputs and outputs, program the start and stop sequences, the interlocks and the alarm handling. Separately we build the SCADA project: mimic diagrams, trends, event and alarm logs, operator access rights. In the end the customer gets a working program flashed into their PLC and a configured supervisory system, not new hardware.

How the PLC and SCADA combination works

A programmable logic controller cyclically polls the sensors, runs the control logic and issues commands to the actuators within milliseconds. This cycle repeats continuously, so the reaction to a limit switch being pressed or a pressure sensor tripping comes out deterministic and predictable. SCADA sits a level above: it pulls data from the controllers over industrial protocols like Modbus, Profinet or OPC UA and shows the operator the line's state in real time. PLC programming is responsible for fast decisions on the spot, while SCADA is for monitoring, archiving and manual intervention where that's permissible. We design both parts so the controller keeps control of the line even on loss of communication with the upper level.

Where industrial controllers came from

The first programmable logic controller appeared in 1969: Dick Morley's team at the engineering firm Bedford Associates made a device on commission from the General Motors Hydramatic division, which in 1968 was looking for a replacement for cabinets of relay automation. The project got the designation 084 because it was the company's eighty-fourth development, and the controller itself was named Modicon — short for modular digital controller. General Motors received the first batch in November 1969, and this replaced hard-wired relay schemes with reprogrammable logic. A relay panel had to be physically rewired when the process changed, whereas a controller just needs reprogramming. The entire industry we work in began with this device, as we prepare programs for controllers on customers' operating lines.

Why software and setup are critical

A controller on its own is neutral: the same PLC can run a line correctly or drive it into an emergency — everything is decided by the embedded logic. An error in an interlock condition means the press will come down with the guard open, while a missed emergency scenario will leave a pump running dry. That's why we work out not only the normal cycle but also the behavior on a sensor failure, a loss of communication, a press of the emergency-stop mushroom button and a power sag. The precision of setting the timers, setpoints and the order of shutting down mechanisms directly affects scrap, wear of the customer's equipment and personnel safety. Physically the cutting and pressing is done by the client's equipment, but exactly when and under what conditions this happens is determined by the control program.

Our stack and languages

The base tool for controllers from a wide range of manufacturers is Codesys, an environment compliant with the IEC 61131-3 standard, in which we write both clear relay logic and structured code. For Siemens equipment we work in TIA Portal, which combines programming of S7-series PLCs, network configuration and operator-panel development in a single project. Ladder logic, that is the relay-diagram language, we use for interlocks and discrete logic, where a visual scheme is closer to the customer's electricians and commissioning engineers. Structured text, a Pascal-like text language, we take for calculations, array processing, recipes and algorithms that would be unwieldy in relay form. The choice of language is dictated by the task: part of the program stays relay-based for readability during maintenance, part is written in text for compactness and control over computation.

When the languages and standards appeared

The unified industry standard for controller programming languages — IEC 61131-3 — was first published in December 1993 and majorly revised in 2013; it's exactly the one that established relay diagrams and structured text as part of a common set. The Codesys environment traces its history to 1994, when Dieter Hess and Manfred Werner founded the company 3S-Smart Software Solutions and released the first version to this standard. Siemens presented TIA Portal later, in November 2010, bringing previously scattered packages for controllers and panels into a single engineering environment. The relay-logic languages themselves go back to electrical relay schemes from the pre-controller era, while the text languages came later along with standardization. We keep tools of various release years in our work, because customers have equipment of both recent and older generations.

Why the task can be given to us

The combined experience of our development team in IT exceeds 45 years, and we approach control programs as an engineering system rather than a set of scattered schemes. Before the production launch we verify the logic in simulation and on controller emulators, run the emergency scenarios and commissioning modes, so the customer's line doesn't become a test bench. We document the inputs, outputs and interlock logic so that the customer's commissioning engineers and service can understand the project without us. We deliver PLC programming and SCADA setup with a description of the setpoints, alarms and the operator's order of actions, not as a closed box. The production capacity and equipment stay with the client — we're responsible for making their machines work by verified and predictable logic.