Top 5 System Software Considerations for Next-Generation ADAS

May 14, 2015 // By Peter Hoogenboom, Green Hills Software
Next generation ADAS (with autonomous driving perhaps its ultimate manifestation) presents automotive application and system designers with a seemingly irreconcilable mix of safety certification, connected security, and cutting edge signal processing and graphics visualization requirements.  This article presents the top 5 system software considerations for OEMs, Tier-1s, and their suppliers looking to create successful ADAS software organizations, infrastructures, and products.

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.

Fig. 1: ADAS subsystems and non-critical partitions consolidated on a multicore processor

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

Design category: