Life moves in real time: your industrial embedded systems should too
By Andreas Karlsson – Product Manager Fieldbus Technology and Co-Founder of RT-Labs
Fieldbus industrial networks (Profibus, EtherCAT, etc.) are widely used in factories to transmit information between field devices such as sensors and actuators and the programmable logic controller that monitors the process. Fieldbus devices today are embedded systems that include a microcontroller unit (MCU) that manages the bi-directional data flow for the device. It does this by running 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, they are designed to perform many different tasks in situations where a slight delay is almost imperceptible to the user and has limited impact on system performance.
However, in industrial settings, even the smallest delays in the execution of a program used to control a machine or robot (Figure 1) can have catastrophic results, which means that a different operating system is required: an operating system on real time (RTOS). Also, as more autonomy is delegated to “edge” devices, they begin to perform tasks like machine learning and employ artificial intelligence, this becomes increasingly important. This article presents some scenarios that demonstrate this requirement before discussing the differences between running a general-purpose operating system and RTOS. Finally, we offer an RTOS that is especially suitable for embedded systems that use an innovative software-based approach to implement Fieldbus protocols.
Where the delay is intolerable
Real-time operating systems have been 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 that receives real-time inputs from sensors that monitor the position of a cutting head. These inputs are then used to determine where to place the head next to produce the desired pattern. In this application, it is necessary for the system to continuously perform trajectory calculations while updating the motor position at a rate of several KHz. Any delay between input and output will create an incorrect pattern that will result in the production of a defective product, the waste of raw materials, and the need to repeat the process (with 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, the machine 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 "hard" or "soft". An RTOS that guarantees maximum uptime is called 'hard', which is a requirement in safety critical 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 synchronization can be guaranteed (within a certain margin of error). Jitter refers to the amount of error in the time it takes to perform an operation (measured over repeated executions of a program or loop).
An RTOS is typically optimized to have low jitter when scheduled correctly, which means that an operation takes almost the same amount of time each time it is executed. Real-time operating systems do this by giving schedulers a high degree of control over task prioritization and checking to ensure deadlines for essential operations are met.
Why a general-purpose operating system isn't up to the job
The problem with using a general purpose operating system (such as Windows) is that they don't always strictly follow pre-programmed priorities. Since they are optimized for running multiple applications and processes simultaneously, they generally work to ensure that all tasks receive at least some processing time. As a result, lower priority tasks can, in some cases, increase their priority over other higher priority tasks, ensuring that while each task is given a certain amount of execution time, the running program is not always followed. as precisely as it should. By contrast, an RTOS always adheres to pre-programmed priorities. For example, if a high-priority task uses 100% of the available processing resources, lower-priority tasks cannot run until the higher-priority task completes. Therefore, real-time system designers must carefully schedule their applications with priorities in mind. In a typical real-time application, designers place time-critical code (for example, 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) falls into a lower priority area. Interrupt latency is measured as the time between when a device generates an interrupt (which marks an operation waiting to be performed) and when it is serviced.
While a general-purpose operating system may take a variable amount of time to respond to a given interrupt, latency in an RTOS is time limited, meaning all interrupts will be serviced within a maximum time interval. Therefore, an RTOS processes data as it arrives, without buffering or updating, enabling faster and more accurate responses in systems with changing input environments. Typically, an RTOS with a microkernel architecture (kernel refers to the kernel) is designed to be small with separate functions that do not affect its core operations.
What is RT-Kernel RTOS?
Unlike a traditional RTOS, RT-Kernel is a secure, small, efficient and reliable embedded monolithic design kernel built in-house by RT-Labs engineers to meet the most complex real-time demands. The size of the kernel depends on the microprocessor 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 further reduced (down to a minimum of 6 kB) if all the RTOS kernel services are not required. Ports are available for many families of processors, 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 complement 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 computer can interface with Fieldbus protocols. Also, when hardware modules are used to provide the Fieldbus interface, this is not possible without a complete redesign of the board.
Conclusion
Fieldbus devices pass information between industrial processes that operate in real time. They don't have time to wait for an operating system to decide when it wants to process this information and decide on the appropriate course of action, especially in circumstances where minute delays can have catastrophic consequences. Real-time operating systems like RT-Kernel ensure that critical operations are given top priority and run without delay, ensuring safety and high performance on Fieldbus-enabled industrial equipment.
