There is an increasing focus on safety and security in a variety of embedded applications. This, in turn, drives a demand for certification of such systems. The most widely used certifications are:

• FDA 510K medical)
• DO-178C (avionics)
• IEC 61508 (industrial)
• ISO 26262 (automotive)

Software certification is a broad subject that requires the right expertise and a generous budget. However, most embedded software engineers should have a basic appreciation of the process …

Certification requires a line-by-line inspection, analysis and testing of the code. There are some key points to note:

1. The process is applied to all the code – the entire application; this includes all the operating system components.
2. All of the source code for the software must be available, including any obtained from a third party (like an RTOS, for example).
3. The larger the application – i.e. the more lines of source code – the more expensive the certification process will be.

Looking at these points in turn:

1. Suggests that it is not possible to simply purchase an OS that is certified. However, there are measures that can make the certification process simpler and cheaper. Choosing third-party software components that have a track record of being used in certified application (get references from your vendor) makes sense. Ideally your OS vendor will be able to supply a “certification ready” package, where much of the detailed work has been done on their products, thus providing a shortcut to certifying the whole application.
2. Availability of application source code should not be a problem, though care with version control is obviously essential. Clearly source code of externally sourced software components is also needed. This may be supplied routinely or may come at a price. Care is needed when selecting an OS, as some products are provided with source code, but it is there for ease of configuration only and is, hence, scrambled and useless for certification purposes.
3. Minimizing the size of the application code – in terms of lines of source – helps keep costs down. Choosing an OS of modest size yields the same benefit; a modern, scalable RTOS will fit the bill.

It would seem logical to use an operating system that is designed to be safe and secure. This implies a “process model” OS, where the tasks are protected from one another using a memory management unit (MMU). When a given task is running, the memory is remapped so that the areas belonging to all the other tasks and the OS itself is invisible. Although this security is attractive, it comes at a high cost in terms of OS complexity, performance and size. However, some RTOS products support the use of an MMU is a simpler way that just hides the other memory areas from the running task. This is commonly called “Lightweight Process Model” or “Thread Protected Mode”.

There is a possible shortcut to achieving certification: only certify part of the application – the part that does the work that needs certified code. This can only really be achieved in a multicore design, where specific cores are used for secure code and others for the rest. This requires suitable multicore management software and a clear boundary (in hardware and software) between the two parts of the system. This is termed “Mixed Criticality”.