Real-Time
According to the DIN 44300 standard, real-time, or rather real-time operation, is defined as follows:
"Real-time operation is an operating mode of a computing system in which programs for processing data are continuously operational in such a way that the processing results are available within a specified period of time."
In other words, the output values of an application program (calculated based on the inner state and input values) are made available within a defined and guaranteed time. This defined time is also referred to as cycle time.
The application program itself can consist of several program blocks, which in turn call other programs or function blocks etc. (see also IEC 61131-3 standard). The program blocks can be assigned to real-time tasks, which in turn call them with a cycle time to be defined and a defined priority.
TwinCAT 3 Real-Time is a real-time extension that can be used in the current TwinCAT 3.1 version under Microsoft Windows operating systems from Windows 7 and under TwinCAT/BSD. TwinCAT 3 Real-Time supports the following features in order to meet the requirements described for the control of industrial processes:
- Real-time capable scheduling
- Parallel execution of processes
- Direct hardware access
In addition, TwinCAT 3 Real-Time also offers multi-core support to meet the ever-increasing demands for high-performance and flexible/expandable control platforms. The available cores can either be used exclusively for TwinCAT or shared with Windows. In the following sections, the cores are therefore referred to as "isolated" or "shared.
Real-time capable scheduling
TwinCAT 3 Real-Time works with the double-tick method. This means that both switching to real-time mode and switching back is triggered by an interrupt. The interrupt when switching to the real-time mode also starts the scheduling at the same time. After an adjustable period of time, at the latest after 90% of the set cycle time, TwinCAT switches back to "shared" cores in non-real-time mode, so that the guest operating system has sufficient computing time available to comply with the response times required for hardware functions etc. The isolated cores are an exception.
Scheduling refers to the (system) process that determines the processing order and the processing time of the individual tasks, based on the defined cycle time and the defined priority. Strict adherence to the processing time ensures that the real-time compliance described above is guaranteed.
Triggered by a synchronous basic tick on all real-time kernels, the scheduling for each real-time kernel is calculated independently in TwinCAT 3 Real-Time. This guarantees that real-time tasks running on different cores do not interfere with each other. Unless this has been explicitly programmed in the user program by using interlocks.
Scheduling in which the priority of a task is derived from its cycle time is also known as rate-monotonic scheduling. The TwinCAT 3 Real-Time automatically activates the "Automatic Priority Management" option. Since this is not always the best solution for every application, the priorities can be adjusted manually.
Exemplary representation of the call of a PLC task
The figure shows the call of a PLC task. After the real-time tick has occurred, the PLC task is called by the scheduler. This makes the current input values available to the PLC application (input update), followed by processing of the application program (cycle update). Finally the results are written to the outputs (output update). Once this has been completed, the device switches to non-real-time mode (double-tick). As shown in the figure, the execution time of the user program may vary depending on which code is executed based on the internal state of the program. Thus the time when the outputs are written also varies. Depending on which task a bus system is driven, this can cause the sending of the bus telegrams to vary to the same extent.
Sample call of a task with "I/O at task start“
By using the "I/O at task start" option, the processing order within a task can be changed so that after reading the inputs, the outputs (of the previous cycle) are written directly before the application program is executed. Although the outputs are not written until the next cycle, this setting has the advantage that the time at which the outputs are written to the process/bus is exactly the same in each cycle.
Preemptive multitasking
Preemptive multitasking means that the current state of a process (the CPU and floating-point registers) is saved in the event of an interrupt (e.g. by higher-priority processes), and the current process is paused. If this happens, the scheduler determines the (new) process to be executed, based on the task priorities. Once the process to be interrupted is complete, the process context is restored and the "old" process continues.
Direct hardware access
In order to achieve deterministic (reproducible) real-time behavior, TwinCAT 3 Real-Time requires direct hardware access. For this to be possible, TwinCAT 3 Real-Time must be executed in Windows kernel mode. This makes it possible, among other things, for TwinCAT Real-Time to access the network ports directly and send and receive real-time Ethernet telegrams (e.g. EtherCAT).
Schematic representation of the TwinCAT 3 runtime environment
The following figure illustrates the structure of the TwinCAT 3.1 runtime environment in relation to scheduling. The TwinCAT 3 runtime environment enables user modules to be executed in real-time. An essential part of the TwinCAT 3 runtime environment therefore is the real-time driver, which is executed on the cores that are activated for TwinCAT and handles the scheduling there. The latter takes place independently on the individual cores.
Isolated cores
As described under real-time scheduling, TwinCAT uses a double-tick procedure to switch back to non-real-time mode at a specified point in time. When switching between real-time mode and non-real-time mode, the preceding process state is restored, as described under Preemptive multitasking. The restoration takes some time, depending on how intensively the real-time and non-real-time programs use the memory and in particular the cache. In order to eliminate these temporal effects, TwinCAT 3.1 Real-Time allows cores to be isolated from the guest operating system. This eliminates the need to switch back, resulting in more computing time for the real-time user program and better real-time quality (less jitter) by avoiding the time effects associated with restoring the "old" process state.
Behavior when the cycle time is exceeded
If the defined cycle time of a task is exceeded, processing of the "old" cycle continues in the next cycle. In addition, the task exceed counter is incremented. Once processing of the old / previous cycle is complete, the system immediately tries to start processing the tasks of the current cycle. If this is completed within the current cycle, further processing is carried out as shown above.
If the second cycle that follows directly is also exceeded (in this case it is irrelevant whether the system is still processing the first cycle or whether the second cycle has commenced), the current processing task is completed, and processing of the next task does not commence until the next possible scheduled cycle start. This means that several cycles may be lost. The exceed counter is incremented accordingly.
Differences in execution between PLC and "TcCom" runtime modules
Processing of a TwinCAT task, in relation to the execution of runtime modules, is based on the following sequence:
- Copying of the inputs to the process images of the runtime modules called by the task.
- Executing the modules according to the sort order (in ascending order).
- Output update, which makes the outputs available accordingly. If this task drives an EtherCAT fieldbus, the frame is provided and sent during the output process image.
- Post-cycle update: This is used, among other things, to trigger a cycle update when the "I/O at task start" option is active.
If runtime modules are added to a task, they "log on" to the respective calls of the task. The only exceptions are PLC runtime modules. For reasons of compatibility with TwinCAT 2, the PLC runtime modules directly update the inputs and outputs. The difference between the two behaviors is shown in the following figure:
Four runtime modules can be seen in each case. Standard TwinCAT 3 runtime modules log on to the corresponding method calls of the task. This means that all input updates (yellow) and output updates (red) are triggered by the task and take place one after the other directly at the start or end of task processing. If two of these modules communicate with each other via a mapping, they do not receive the current values until the next cycle.
The PLC runtime modules independently perform an input and output update. If two PLC runtimes communicate with each other, the runtime module that is executed second directly receives the current values from the first runtime module. Thus, there is no cycle offset in the communication direction from first runtime module to second runtime module, but there such an offset does exist in the other direction.