For a growing number of commercial embedded systems, malfunction could result not just in financial loss, but in loss of life and / or large scale environmental damage. In developing these safety-critical IoT applications, you can’t afford to take chances. But commercial pressures don’t go away just because you’re diligent. The defence and aerospace industry have been striking this balance for many years – and the working practices they have developed, in particular in terms of reusing code once it has been thoroughly tested and proved, can be more widely used in the embedded systems industry.
In every safety-critical sector, software development teams fight the project triangle. Budgets need to achieved, the system needs to work in a timely manner with all specified functional requirements fulfilled. Compromise on any of those factors impacts the quality of the resulting product. Add the ever-increasing awareness of security issues and it is clear that developers face huge challenges.
For each of these challenges, the basic question is “how much is enough”? Striking the right balance requires assessing the risk involved with any particular course of action. In safety- critical industries, this notion is formalized by defining risk as the product of the probability that a hazardous event will occur along with the severity of the consequence if it does. Several industries have defined functional safety guidelines and standards for managing tangible risks associated with software.
The avionics industry has particularly extensive experience in this area, and the guidelines it uses for creating safety critical software are encapsulated in the RTCA DO-178 document (previously DO-178B and latterly DO-178C). Similar process standards apply to the wider industrial domain, with IEC 61508 as the general standard from which more specific standards for railway, automotive, medical, industrial and nuclear industries have been derived. Like DO-178, IEC 61508 (and its derivatives) has at its core a process document, which defines the activities and metrics that must be obtained during software development, starting with a system safety assessment.
Comprehensive validation and verification represents a considerable overhead, so it needs to be implemented as efficiently as possible. One obvious route is to reuse software that is proven to have worked.
Support tools provide an example as to how this applies. Standards such as IEC 60601-1:2005, IEC 61508, ISO 26262, and IEC 62304 provide for such tools to be assessed and confirmed by independent organisations such as TUV eliminating the need to undertake assessment case-by-case.
The same reuse argument extends to the application software. For example, a key clause in the automotive ISO 26262 standard applies when a component has been used in other applications without issues, which naturally extends to older systems which were developed in accordance with past best practice.
There are efficiency benefits to be gained from software reuse, but great care is needed to avoid increasing risk by doing so. Even after many thousand runtime hours, application code may still only have been exposed to particular combinations of conditions.
That argument is reflected in the Federal Aviation Authority’s Advisory Circular AS20-1484, designed to provide guidance for the development of Reusable Software Components (RSC), such as software libraries, operating systems, and communication protocols. From the document:
“… an RSC developer may partially satisfy the applicable RTCA/DO-178B objectives, while the integrator or applicant completes and shows the compliance for the integrated software package, systems aspects, and aircraft certification...”
Deploying any such RSC within a DO-178 compliant system can save significant hours of certification time. In the case of a Real Time Operating System (RTOS) without an RSC, the FAA will require that certification artefacts are regenerated, resubmitted and re-reviewed for each and every reuse, including software changes made to an existing installation.
RSC RTOS also benefit because a large majority of DO-178 objectives are hardware independent. Here, FAA acceptance can be “handed down” from project to project, irrespective of the target hardware (Fig. 4)
The clear advantages of an RSC RTOS do not just apply to aviation applications, extending through each of the process standards – DO-178 and IEC 61508 included. The bottom line is that for an RSC RTOS – or indeed, for any RSC - the FAA is satisfied that if instructions are followed then the software component will ALWAYS behave as expected. Software components without FAA RSC acceptance will require justification in each and every case.
Whether the application involves an aeroplane, a heart monitor, a car or a nuclear power plant, that makes it easy to present the evidence of applied best practise. With Reusable Software Components every user know exactly what to expect of them. Whether the application is under FAA jurisdiction or not, that represents a strong engineering case to seek out Reusable Software Components.