Get the process right (a fast intro)
Get yourself a cup of coffee because it’s time to talk process. Yawn, right? Have you heard the saying about how “getting the process right is more than half the battle to receive a functional safety certification?” Actually, it’s no joke. A large percentage of most safety standards are dedicated to defining what processes you should follow to build a safe system.
A good example to illustrate safety process is the V-model, a reference process model for each phase of product development defined in ISO 26262. The standard explains: “The software development process is based on the concept of a V-model with the specification of the software requirements and the software architectural design and implementation on the left-hand branch, and the software integration and testing, and the verification of the software requirements on the right-hand branch.”
Figure 2: The V-model from ISO 26262, Road vehicles — Functional safety — Part 2: Management of functional safety
Safety throughout the product lifecycle
ISO 26262 goes on to explain that the safety lifecycle encompasses “the principal safety activities during the concept phase, product development, production, operation, service and decommissioning. Planning, coordinating and documenting the safety activities of all phases of the safety lifecycle are key management tasks.”
To sum it up, a well-defined safety process ensures that an organization keep safety in mind at every step in the software development lifecycle.
Understand the hazards
Functional safety standards typically start with hazard identification, because the risks posed by hazards drive the safety requirements for a system. In the following table from the Hazard & Risk Analysis for an operating system, you can see how risks lead to safety requirements for three hazards that could emerge when the prescribed action A does not occur within time T after receiving a command:
This exercise of identifying the hazards and deriving safety requirements must be carried out thoroughly for the component or system that issafety-critical. The resulting list of safety requirements is what you must shepherd through the development lifecycle exemplified by the V model.
No SOUP for you
It is permissible to use off-the-shelf components if they come with sufficient evidence from the supplier to support the overall system’s safety case. Building all software from scratch won’t necessarily result in a safer system than one that uses commercial off-the-shelf (COTS) components with tens of millions of hours of in-use history.
However, many COTS components are considered software of unknown provenance, or SOUP, unless they are pre-certified for safety. If you use off-the-shelf (OTS) software in a system requiring SIL 3 or 4, for example, most safety standards require you to develop a strategy to detect failures of the OTS software and to protect the system from these failures. If sufficient support is not provided by the supplier, SOUP can result in an overwhelming burden for your software development team. That’s why functional safety engineers, at least the ones who are Seinfeld fans say, “No SOUP for you!”
Choosing pre-certified software, such as QNX OS for Safety or QNX Hypervisor for Safety, can save money, lower risk, and significantly reduce the time you’ll spend documenting or re-creating an uncertified software component, such as Linux.
Consider these four criteria when selecting OTS components for a safety critical system:
- Supplier reputation and track record
- Product information including development artifacts
- Standards compliance, preferably certification
- Supplier audit
A good way to test the safety depth of your supplier is to ask about the availability of some key documents that can support your safety case, such as:
- Functional Safety Requirements
- Functional Safety Management Plan
- Safety Case
- Hazard and Risk Analysis
- Safety Manual
Design with safety in mind
Working from the premise that errors lead to faults and faults lead to failures, you’ll need multiple lines of defense to design and build a functionally safe system, including isolation and freedom from interference.
Isolation and freedom from interference
An aspect of functional safety is designing the system to isolate safety-critical functions from other functions and ensure they are free from interference. For example, the important warning displays on an automobile digital instrument cluster should be isolated from vehicle infotainment systems, even if they share display space on the dashboard.
Subsystems sharing a single system-on-chip (SoC) may be subject to safety requirements at different safety integrity levels, such as ISO 26262 ASIL A, B, C or D for a subsystem found a passenger vehicle ECU (Electronic Control Unit). Sufficient temporal and spatial separation between safety-critical and non-safety-critical domains allows for a simpler design, which leads to a simpler safety case and a lower certification effort.
A microkernel architecture, such as QNX® Neutrino® RTOS, can separate multiple functions, both spatially and temporally, and provide isolation and freedom from interference in embedded systems with mixed criticality.
An embedded hypervisor divides hardware resources into separate execution environments called virtual machines (VMs). The hypervisor manages these virtual machines, making sure they share resources without conflict. An embedded hypervisor, such as QNX® Hypervisor for Safety, allows designers to run separate and isolated guest operating systems – such as Linux, Android and QNX – on a single system-on-chip (SOC).
Leverage expertise where available
Safety certification is complicated and time-consuming. Most development organizations engage outside expertise to avoid missteps and delays. Some organizations benefit from assistance from start to finish, while others only need expertise in specific areas. These three examples show how development organizations use safety services differently:
- An organization new to functional safety wants training to bring its technical team up to speed on the relevant functional safety standard, assessment services to examine the organization’s internal processes, and help designing safety requirements and safety architecture.
- An organization with experience in functional safety wants expert advice on a specific technical area, such as how to use the memory protection features of a specific RTOS.
- An organization attempting to use a certifiable or compliant software solution (not pre-certified) wants a gap analysis and assistance to document what can be done to fill the gap to satisfy an auditor.
Keep it safe
Release cycles matter; safety certification is always linked to specific versions of all software components and will have a lifespan of years. When it’s time to revamp the product, some of the software may have reached end-of-life.
Choosing a more modular OS, such as a microkernel RTOS, can isolate the impact of software changes and simplify certification.
In addition, an embedded hypervisor can play an important role in a product team’s ability to rapidly create, test, and certify a new version of a safety-critical product. With a hypervisor, the development team can re-use proven legacy software (for example, running it in a dedicated virtual machine) and keep safety functions separate. Software components can be built by independent groups, tested separately, run together, and swapped out without affecting other systems or having to retest the whole system repeatedly.
Finally, there is no safety without security. Unfortunately, since security is a newer topic for embedded systems than safety, there is less accumulation of security knowledge, expertise solution sets and industry guidance. Security for embedded devices calls for a different set of skills and solutions than IT security, and there isn’t a dominant security standard to follow.
BlackBerry® has developed in-depth security expertise and technology throughout the last 35 years. Our tens of thousands of patents and more than 80 security certificates reflect a deeply entrenched security culture and capability.