All automotive software must comply with ISO 26262, a functional safety standard that regulates electrical and electronic (E/E) systems across the product development lifecycle, from concept to decommissioning. ISO 26262 identifies and assesses potential hazards surrounding each system component, establishes safety requirements to reduce any identified risks to acceptable levels, and provides validation measures to ensure that these safety levels are actually being achieved once an E/E system is implemented into a vehicle.

The first step to becoming ISO 26262 compliant is identifying a system’s Automotive Safety Integrity Level (ASIL). This process, which evaluates what could potentially happen to a vehicle’s driver and surrounding drivers if a system failure occurs, assigns a system an ASIL risk level based on the probability of a failure, how much control the driver has to prevent a hazard, and the severity of injuries resulting from the hazard. Based on these factors, a system is given an ASIL ranking of A, B, C, or D, with D having the most safety-critical processes and strictest testing regulations.

For example, if (1) a system was very likely to fail, (2) the failure could not be prevented by the driver, and (3) the resulting injuries would be fatal or life-threatening, then that system would be given an ASIL D ranking. As such, it would be subject to much stricter safety regulations and testing cycles than an ASIL A system (for reference, all automotive software submitted for ISO 26262 certification must achieve a ranking of ASIL B or higher).

Once a system’s ASIL is identified, it is given a safety goal that outlines (1) which system behaviors need to be modified to ensure driver safety, and (2) which methods can be used to achieve that specific level of integrity. Although automotive manufacturers and software developers all have their own quality management systems (QMS) for testing and managing their products, ISO 26262 aims to standardize these practices by providing complementary methods. Below is an example of a typical certification process for automotive software artifacts.

Methods for certifying automotive software

While mission-critical systems such as instrumental clusters and driver assistance programs already leverage ISO 26262-compliant software from vendors such as QNX, in-vehicle infotainment (IVI) and other connected car systems need more flexible platforms. Realistically, open source is the ideal way to encourage automotive IoT. In addition to being continuously improved upon through crowdsourcing, open source software enables developers to experiment with out-of-the-box applications in an unstructured environment.

Unfortunately, the very characteristics that make open source a great incubator for innovation also make it nearly impossible to certify for the automotive industry. Without structured processes for developing and maintaining the software, or regulated physical environments for housing and working on the software, or a way to vet and manage all the people who touch the software, open source products are extremely difficult to certify.

If so inclined, a developer could submit every iteration of his or her software for ISO 26262 testing and compliance. In fact, there are several service providers who offer code review and testing for this very purpose. However, keep in mind that most of the electronics in today’s vehicles were initially developed 4-5 years ago due to stringent certification processes; it’s simply not time or cost-effective to continuously test for new updates. Although certifying updated iterations will require less effort than the first gap analysis, developers must still comply with ISO 26262 guidelines any time the software has changed.

A much easier (and faster) approach is to simply separate non-compliant IVI software from mission-critical software via virtualization. In this method, multiple sandboxed virtual machines (VMs) interface with a vehicle’s hardware through a single hypervisor. Since the VMs are completely separated from each other, an IVI system running on Android will never interfere with an instrumental cluster running on QNX. If the IVI system fails, it will have no impact on a driver’s ability to operate his or her vehicle, which eliminates the need for an ASIL ranking. While experiencing a dropped call or frozen podcast is irritating, it isn’t life threatening. As long as IVI software is separated from mission-critical software, there’s technically no need to submit it for ISO 26262 certification.

Of course, the only way this approach will work is if the hypervisor itself is certified. GlobalLogic is currently developing an ISO 26262-ready version of the Xen Hypervisor with encouraging results. As you can see in Figure 2, the goal is to create a virtualized environment in which only a handful of software components need to be ISO 26262 compliant. IVI and connected car systems are free to operate without constraint because the underlying hypervisor is certified and because they do not physically interact with any mission-critical components. Without the restrictions of ISO 26262 compliance developers can accelerate time to market and expand on innovation.

Conclusion

Automotive manufacturers and software developers are struggling to balance the innovation requirements of the connected car movement with the considerable safety regulations of the automotive industry. While there is no denying that ISO 26262 is crucial to driver safety, it is also very limiting in terms of how the IoT can be applied to vehicles. Rather than trying to reconcile these two opposing requirements product-by-product, it makes much more sense to take ISO 26262 certification processes out of the picture entirely. By creating a virtualized environment in which mission-critical and connected car systems are completely separated, developers can freely create innovative new automotive software without violating ISO 26262 safety standards.

Alex Agizim is CTO of Embedded Solutions at GlobalLogic Inc.

GlobalLogic, Inc.

www.globallogic.com

@GlobalLogic

linkedin.com/company/globallogic