Mixed criticality in embedded systems
Multicore embedded designs are becoming more common by the day. There are various of reasons why this design choice is being made and we addressed a number of the issues in a recent webinar [you can see the recording, including Q&A here]. I would like to pick up on a couple key points from the webinar concerning the applications for AMP systems with multiple operating systems …
An AMP system has multiple cores that may be of different architectures. Each CPU runs its own [copy of an] operating system. Multiple operating systems may be used in a single design, each being chosen for its particular characteristics and capabilities. This approach results in a quite a complex system design, but there are a couple of reasons why it is regarded as worthwhile.
First off, there are designs that feature multiple time domains – different parts of the system have a different idea of what time means.
Some CPUs may run a real-time operating system [RTOS] if they need to exhibit hard real time behavior and be responsive to external events. Similarly, there may be CPUs with no OS at all, as they need to avoid any possible overhead to deliver maximum computing power. Other CPUs may perform tasks where time is not an important factor and they can reap the benefits of a non-real-time OS, like Linux.
The other motivation for a multi-OS AMP design is a system that needs certification. In a number of industries – automotive, mil/aero, medical, industrial – it is legally necessary to obtain certification for the hardware and software design. The certification of software is a costly endeavor and that cost is significantly affected by the quantity of code involved. Matters may be eased by sub-system certification.
With this approach, only parts of the multicore system are used to run the critical code, so only those parts need to be certified. There needs to be a secure barrier between the certified and non-certified parts of the system, but this is a small price to pay for the benefits of such a design featuring mixed criticality. Costs are reduced, as there is less code to certify, and this can lead to shorter time to market. These advantages are reinforced by having the option to choose cost- and time-effective options for the non-critical parts of the system.
Mixed time domain and mixed criticality are not mutually exclusive – a design might feature both motivations for implementation of an AMP system with multiple operating systems.
