Developing certified embedded applications

In a number of different fields – notably medical, military, avionics, industrial and automotive – there is an increasing focus on safety and security, which results in a higher demand for certification of systems. Such certifications include FDA 510K [medical], DO-178C [avionics], IEC 61508 [industrial] and ISO 26262 [automotive].

Certification of software is a big subject, requiring specialist expertise and often a large budget. But all embedded developers would be wise to have a grasp of the basics …

Broadly speaking, the certification of an embedded software application entails the inspection, analysis and testing of the code on a line by line basis. This is a specialized and, hence, potentially expensive exercise. There are some key points to note:

1. the certification process is applied to the entire application, including OS, middleware etc.
2. all of the source code must be available [this is only an issue if 3rd party IP, like an RTOS, is used]
3. the more lines of code, the greater the cost of certification

Taking these points in turn:

The implication of (1) is that it is not possible to simply purchase an OS etc., which is fully certified. However, there are some measures that may be taken to reduce the cost/effort. First, it is wise to select 3rd party IP which has a track record of being certified, as this is reassurance that problems are unlikely. Asking the vendor for references might be wise. Better still is the situation when the vendor offers a “certification ready” OS package, where much of the detailed work has been done, which is a shortcut to getting the certification of the whole application. Just such a package was recently announced by Mentor Embedded.

Obviously the source code for the in-house developed software is readily available – though careful version management must be employed. Any code that has been custom developed by a third party must be brought under the same version management scheme. Off the shelf third party IP must also be available in source form. Some OS vendors do not provide source code. Others do so at a price. A few provide source, but it is scrambled, which renders it useless for certification purposes. A few RTOS products are provided as source routinely; Nucleus RTOS is a good example.

Because code size – lines of source code – needs to be minimized to reduce certification costs, care should be taken to ensure in-house code is developed efficiently. Furthermore, the size [and scalability] of 3rd party IP must be considered. Again Nucleus RTOS scores well, as it is highly scalable, rendering a modest memory footprint.

There is a possible certification shortcut, which can reduce costs and effort: only certify part of the application. The application needs to be divided into safety critical components [which must be certified] and non-critical parts [which are not]. This is termed “Mixed Criticality” and can be achieved only if a very solid security structure permits the division of the two parts of the application, so that the secure part is “safe” from interference by the rest of the code. This is best achieved by using a process model OS, which uses the memory management unit [MMU] to remap and protect memory.

The problem with process model operating systems is that they are typically large and complex [which increases certification costs]. They also introduce overheads by using the MMU for every context switch and may not be deterministic [real time]. A good option here would be an RTOS [compact and deterministic], which uses the MMU in a minimal way – just protecting memory, without the unnecessary remapping. Once again Nucleus RTOS provides for these needs.