11 “Musts” for an Automotive Integration Revolution
March 27, 2015 by John Day
By Andy Gryc
Conference Director, Connected Car Expo
Co-founder, CX3 Marketing
Tier one companies like Bosch, Continental, Delphi, Denso, Harman, Mitsubishi Electric, Panasonic, and Visteon have deep expertise in building numerous complex modules for the car companies, they all have the know-how for building reliable, safe systems, and all are willing to be a “secret ingredient” instead of a nameplate brand.
Tomorrow’s car, regardless of who’s building it, will have even more working software in it than today’s cars do. The integration problems that car makers face today will only be compounded in the future with the explosion of smartphone connectivity, apps, wearables, fog computing, big data analytics, ADAS and autonomous technology.
Tomorrow’s car will have 2 billion lines of code, and current tools and methodologies will be very inadequate in dealing with this exponential explosion in software.
It’s worthwhile to step back a bit and see how hardware engineers have coped with exponential complexity in their domains.
Lego Block Hardware
Hardware design has been able to scale with Moore’s law because hardware engineers use a building block model. Each hardware logic block is assembled from the composition of dozens or hundreds or thousands of reliably functioning and interchangeable entities.
Unfortunately, software doesn’t work that way. Despite the desire by many and the attempts by a few, software has yet to be tamed in such a rigorous, modular fashion. As any automotive tier one will tell you, software integration is a difficult and dirty business.
Why Software is Hard
Why is software so different from hardware? A single embedded system uses a huge array of software components that together fulfill the system’s requirements. Those components are a hodge-podge of different types of software: individual programs, drivers, utilities, applications, libraries, scripts, system services, and other assorted chunks of code.
For an automotive module like a telematics box or infotainment system, the components are things like phone dialers, navigation engines, speech recognition libraries, Bluetooth stacks, vehicle bus drivers, user interface frameworks, graphics drivers, operating systems, etc.
Each one of these components uses a very specialized interface to communicate to other software, called APIs (Application Programming Interface). The APIs for each type of component use different languages or tools. Even between similar components–because the software does different things–the APIs will usually be different. And not all the software comes from the same source: there are many different suppliers involved.
The integrator (normally a tier one) takes all the code from those many suppliers and pulls it all together. Because each project is different, how those software components need to communicate to each other is also different per project. It requires a team of reasonably skilled engineers to add all the scaffolding and weave in all the bits of code needed so that two chunks of code can “talk” together. And that needs to be done between all the components that make up the final system. That means that every integration effort is effectively one-time code. Although pieces may be leveraged, the integration code as a whole has never existed before and it can’t be reused.
Furthermore, although the software modules do a consistent, reliable job, they’ve only been tested individually by their supplier. They haven’t been combined and tested in the endless possible configurations that the tier one could have used them. So testing the entire project requires construction of completely new testing scripts and sometimes even new testing frameworks, each and every time.
Seven Software Principles for Effective Automotive Integration
We need tools that allow creation of reasonably complex systems from many pre-existing parts without a handcrafted creation process. Here are the attributes that I think a Lego-style approach to building massive software systems must have.
1. Reasonable performance: tools cannot be noticeably slower than what is achievable with standard techniques.
2. Language independence: tools should be designed to integrate with multiple languages.
3. Existing interfaces: tools should not require APIs or module software to be rewritten.
4. Timing described: tools should be able to make deductions about the timing behavior of the module under load.
5. Space described: tools should predict average case and guarantee worst case of memory utilization patterns.
6. Automatic verification: tools should be able to programmatically verify connections between components for consistency and compatibility.
7. Easily reasoned about: the tools’ methodology and language should be simple to understand and reason about by people and machines.
Without at least these high-level properties, any integration tool attempting to make software “plug n play” will not help or will not be adopted. Some of these features are pretty difficult to design, but none should be impossible.
Four Principles of Module Integration
The seven principles of integration apply to software within a single module, but the car has many modules. So we need to add a few more guidelines to guarantee working between multiple modules.
1. Reliable. Communication between modules must be reliable.
2. Real-time. Communication should be exchanged within a guaranteed deadline and with a minimum of jitter.
3. Standards. Communication should be standardized, flexible enough for future growth, and not created specifically for automotive.
4. Protected. Communication between modules should authenticate sender and receiver, and disallow modification and snooping of the data exchanged.
Of course these principles are realized through the vehicle bus. We’ve seen some of these before but current vehicle bus technologies can’t adequately address each point. For example, CAN isn’t secure enough, and MOST is too auto-centric. I know some readers may argue with my rule about avoiding automotive specific standards, but using a technology that’s viable outside of automotive helps foster a vibrant, living technology that can interface the car to the outside world rather than an inwardly focused and potentially dead-end solution.
Is an Integration Silver Bullet Possible?
Is there anything on the horizon that can combine all of these 11 benefits into a new way to design complex, multiple module software that will be building tomorrow’s cars? Some portions of the puzzle are being solved in other domains.
Ethernet-AVB looks like the best candidate for a new vehicle bus standard. It’s fast, flexible, and real-time. It is used outside of the car, which gives the technology legs, and it has the ability to incorporate security features from the Internet world. Some additional work may be needed to perfectly mate it to the automotive world, but that work is forging ahead by Harman and other big players. I’m confident it will eventually emerge as the new vehicle bus standard.
There are a lot of exciting new programming languages that attempt to combine performance, testability, and ease of use—Julia, D, Haskell, Erlang, Rust, Haskell and many more. Many of these languages solve or remove the challenges encountered in C/C++, the current workhorse language of embedded. Some of these challengers could make excellent replacements for a new go-to embedded language.
Of all of the languages I mentioned, I think Rust is the best candidate for a new embedded language standard, because:
• It is very fast and you don’t pay the performance penalty of some other technologies
• It is designed for OSes and low-level code which still comprises a lot of embedded work
• It uses language constructs that automatically prevent memory corruption and unsafe thread behavior, two of the most challenging software problems to fix in C/C++
• It has a clean way to interface with existing C code.
Plus, what’s not to love about a language named Rust used for automotive?
No tool I’m aware of is designed to solve the multi-program, whole system coordination problems that are encountered in integration. That’s still the domain of startup scripts, custom apps and specialized launchers. Operating System tools allow you to measure the performance of a running system (run-time checks), but no real world tool lets you check the validity of the whole system before you run it (no “build-time” checks). And very few software tools are written to allow you to test, check, or measure multiple programs working together. Doing so simply and consistently will be key for tomorrow’s integrators.
Do you have any ideas on what might help solve the challenges encountered in integration? I’d love to start a dialog on what you think tomorrow’s integrators will need to quickly build safe and secure cars from the heaps of complex technology we have all come to expect.
Conference Director, Connected Car Expo
Co-founder, CX3 Marketing