UST034

89 Real-time operating systems | Focus the hardware of a multicore chip has to deal with synchronisation issues between different tasks reading and writing data. The state of a shared cache might be affected by an erroneous application, which has a serious impact on the performance of a safety-critical partition. Cache handling in an RTOS is implemented in a hardware-specific component, called the Platform Support Package. This provides enough flexibility to allow the partitioning of shared caches, for example by assigning different parts of the cache to individual partitions. In order to be prepared for worst-case scenarios, an RTOS can also monitor the cache bandwidth, to shut down erroneous applications. Another source of interference is the main memory bus. Although the memory areas are protected against each other through the partitioning, access to the bus takes a certain amount of time. Intensive use of the memory bus by one application is at the expense of applications running in parallel. Contention can also occur when applications executing on different cores are entering the kernel space at the same time, potentially accessing the same data structures. Traditionally, access to the entire kernel memory is protected by a global lock, allowing only one core at a time to execute operating system services. Fine granular locking significantly reduces the probability of applications requesting the same lock at the same time. Multiple cores each running two threads in kernel mode might try to modify resources at the same time. To prevent this, a semaphore messaging system in the kernel ensures that only one core can access the resources at any one time, but this creates an issue as the other application has to wait. The fine-grained approach provides a semaphore lock for every special resource being addressed, so the application does not lock the entire kernel space, only the resources being used. That though means the developer has to carefully decide how to protect these and avoid multiple locking and deadlocks. One way to do that is to avoid applications with low priority running at the same time as high-priority applications. For example, one Posix kernel is 5000 lines of code in a 10,000-line RTOS that supports up to 255 separate partitions, up from 64, to support more individual applications. It runs in 4 Mbytes of memory on cores with an MMU and can be certified, but it also supports additional features such as fully fledged Linux running with an ML framework that can run in an internal partition without access to the outside world. This prevents external attacks and ensures that all the data is managed by the RTOS. The comms between the partitions are defined by ARINC 653 with memory queues. These comms channels have been abstracted, making them available to all the partitions, so the Linux OS has a driver to the queuing port and the Posix microkernel has something similar. The microkernel is supplied fully compiled and tested, and loads a configuration file that defines the virtual machines. It consists of three parts – a generic package, an architecture-specific package and a board support package. The generic and architecture-specific packages are supplied as pre-compiled libraries, then the developer compiles the code for the board to create a custom kernel. If the certification project requires it, customers can buy access to code for certification but not for recompilation. Single RTOS, multiple cores Another approach is to use the RTOS as both a secure and safety-critical layer. The SWaP of a design is maximised by having greater integration and maximising the use of the cores. In a safety-critical design though, that is at odds with the separation of critical functions so that they don’t interfere with each other and with non-critical functions. This requires a safety-critical RTOS. The RTOS runs on each core and is coordinated so that it looks like a unified OS across all the cores, with task scheduling and resources and timing across all of them. This allows one multi- threaded process to run across all the cores and use the RTOS to figure out which cores run each task. Alternatively, a ‘bound MP’ (multiprocessor) mode can be used, where the developer specifies Unmanned Systems Technology | October/November 2020 The Integrity RTOS is built around a partitioning architecture rather than a hypervisor (Courtesy of Green Hills Software)