Industrial control systems
Industrial Fieldbus networks (Profibus, EtherCAT, etc.) are widely used in factories to relay information between field devices like sensors and actuators and the programmable logic controller which monitors the process. Nowadays, Fieldbus devices are embedded systems that include a microcontroller unit (MCU) that manages the bidirectional data flow for the device. It does this by executing a program that runs on an operating system (OS). Windows, Linux, and Android are general-purpose operating systems used in everyday devices like smartphones and laptops. However, these are designed to perform many different tasks well in situations where a slight delay is almost imperceptible to the user and has a limited impact on system performance.
However, in industrial environments, even minuscule delays in executing a program used to control a machine or robot (Figure 1) can have catastrophic results, meaning a different operating system is required – a real-time operating system (RTOS). Furthermore, as more autonomy is delegated to ‘edge’ devices, and they begin to perform tasks like machine learning and employ artificial intelligence, this is becoming increasingly important. This article presents some scenarios that demonstrate this requirement before discussing the differences between how a general-purpose OS and an RTOS operate. Finally, we offer an RTOS that is particularly suited for embedded systems employing an innovative software-based approach to implementing Fieldbus protocols.
Figure 1 A RTOS is critical for the deployment of intelligent edge devices
Where delay is intolerable
Real-time operating systems were designed for two general classes of applications: event response and closed-loop control. An example of a closed-loop control application is a computer numerical control (CNC) machine tool which receives real-time inputs from sensors monitoring the position of a cutting head. These inputs are then used to determine where to position the head next to produce the desired pattern. In this application, it is necessary for the system to continuously perform trajectory calculations while also updating the motor position at a rate of several kilohertz. Any delay between input and output will create an incorrect pattern resulting in a defective product being produced, the scrapping of raw materials, and the process having to be repeated (with the associated costs and delays).
On production lines where humans interact directly with robotic machinery, safety systems are designed to ensure that if an operator accidentally (or otherwise) comes into unauthorized contact with a machine, it will stop immediately. Any delay in shutting down the equipment could result in serious injury to the operator or even more tragic consequences. These examples illustrate the potential effects of delay in industrial embedded systems.
RTOS Terminology
RTOS are classified as either ‘hard’ or ‘soft.’ A RTOS that guarantees a maximum operating time is called ‘hard’, which is a requirement in critical safety applications. An RTOS that performs operations within a specific time window (in several hundred milliseconds) is called ‘soft’ and can be used in less critical applications. Determinism is the characteristic used to compare RTOS performance – an application is said to be deterministic if its timing can be guaranteed (within a certain margin of error). Jitter refers to the amount of error in the time taken to perform an operation (measured over repeated executions of a program or loop).
An RTOS is typically optimized to have low jitter when programmed correctly, which means that an operation requires almost the same amount of time each time it is executed. Real-time operating systems do this by providing programmers with a high degree of control over prioritizing tasks and checking to ensure that deadlines are met for essential operations.
Why a general-purpose OS is not up to the job
The problem with using a general-purpose OS (like Windows) is that they do not always strictly follow pre-programmed priorities. Since they are optimized to run various applications and processes simultaneously, they typically work to make sure that all tasks receive at least some processing time. As a result, lower priority tasks may, in some cases, have their priority increased above other higher priority tasks, ensuring that while each task receives some amount of run-time, the running program is not always followed as precisely as it should be. In contrast, an RTOS always adheres to pre-programmed priorities. For example, if a high-priority task is using 100% of the processing resources available, lower priority tasks cannot run until the higher priority task is complete. Therefore, designers of real-time systems must carefully program their applications with priorities in mind. In a typical real-time application, designers place time-critical code (e.g., event response or control code) in an area that has been assigned a very high priority. Less-important code (such as data logging or network communication) is included in a lower-priority area. Interrupt latency is measured as the time between a device generating an interrupt (which flags an operation waiting to be performed) and when it is serviced.
While a general-purpose OS may take a variable time duration to respond to a given interrupt, latency in an RTOS is time-bound, i.e., all interrupts will be serviced within a maximum time interval. Therefore, an RTOS processes data as it arrives, without buffering or refreshing, enabling faster, more accurate responses in systems with changing input environments. Typically, an RTOS with a microkernel architecture (kernel refers to the core) is designed to be small with separate functions that do not affect its primary operations.
What is RT-Kernel RTOS?
Unlike a traditional RTOS, RT-Kernel is a secure, small, efficient, and reliable embedded monolithic designed kernel created in-house by RT-Labs engineers to meet the most complex real-time demands. The kernel size depends on the microprocessor’s type and feature set, but a full-featured RTOS kernel can be as small as 13 kB (ARM, Thumb instruction set). The footprint can be reduced further (to a minimum of 6 kB) if not all RTOS kernel services are required. Ports are available for many processor families, including ARM, PowerPC, and Blackfin®. A port consists of an architecture layer for the processor and a board support package (BSP) for peripherals. RT-Kernel is ideal for use with embedded systems in industrial equipment and is suitable for automotive powertrain control applications.
Implementing Fieldbus in Software
RT-Kernel is the ideal accompaniment to embedded MCUs running a software-based implementation of Fieldbus. This innovative approach has been developed by RT-Labs and offers maximum flexibility when redesigning industrial equipment for different applications. This approach means that by simply modifying the code running on the MCU, a piece of equipment can interface with Fieldbus protocols. Also, when using hardware modules to provide the Fieldbus interface, this is not possible without performing a complete board redesign.
Conclusion
Fieldbus devices pass information between industrial processes operating in real-time. They do not have time to wait for an operating system to decide when it wishes to process this information and decide on the appropriate course of action, especially in circumstances where minuscule delays can have catastrophic consequences. Real-time operating systems like RT-Kernel ensure that critical operations receive the highest priority and are executed without delay, ensuring safety and high performance in Fieldbus-enabled industrial equipment.