Top 5 System Software Considerations for Next-Generation ADAS: Page 6 of 6

May 14, 2015 //By Peter Hoogenboom, Green Hills Software
Top 5 System Software Considerations for Next-Generation ADAS
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.
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.

Design category: 

Vous êtes certain ?

Si vous désactivez les cookies, vous ne pouvez plus naviguer sur le site.

Vous allez être rediriger vers Google.