46 Real-time operating system (RTOS) implementations are changing as uncrewed system platforms evolve. The technology is used widely, from small operating systems for UAVs to larger and more complex implementations running critical systems in driverless cars. The implementations in both areas are changing significantly. The code is becoming smaller, more secure and more reliable on a single microcontroller, while the larger ones are also more secure, as well as scalable, modular and updateable on microprocessors with multiple cores in order to ease the challenges of certifying the software as safe. As the complexity of uncrewed platforms increases, larger real-time systems of various architectures are being used in subsystems such as vision systems and Lidar that have to combine the inputs of multiple sensors and handle a wide range of sensing algorithms in real time. Different architectures are being used for the RTOS, moving from the traditional hypervisor to separation kernels and unikernels. An RTOS provides a layer directly on a microcontroller or microprocessor, called a ‘bare metal’ implementation, that provides real-time control of the system. However, it can be difficult to programme and is limited in the applications that can be added, such as Bluetooth or video processing. To address this, an RTOS provides the basis for a hypervisor to manage various functions in what is called a virtual machine (VM). The hypervisor is either integrated into the RTOS or added as a layer on top to allow higher level code to run on a microprocessor. This is particularly important now with machine learning (ML) engines running on Linux or its real-time version, Posix. However, a hypervisor has to manage the resources in the processor, so it can leak data between applications or provide an entry route for hackers. The evolution of RTOS implementations is addressing the challenges of developing and certifying millions of lines of code for uncrewed systems where different levels of system robustness and reliability are required. This creates several challenges for software architects and engineers. As certification cost is a function of the number of lines of source code being certified, a large operating system such as Linux is impractical. For avionics systems in large UAVs, certifying software to the highest level, DO-178C DAL A, can takes months if not years. With applications sharing resources such as CPU cores, memory and I/O, the software must be able to deliver deterministic and high reliability in the face of cyber attacks, poorly written code or a failure of system functionality. With technologies such as AI continuing to evolve, the software must also continue to add functionality to deployed systems through over-the-air updates, which have to be safe, secure and reliable. This has led to a special type of bare metal hypervisor called a separation kernel, which looks very much like an RTOS. This is a tiny piece of carefully crafted code (as small as 15 kbytes) that uses virtualisation hooks in modern processors to define a VM and control information flows. Separation kernels contain no device drivers, user model, shell access or dynamic memory; these ancillary tasks are all pushed up into guest software running in the VMs. This simple architecture results in a minimal implementation that is suitable for embedded real-time and safety-critical systems. A separation kernel is much more than just a minimal hypervisor implementation. Separation kernels can be used to partition processor hardware resources into high-assurance VMs that are tamper-proof and can’t be bypassed, as well as to set up strictly controlled information flows between a VM and the peripherals so that the VM is isolated except where explicitly allowed. Separation kernels allow modular software design architectures to be Separation kernels are becoming more important for real-time sensor processing in uncrewed systems. Nick Flaherty explains how they work Degrees of December/January 2024 | Uncrewed Systems Technology
RkJQdWJsaXNoZXIy MjI2Mzk4