Top 5 System Software Considerations for Next-Generation ADAS
5. Plan to Patch
Legacy driver assistance systems, such as simple electronic instrument clusters, are characterized by relatively small software code bases, simple operating systems (OSEK, AUTOSAR), and software design teams experienced with safety-critical development processes. Next-generation ADAS have more extreme demands, such as 3D graphics processing, which leverage large code bases and possibly third party software developed by engineers lacking a formal safe software development process capability. Designers must plan for serious problems with these increasingly complex systems and build into them a reliable, scalable software patch/upgrade system. The mobile device industry has proven the importance and practicality of scalable software upgrade, ranging from lowest level bootloader firmware up to entire mobile operating systems and applications, and mobile device manufacturers have done an admirable job developing and deploying this capability. While there are open standards relating to software upgrade (notably Open Mobile Alliance DM/FUMO), they do not cover many of the more difficult considerations of practical software upgrade, such as version management, scheduling delivery to a high volume of remote systems, and optimizing patch size for constrained wireless networks. The automotive industry needs to get smart on this quickly and then take the technology a step further to demand a high level of confidence in the security and safety of the upgrade infrastructure and the patches themselves.
Safe field upgrade requires a cryptographic infrastructure built into the SoC and its system software. In particular, software will be checked for its integrity and authenticity via digital signatures, whose verification key must be protected against tamper (either via software or physical attack). The verification key must reside in tamper-resistant on-chip key storage or protected by such a hardware-based key. The system software used to perform the validation must itself be protected against tamper, using a combination of secure boot, dynamic integrity checking, and remote attestation. One can think of the on-chip secure storage and the known-good, immutable firmware as the roots of trust for practically any important security function in the system.
4. ISO 26262 ASIL D Compliance
While many legacy electronic driving systems have been developed by small, experienced teams with a proven pedigree delivering safe and reliable software, the transformation to sophisticated ADAS requires a formalized process that can guarantee safety is not left as an afterthought: a safety culture must be permeated across the organization, including design, manufacturing, and operations, and recursively to suppliers. This promulgation of effective process standardization requires not only high quality standards but also enforcement of standards conformance.
The ISO 26262 safety standard, first published in 2011, aims to provide the guidance and has been generally well received throughout the automotive community. Enforcement, however, is lacking, as governments have yet to issue an ISO 26262 mandate. Thought leaders in the automotive industry, including some OEMs, Tier-1s, and Tier-2s, view ISO 26262 compliance as an internal mandate and goal in order to meet the challenging safety demands of ADAS and other systems. At a minimum, obtaining expertise in ISO 26262 and demonstrating both an ability to meet the highest level (ASIL D) as well as choosing suppliers that can do the same (e.g. via independent assessment by TUV) put themselves at a competitive advantage.
A developer can write perfect software only to still have it fail if the software’s compiler fails to correctly translate source code into machine code. ISO 26262 addresses the use of software development tools for the creation of safety-critical software, requiring tools qualification by a combination of pedigree (confidence from use), evaluation of the tool supplier’s development process, and validation of the tool’s functionality). Tools classified at the highest tool qualification level, T3, generate outputs that contribute to the executable code of a safety-related system. While a number of compiler vendors claim a certifiable compiler or qualification package that can be taken through certification by a manufacturer, only the Green Hills and ARM C compilers have been independently certified for use in ISO 26262 ASIL D systems (independently certified by TUV) as of this writing.
3. Leverage Consumer Electronics Standards, Carefully
Next generation ADAS leverages high-end graphics, signal processing, and other sophisticated software and algorithms. ADAS leverages multimedia innovations from consumer electronics, such as mobile and gaming, and designers must be up to speed on related standards, such as OpenGL, OpenVG, OpenVX, and OpenCL.
A big challenge, however, lies in reconciling the use of complex consumer electronics software packages and the preceding requirements for safety (i.e. ISO 26262). One approach to incorporate general-purpose software, including open source, in a safety-critical system is to use system virtualization to isolate the safety-critical components from the complex packages unable to meet safety-critical standards. With virtualization, these complex subsystems can be full “guest” operating systems, running in a virtual machine under the control of a safety-rated hypervisor. Unlike traditional hypervisors, an automotive-grade hypervisor can host native, real-time safety applications as well as guests. The hypervisor’s strict resource scheduling and protection mechanisms ensure that the virtual machine and its constituent applications are unable to impact the execution of critical applications.
Unfortunately, in the case of ADAS, often the complex subsystems must be used in a safety-critical context. For example, a rich 3D graphical display may be used to inform the driver of road hazards. Very few run-time software platforms in the world can claim to support the combination of ISO 26262 ASIL D compliance and 3D graphics, at the same time. For example, Green Hills Software’s INTEGRITY real-time operating system, a well-known platform used in automotive safety systems, supports OpenGL, fully accelerated graphics software and drivers on a wide variety of popular automotive SoCs, such as Freescale’s i.MX line, TI’s Jacinto line, Renesas’ R-Car line and Intel Atom processor E3800 line. System designers must carefully consider systems software architecture to ensure it can scale to potentially any mix of safety-critical and high-end multimedia and signal processing workloads.
Going back for a moment to the ISO 26262 requirements: while ASIL D is the highest ISO 26262 defined safety level, not every component or subsystem in the car or even within a single component/SoC must meet this level. ISO 26262 introduces the concept of ASIL decomposition via software partitioning. For example, an ASIL C subsystem can be composed of an ASIL B partition and an ASIL A partition, as long as the partitioning/freedom of interference can be adequately verified and the overall safety function of the subsystem can be validated and verified to ASIL C. Thus, a high assurance partitioning operating system or hypervisor (itself certified to ASIL D) can reduce overall system cost by reducing the ASIL level requirements of constituent components and permitting the (careful) use of complex software packages that are impractical to assure at higher levels.
2. Zero Trust
One of the most dominant threads of 2014, and continuing now in 2015, is the connected car and the inherent security risks associated with bringing wireless communications (especially WANs) into the car. Ideally, safety-critical subsystems in the car are physically isolated (air gap) from multimedia or telematics subsystems that may take advantage of such connectivity. System designers, however, are increasingly replacing air gap with logical gap, enforcing subsystem isolation with software firewalls. Unfortunately, as researchers have demonstrated, once the wires are joined, vulnerabilities in various subsystems can be exploited to jump the logical gap between safety and non-safety critical systems. While it may seem like a simple problem to solve (keep the air gap!), in practice, there are numerous demands that force these connections. For example, size, weight, and cost pressures promote a reduction in wiring and hardware components. This consolidation forces designers to build in logical isolation. Another important trend was discussed earlier: field upgrade. In order to upgrade a safety-critical subsystem, there must exist a pathway from the patch developer on the net into the upgradeable subsystem in the car. Ironically, it is the remote access pathway, for software updates, diagnostics, and other critical data gathering functions, that has enabled attackers to exploit the wide range of vulnerabilities in software intensive products. In fact, this is arguably the most daunting, security risk facing the Internet of Things today.
Once again, high assurance logical isolation can solve many of these problems. However, “high assurance” is an incredibly rare commodity in modern electronics. As of this writing, only the U.S. government has ever performed a high assurance software certification under the ISO 15408 Common Criteria security standard (for a single product, Green Hills Software’s INTEGRITY-178B), and the government program to foster these high assurance Common Criteria certifications was shuttered years ago due to cost and schedule overruns (read: government bureaucracy). For now, automotive manufacturers and Tier-1s must rely on independent assessments from security consultants and the high assurance pedigree and experience of its suppliers.
The industry must also take strides to protect the privacy of information generated within ADAS and other intelligent subsystems as it is distributed to the cloud for analysis, monetization, etc. While the ownership of such data may be murky, clearly it is valuable, and the aggregation of this information across many millions of cars presents a compelling target for sophisticated, well-funded attackers. Data owners must adopt a “zero trust” posture wherein the owner demands ownership and control of the private keys used to protect such information. By addressing data protection orthogonally to the choice of system software protocols and products, the privacy challenge can be met in a scalable way. 2014 may be known as the year of SSL embarrassments after the incredible variety of failures: POODLE, Heartbleed, Apple’s “goto fail” fail, and others. These vulnerabilities should hopefully send some clear messages to the industry, such as:
- Turning on SSL (or other data-in-transit protocols) is not a strategy for IoT data protection
- Open source and assurance level are orthogonal
- High assurance is the only pathway to vulnerability prevention
1. Don’t freeze hardware until 2 through 5 are covered
All too often, critical, irreversible hardware decisions are made with little or no consideration of the items discussed above. FLOPs and BOMs continue to dominate purchasing decisions, leaving system and software engineers sad. There shall come a day, hopefully soon, when the decision to choose a particular ADAS SoC will consider the SoC’s safety and security capabilities (such as TrustZone, ARM virtualization extensions, MMUs, IOMMUs, on-chip protected key storage, high quality RNGs, debug capabilities such as trace, and more), and the software ecosystem available to leverage such features, as much as the device’s processing power per dollar.
About the author:
Peter Hoogenboom is EMEA Engineering Manager at Green Hills Software.
If you enjoyed this article, you will like the following ones: don't miss them by subscribing to :
