x86 in production: high end industrial controllers, pascal and viruses
There is such a not very correct term: PC based industrial automation. I think that it is not entirely accurate, since no one, of course, connects the machine to an ordinary personal computer. And then suddenly freezes, and the machine will cut off something unnecessary . But there is a rational grain in this term - for many years among the control devices of industrial automation there are devices resembling PCs.
Reminding, of course, not outwardly.
Like in your laptop, the controller can have a Core i5 processor, ordinary DRAM (usually only with ECC), an SSD disk, and regular Ethernet. The boot process is no different either - the BIOS loads the operating system. As a rule, OSes - RTOS. However, sometimes even Windows. And it is not always Windows Embedded Compact (formerly CE). Even Windows Embedded 7 is used, and this is a full seven. (Linux is also found)
')
The main classes of computational problems solved in the process of the production line - CNC and SCADA .
In the case of CAD and SCADA, the questions whether x86 performance is necessary, and whether this platform is sufficiently reliable, have not been worth it for a long time.
CNC is a little more complicated. To manage many industrial devices do not need a powerful number shredder, but the requirements for reliability and guaranteed response time may exceed the capabilities of x86. Enough microcontroller or the simplest PLC .
G-code is typically used for CNC programming, and x86 computational power is not required. If the machine is more complex, PLC is used. How is the PLC programmed? There is a standard IEC61131-3. It defines the programming methods: “assembler type” IL, as well as graphical diagrams based on Petri nets, block diagrams or ladder logic.
Of course, on relay logic, asm or Petri nets it is very difficult to write a program so complex that there is not enough computing power of the microcontroller for its execution. But thenpascal comes to the rescue ! Another PLC code representation defined in IEC61131-3.
Here is the code in this obscure language:
Nothing like? I also learned in computer science lessons 20 years ago that if you equip a programmer with Pascal and structured programming, the processor speed is not too high.
In some cases, the faster the PLC processor, the better: there are applications where measurements from dozens of sensors are used as input data for a fairly complex calculation, and the data comes in at dozens of kilohertz. That is, in tens of microseconds, they must be taken, driven through a complex floating-point algorithm, and commands must be given. Only the latest generation x86 processor with a bunch of gigaflops inside can handle it.
In addition, it is convenient if the HMI (that is, the GUI translated to general IT) will spin on the same piece of hardware as the PLC program. Well, since we started such workload consolidation, even fieldbus communications are also controlled by the same piece of hardware, which is really there! The blessing of cores in a single processor now happens a lot, creating multi-threaded real-time applications is difficult, and virtualization provides good isolation (if you don’t forget about the nuances associated with the shared cache and memory controller)
In the last paragraph, I used a new word - fieldbus . The evolution of industrial data transmission systems is also a good example of how technology comes from IT to supplant specialized dinosaurs. Modern fieldbus networks Profinet, Ethercat, Sercos III are based on Ethernet, and work with regular network cards made by Intel and, probably, other vendors.
What prevents the full transition to x86? Cautious lawmakersare afraid of an explosion of nuclear power plants from bluskrin require that in particularly important places PLC meet certain safety standards . There are OSes that meet these standards - for example, VxWorks, QNX, etc. There is even a virtual machine - Windriver Hypervisor is also SIL3 / SIL4 certified.
The issue is certification of iron. Of course, the corresponding certificate is easier to get on a simple microcontroller that has been produced unchanged for years than on a complex x86 processor and chipset, the generations of which change every year. But this does not prevent Intel processors from being used in many popular PLCs from different manufacturers .
But what about real time? We need hard real time, soft real time will not go, that's why: even if we are on the deadline in 99.99999% of cases, the remaining 0.00001% can crash on average several times a day. Of course, we have to have a safety function in this case, which will de-energize everything, but this is often not fun to do. I have heard many times the opinion that a complex OOO processor and Real Time are incompatible concepts. After all, the microcontroller can look at the code, and up to the tact know how long it will take to execute.
So? So, not so. Watch your hands! For example, suppose we have a cycle of 100 microseconds. Let it begin with an interrupt. To the interrupt handler, the control can go through 2, and maybe (at worst) after 8 microseconds. Let another 10-15 microseconds spend reading the information received. And then another 50-75 microseconds will process it (we have a terribly unpredictable superscalar processor with an even more unpredictable cache!). Total spend from 62 to 98 microseconds. Terrible jitter; creepy, not adapted for hard real time x86! But in the worst case (which occurs once every few hours with a frequency of 10 kilohertz), we still get out in 100 microseconds.
But what is 50 microseconds of processing the data on the core i3? This is 100,000 ticks, or about 120000 instructions with IPC = 1.2 not at all outstanding. Suppose we also have a not very efficient PLC compiler that generates on average 5 x86 instructions for each IL instruction. That is, for the cycle, we executed 24,000 instructions of IEC61131-3 IL.
And if you imagine the same thing on a very bright, but not x86 PLC? There is no jitter to interrupt or read data, and you can tell in advance exactly how long it will take to execute 24,000 IL instructions. Let's look in the documentation of the manufacturer of the PLC from the big three (AB, Siemens, Mitsubishi automation) How long does one IL instruction execute? 9.5 nanoseconds 24,000 instructions will execute in 228 microseconds. PM
If it is objected that 24,000 processing instructions per cycle are too many, then I will answer:
Are you for me, or for a bear? . Clients talked about modern machines, the controller of which each cycle calculates the physical model of dozens of actuators, based on the readings of dozens of sensors. That is, it is engaged in the numerical solution of the system of equations every clock cycle, which requires more and more FP performance.
All of the above related to the performance of a single core. But we have a lot of them now. And we can use them to consolidate several functions or PLCs on a single device, or to parallelize the control program. Latest RTOS versions such as VxWorks, Twincat, etc. keep hard real time guarantees with multithreading support. But this is at the level of the OS kernel, hypervisor and libraries. And at the application level, using the usual primitives of internuclear synchronization, it is very easy to break real time. Unfortunately, the general recipe for dealing with this problem is unknown to me.
I wrote above that multithreaded programming and the use of virtualization are becoming popular in the industry. That is, there is a lag behind IT years in a few. Maybe in a few more years they will start introducing something like a private cloud? And then besides Stuxnet, which everyone has heard about, but no one has seen, will it be necessary to fight malware that can break industrial robots and force automated chemical production to synthesize interesting substances instead of the necessary ones?
Reminding, of course, not outwardly.Like in your laptop, the controller can have a Core i5 processor, ordinary DRAM (usually only with ECC), an SSD disk, and regular Ethernet. The boot process is no different either - the BIOS loads the operating system. As a rule, OSes - RTOS. However, sometimes even Windows. And it is not always Windows Embedded Compact (formerly CE). Even Windows Embedded 7 is used, and this is a full seven. (Linux is also found)
')
The main classes of computational problems solved in the process of the production line - CNC and SCADA .
In the case of CAD and SCADA, the questions whether x86 performance is necessary, and whether this platform is sufficiently reliable, have not been worth it for a long time.
CNC is a little more complicated. To manage many industrial devices do not need a powerful number shredder, but the requirements for reliability and guaranteed response time may exceed the capabilities of x86. Enough microcontroller or the simplest PLC .
G-code is typically used for CNC programming, and x86 computational power is not required. If the machine is more complex, PLC is used. How is the PLC programmed? There is a standard IEC61131-3. It defines the programming methods: “assembler type” IL, as well as graphical diagrams based on Petri nets, block diagrams or ladder logic.
Of course, on relay logic, asm or Petri nets it is very difficult to write a program so complex that there is not enough computing power of the microcontroller for its execution. But then
Here is the code in this obscure language:
Var
arr1: ARRAY [1..4,1..4] OF REAL;
arr2: ARRAY [1..4,1..4] OF REAL;
arr3: ARRAY [1..4,1..4] OF REAL;
i: int;
j: int;
k: int;
END_VAR
FOR i: = 1 TO 4 DO
FOR j: = 1 TO 4 DO
arr3 [i, j]: = 0.0;
FOR k: = 1 TO 4 DO
arr3 [i, j]: = arr3 [i, j] + arr1 [i, k] * arr2 [k, j];
END_FOR
END_FOR
END_FOR
Nothing like? I also learned in computer science lessons 20 years ago that if you equip a programmer with Pascal and structured programming, the processor speed is not too high.
In some cases, the faster the PLC processor, the better: there are applications where measurements from dozens of sensors are used as input data for a fairly complex calculation, and the data comes in at dozens of kilohertz. That is, in tens of microseconds, they must be taken, driven through a complex floating-point algorithm, and commands must be given. Only the latest generation x86 processor with a bunch of gigaflops inside can handle it.
In addition, it is convenient if the HMI (that is, the GUI translated to general IT) will spin on the same piece of hardware as the PLC program. Well, since we started such workload consolidation, even fieldbus communications are also controlled by the same piece of hardware, which is really there! The blessing of cores in a single processor now happens a lot, creating multi-threaded real-time applications is difficult, and virtualization provides good isolation (if you don’t forget about the nuances associated with the shared cache and memory controller)
In the last paragraph, I used a new word - fieldbus . The evolution of industrial data transmission systems is also a good example of how technology comes from IT to supplant specialized dinosaurs. Modern fieldbus networks Profinet, Ethercat, Sercos III are based on Ethernet, and work with regular network cards made by Intel and, probably, other vendors.
What prevents the full transition to x86? Cautious lawmakers
The issue is certification of iron. Of course, the corresponding certificate is easier to get on a simple microcontroller that has been produced unchanged for years than on a complex x86 processor and chipset, the generations of which change every year. But this does not prevent Intel processors from being used in many popular PLCs from different manufacturers .
But what about real time? We need hard real time, soft real time will not go, that's why: even if we are on the deadline in 99.99999% of cases, the remaining 0.00001% can crash on average several times a day. Of course, we have to have a safety function in this case, which will de-energize everything, but this is often not fun to do. I have heard many times the opinion that a complex OOO processor and Real Time are incompatible concepts. After all, the microcontroller can look at the code, and up to the tact know how long it will take to execute.
So? So, not so. Watch your hands! For example, suppose we have a cycle of 100 microseconds. Let it begin with an interrupt. To the interrupt handler, the control can go through 2, and maybe (at worst) after 8 microseconds. Let another 10-15 microseconds spend reading the information received. And then another 50-75 microseconds will process it (we have a terribly unpredictable superscalar processor with an even more unpredictable cache!). Total spend from 62 to 98 microseconds. Terrible jitter; creepy, not adapted for hard real time x86! But in the worst case (which occurs once every few hours with a frequency of 10 kilohertz), we still get out in 100 microseconds.
But what is 50 microseconds of processing the data on the core i3? This is 100,000 ticks, or about 120000 instructions with IPC = 1.2 not at all outstanding. Suppose we also have a not very efficient PLC compiler that generates on average 5 x86 instructions for each IL instruction. That is, for the cycle, we executed 24,000 instructions of IEC61131-3 IL.
And if you imagine the same thing on a very bright, but not x86 PLC? There is no jitter to interrupt or read data, and you can tell in advance exactly how long it will take to execute 24,000 IL instructions. Let's look in the documentation of the manufacturer of the PLC from the big three (AB, Siemens, Mitsubishi automation) How long does one IL instruction execute? 9.5 nanoseconds 24,000 instructions will execute in 228 microseconds. PM
If it is objected that 24,000 processing instructions per cycle are too many, then I will answer:
All of the above related to the performance of a single core. But we have a lot of them now. And we can use them to consolidate several functions or PLCs on a single device, or to parallelize the control program. Latest RTOS versions such as VxWorks, Twincat, etc. keep hard real time guarantees with multithreading support. But this is at the level of the OS kernel, hypervisor and libraries. And at the application level, using the usual primitives of internuclear synchronization, it is very easy to break real time. Unfortunately, the general recipe for dealing with this problem is unknown to me.
I wrote above that multithreaded programming and the use of virtualization are becoming popular in the industry. That is, there is a lag behind IT years in a few. Maybe in a few more years they will start introducing something like a private cloud? And then besides Stuxnet, which everyone has heard about, but no one has seen, will it be necessary to fight malware that can break industrial robots and force automated chemical production to synthesize interesting substances instead of the necessary ones?
Source: https://habr.com/ru/post/148090/
All Articles