Part 3 – Old World, New World: The Challenges of Bridging the Gap
Without open standards, OEMs will not be able to transition through the SAE levels of autonomy. OEMs will stay in Level 2, or an extended version of Level 2 (often referred to as Level 2+) but will not evolve to Level 3 in a credible timeframe. Nor will they achieve UN’s WP29 requirement to maintain and update the car’s software for the lifetime of the vehicle.
The SAE (Society of Automotive Engineers) defines five levels of autonomy:
| SAE Level |
Title |
Description |
| Level 0 |
No Automation |
None, driver controls everything |
| Level 1 |
Driver Assistance |
one automated process e.g., cruise control or lane assist |
| Level 2 |
Partial Automation |
More than one automated function e.g., brakes/accelerator and steering. Used for automatic collision avoidance |
| Level 3 |
Conditional Automation |
Automation with driver on standby to take back control |
| Level 4 |
High Automation |
Automation without driver but with some limitations eg routes available, platooning, extreme weather. Vehicle safely stop autonomously if experiencing something unsafe. |
| Level 5 |
Full Automation |
Fully autonomous cars with no limits |
We currently have a gap between the millions of lines of code created for cars today, and how to integrate the new computer vision and AI algorithms for the next generation smart cars. This gap is estimated as getting from 100 million lines of code in the most advanced cars today, to 1 billion lines of code to achieve an autonomous vehicle.
The problem is enhanced by the limitation of silicon to maintain Moore’s Law, pushing semiconductor suppliers to produce heterogeneous multi-core processor chips i.e. those containing different types of processor architectures tuned to the type of algorithm processing required.
Can new world AI developments co-exist with old world software?
New and old will need to co-exist. There are huge gaps in software and development styles, from low level assembly programming in the processor’s native language; C code, which has been extensively used for years in cars; C++ code which continues to evolve and is the most widely used language in the world but limited in cars, and finally the extensive use of libraries and frameworks providing another layer of abstraction to embrace computer vision and AI.
A car will embrace all languages and will increasingly include the higher-level languages of C++ and AI frameworks for a blend of all languages.
Today, new car companies have started development from a clean sheet and are embracing C++. They are therefore quicker to embrace the latest AI technologies and succeed with integrating these into the latest chipsets. Look to these leaders and see how big the software gap is. They are quickly evolving, and the gap is getting bigger as conventional car companies struggle to evolve.
What is the status on standardization?
The compute standards are already existing today, with many AI developers already benefiting from them within many industries. OpenCL and SYCL from Khronos are well defined, adopted with extensive ecosystems.
Functional safety for automotive is still catching up with modern programming methods, but this is being addressed through MISRA and ISO26262. So by the time the cars come to market fully embracing open standards, then programming requirements will be included. But this isn’t stopping companies adopting open standards programming today.
With so many processor architectures coming to the market with their own special DSL (Domain Specific Language) software, these solutions take substantial integration effort meet customer needs, with software limitations quickly inhibiting time to market, escalating the overall solution costs and further impact the expectations of the next generation developments.
There are some companies that have either experienced the limitations caused by bringing their proprietary solutions to the market and are looking to re-think their software architecture and organization, so that it can provide an open standards based platform and embrace the growing ecosystem.
Tesla has invested a huge amount of money to be a vertical organization, creating their own chip with their full software stack. So Tesla does not need to worry about open standards and ecosystem. But all other companies cannot mimic this software approach and cannot afford to go it alone.
For other automotive companies, these OEMs and Tier 1 companies have a more traditional software development environment which brings difficultly in adopting modern programming methods and frameworks. They stick to what they know and have done over the last 10 years and are cautious in bringing modern programming methods into their development teams.
My 3 Concluding Messages
- Embrace the modern software approaches using OpenCL and SYCL, and work with the industry using open standards-based programming.
- OEMs will not transition from L2 to L3 with traditional software approaches; they will drift forward while the new car manufacturers take advantage of their modern software solutions.
- Finally, remove proprietary, lock-in and restrictive solutions. As software becomes more dominant, these proprietary solutions will become an even bigger limitation, and cannot benefit from the array of latest processor architectures available.
Want more tech news? Subscribe to ComputingEdge Newsletter today!
About Codeplay
Codeplay Software provides the tools to enable software to be accelerated by graphics processors or the latest specialized AI processors. Codeplay works with leading technology businesses to build advanced intelligence into devices ranging from smartphones to self-driving cars. For more information, visit www.codeplay.com. Contact Mr. Macfarlane at charles.macfarlane@codeplay.com.
