"The biggest challenges on the path to Industry 4.0 lie between the automation and IT worlds," explains Peter Brügger, Managing Director of iniNet Solutions. "Two worlds collide - and this problem needs to be solved." With its new hardware and software architecture, the company aims to merge the two worlds into one productive unit.

According to Peter Brügger, the production processes must be programmed exclusively at the automation level in order to avoid redundancies: "The control level determines which orders are to be processed and which products are to be manufactured. It also issues the requirements for production equipment, production times, parts lists, test protocols and much more. This also means that the control level determines what is to be produced - but how it is to be produced is determined by the machine."

At the production level, the approach is therefore as object-oriented as possible, in the sense of focusing on the machine as a mechatronic unit. "The respective production and control units therefore retrieve the orders from the control level, communicate with the subsystems required for product manufacturing, allocate them and provide them with the link to the specifications from the control level," explains Peter Brügger. Material requirements and consumption are reported to a logistics system and the production status is sent back to the control level. Each object deals exclusively with its own task. "This means that not only the I/O level for classic automation is programmed for each control system, but also the communication level for integration into the company's Industry 4.0 network." For each product that is then manufactured, programming is carried out as 'classically' as possible in IEC 61131 at the I/O level of the automation systems.

The SCADA software 'SpiderControl SCADA Server', which is available for various operating systems, forms the basis for setting up the control unit. If the SCADA server is integrated in the PLC, it can communicate directly with the local PLC application or with remote automation components. The 'SpiderPLC' programming tool is integrated into the SCADA server, which enables programming with a function block diagram in accordance with IEC 61131 via the browser. The special feature: "The function blocks not only execute simple logic, but can also call up functions from external scripts in the most important current high-level languages, including JavaScript, i.e. NodeJS and NodeRED, PHP, Python and .NET," says Peter Brügger. A runtime for executing the required script languages is also installed in the PLC for this purpose. The runtime is started in the background and waits to receive a request to execute a function from SpiderPLC.

This makes it possible to link the PLC code directly with the data and functions from the control level. To connect to the IT level, the computer scientists can provide the code for communication with their applications in the high-level language of their choice. This code is encapsulated via a function block and integrated into the automation.

"Common processes can therefore be easily implemented on the basis of the SpiderPLC/SCADA infrastructure," concludes Peter Brügger. "The decisive advantage is that the programming of Industry 4.0 applications can easily be carried out by the company's own permanent staff." The classic problem of the rift between the automation level and IT is also elegantly solved because both sides can remain in their technical domains: "IT provides all relevant interfaces in a programming language that it is familiar with. The automation level uses these as function modules in function block diagram programming, which has access to all automation components via the SCADA and its drivers."