Modern embedded software is a complex conglomerate of code components that originate from numerous suppliers. Standards such as ISO 26262 and IEC 62304 provide guidance on the acceptable use of third-party software and help software developers mitigate risks with best practices.
Once upon a time, long, long ago, embedded software development consisted of writing a simple, bare metal application in C or assembly code. A standalone project was built for a specific task by a small team often based in a single office. But today, bare metal applications generally exist only as part of a much bigger picture.
Times have changed, and software development and maintenance has grown to become the costliest and most time consuming part of many modern embedded systems. Modern embedded systems are built on layers and layers of technology, requiring software teams of hundreds or thousands of developers who contribute millions of lines of code to a release image. It is rare for a single organization to own the entire software stack. How can anyone manage the potential risks introduced by including code from other entities and organizations to live happily ever after?
A modern, high-level software architecture for an embedded system will likely include many components. Operating systems, device drivers, communication stacks, bootloaders, hypervisors … and that’s before anyone adds any application code.
In most cases, the system codebase is a combination of handwritten code, autogenerated code, commercial off the shelf software (COTS), and open-source software (OSS). Throw in legacy code, compiler related software, template libraries, and third party tooling and there’s quite a risky looking mix.
For example, many parties in the supply chain participate in the development of vehicle software. Vehicle manufacturers rely on hundreds of first and second tier suppliers to design and manufacture the vehicle sub-systems and electronic control units (ECUs) that are integrated into the vehicle. These suppliers rely on semiconductor IP companies and hardware suppliers to produce microcontrollers along with the necessary software development toolchains, run time libraries and hardware interfaces.
The complexity of the resulting software stack consisting of code from a plethora of sources makes it imperative that risks are managed carefully.
It is clearly important to be sure that third party software will fulfil its purpose, and will save a justifiable amount of development effort. However, there is much more to think about.
Consider software licensing, for example. While open-source software is usually provided at no cost, it often comes with restrictions and obligations. It is important to consider whether those restrictions limit the commercial use of the software, whether modifications are permissible, and if so, whether those modifications have to be delivered back to the open-source software community or your users.
Failing to understand and comply with these restrictions and obligations can result in damage to an organization’s reputation, hefty penalties and fines and possibly result in prison time.
COTS typically comes with a license agreement that spells out what use of the software is permissible, and what royalties or fees, if any, must be paid to the software supplier. If there are violations of the license agreement from either side, then the other side may take legal action and claim damages. However, COTS licensing models can be more difficult to navigate than their open-source counterparts. They often contain complex licensing metrics and conditional clauses, and the license models can vary widely.
It is also important to ensure that the intellectual property associated with the software is actually the property of the COTS vendor. Their intellectual property infringement may result in apparently blameless customers being subjected to additional fees, or being forced to stop using the software.
No software is perfect, and failures in software sourced externally are clearly more challenging to deal with than for in-house projects. These failures may impact safety, or result in costly product recalls, which can also negatively impact the reputation of the manufacturer. Functional standards such as ISO 26262 Road vehicles – Functional safety, (ISO, 2018) contain guidance on best practice for developing a safe product. The standard dictates that if the product is safety critical, scrutiny of any applicable third party software is required by the integrator, preferably with assistance of the supplier.