11 “Musts” for an Automotive Integration Revolution

March 27, 2015  by  

andy gryc AAEAAQAAAAAAAAM2AAAAJDI2ZTg5MTIwLTViNGUtNDE2YS04NGE2LWNiODQ2MjhhZGUwNQ

Andy Gryc

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.

Vehicle Bus:
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.

Software Languages:
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?

System Integration:
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.

–Andy Gryc
Conference Director, Connected Car Expo
Co-founder, CX3 Marketing
andy@cx3marketing.com
Twitter: @cx3marketing

 

Comments

7 Responses to “11 “Musts” for an Automotive Integration Revolution”
  1. Katie says:

    Test 6

  2. Hi Andy,

    thanks for sharing this — after >10 years in the Automotive/Infotainment business I fully agree that system and software integration is a major challenge, and will be even more with the C2X, Connectivity and IoT requirements of the near future.

    Regarding the seven software principles you thoughtfully collected in your article I want to share a technology which might help at least for principles 2, 3, 4, 6 and 7: In 2011, the GENIVI consortium initiated the Franca project, which is available as open source and will migrate soon to Eclipse Foundation (see https://www.eclipse.org/proposals/modeling.franca/). Franca provides a language- and platform-agnostic, neutral Interface Definition Language (IDL) including the possibility to formally define the dynamic aspects of inter-component communication. It also provides tools for automatic verification of the dynamic interactions between components. Franca thus focuses on the integration of complex technical systems already on the level of architecture and design models.

    Franca is already used by several tier1s and some OEMs for R&D of their latest IVI systems and platforms. Among the various projects using Franca there is CommonAPI C++ (again open-source, see http://projects.genivi.org/commonapi/home), which is a flexible code generator based on Franca for creating the glue code needed for communication between components and subsystems. As project lead of the Franca open source project, I am sharing your interest and engagement for improving system integration and software engineering in the Automotive domain.

    I am looking forward to an interesting and inspiring discussion, regards,
    Klaus

  3. Andy Gryc says:

    Hi Klaus,
    Great feedback–I remember finding out about Franca when it was still in early concept, but haven’t been back in a long time. Definitely it sounds like I need to check out the progress! Thanks very much for the tip.
    –Andy

  4. Taylor Wu says:

    Great article Andy. Having manage integration with OEMs and Tier1 suppliers for years, I share the attest to it.

    IMO, the way which OEMs and suppliers build these systems are sometimes unnecessarily complicated for what seems to be very trivial use cases. Exercising a simple end-to-end function would go through a code path of 7 or 8 different modules from as many suppliers. All with their own libraries, state machines, wrappers and custom translation code typically done to solve incompatible interfaces during integration time. This will get worst with connected cars with a hybrid cloud and embedded architecture. Debugging is often done through exchanging logs via email which takes days or even weeks if suppliers are of different time zones.

    Until OEMs take a completely different approach, meaning carefully assess the entire technology stack and it’s implications to build, integrate, test and maintain the end-to-end system, there will be no single tool that can validate everything.

    Tesla I think is doing it right, their software stack resembles that of a smart phone ecosystem, which we know is simple integrate based on their ability to do OTA updates. This is the new standard by which OEMs need to think about how their infotainment and telematics systems should work.

    Just my 2 cents

    Taylor

Trackbacks

Check out what others are saying about this post...
  1. […] CCE Conference Director Andy Gryc outlines the 11 changes and steps that will have to happen to make sure all of the software in a vehicle can communicate seamlessly in the connected world of tomorrow, over at John Day’s Automotive Electronics. […]

  2. […] as long as they have Internet connectivity. This is why researchers and developers have started looking for ways to integrate such technology to vehicles and see just how much this would impact the overall […]

  3. […] distracted drivers a danger to themselves, passengers, and other motorists, applications need to be smarter and more intuitive. Apps need to reduce the time drivers spend not only completing a particular task but thinking […]



Speak Your Mind

Tell us what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!