Making Connected Cars Work. The Next Dimension of Automotive Development.

Share this post

Automotive Development.

From product development’s point of view, a passenger cars certainly have always been one of the bigger challenges. In contrast to the majority of other product categories, their customer relevant functions and properties (e.g. agility, passive safety, cabin comfort or exterior and interior design) are not fulfilled by one specific vehicle component (such as engine, body, seats, drivetrain or chassis), but by a complex interplay of mostly all these components. Over time however, the boundaries of the automotive system to be considered during development have gradually expanded.

Level 1: When cars were just cars. The classic art of complete vehicle integration.

Development of a premium passenger has always been carried out as a sequence of development cycles. Starting from the initial vehicle concept, each of these cycles included dimensioning and designing the components, testing and optimizing them using virtual or real prototype parts, and then merge them into a complete vehicle – again virtual or real – in order to test and optimize it. This vehicle integration process includes the proper positioning of all components within the complete vehicle in consideration of available space and required clearance (so-called geometric integration), validating manufacturability (so-called production integration) and last not least ensuring the desired vehicle properties and functions mentioned above (so-called functional integration).

Both the electric components (such as lights, window lifters or power steering) and the very few electronic devices (such as engine control units, navigation systems or anti blocking systems) were separate systems, sharing power supply but running independently. The conventional cars that came out of this first level vehicle development process were highly integrated and optimized “systems of electromechanical components”.

Level 2: System integration. How to develop computers on wheels.

This approach proved itself very apparently insufficient when after the millennium premium automakers made almost every component software controlled and interlinked all these electronic systems to a “system of systems”, however without including proper validation of the electronic functionality in their development processes. As a result, these systems lacked the appropriate technical maturity, and early customers regularly despaired of the rather unpredictable behavior of their vehicles. Especially the luxury class flagships, filled up to the roof with the latest electronic features, surprised their owners by suddenly and unexpectedly opening windows and sunroofs, switching wipers on and off, or stalling the engine.

To quickly come out of this rather embarrassing (and costly) situation, automakers hurried to enhance their existing vehicle integration process by a system integration process to comprehensively validate hardware and software together – first on component level, then on domain level, and eventually on complete vehicle level. While control software changes on component level had typically been executed uncontrolled before, they now had to abide by a strict release process that led to thoroughly validated hardware-software sets (so-called integration levels). Ultimately, the desired system reliability of this “computer on wheels” was secured before the car left the manufacturing plant and was handed over to the customer.

Level 3. Connected cars. Things in the internet of things.

Even though no one never called it so, car radio was the first data based feature provided in vehicles. Having a working component installed was not enough, a car radio could only fulfill its duty, when broadcast stations continuously provided their service. And just like carmakers never had a contract with filling stations obliging them to deliver fuel and oil, they just trusted in the radio stations to keep on delivering appropriate data.

Decades later, data transmission in the other direction, namely from the car to a backend system, was used to indicate imminent service requirements. First via diagnosis cable, then via mobile internet connection. But as these teleservices apply to manufacturers or dealers rather than customers, their reliability has been considered rather uncritical, and their development went not as part of but in parallel to the vehicle development.

However, when data based vehicle features (such as audio streaming, traffic flow information or remote control via smart phone) are rendered to customers, they must be developed as a part of it. But in addition to the electronic systems on-board the vehicle, these data based features also require off-board elements, i.e.:

  • Data provider delivering the required data (e.g. traffic flow or weather conditions).
  • One or more backend servers, where this data is collected, stored and if necessary processed.
  • A mobile network to exchange data between cars and backend servers.
  • Additional connected systems that exchange data with backend servers or cars (e.g. smartphone apps or internet portals).

By this expansion of the system boundaries, cars become connected, become “things in the internet of things”. To ensure its functionality, first of all the respective development process must cover these off-board elements. Then, just like for any other component, quality criteria for data and their provision process must be defined:

  • Data availability: Data must be generated, transmitted and aggregated in a reliable and timely manner. Providing e.g. 10 minutes old data in a traffic flow information system makes it useless at that time and certainly leads to major customer dissatisfaction. Responsibility for data availability lies with data providers, but also with mobile network and backend operators.
  • Data quality: Getting stuck in a traffic jam in a road that was indicated free by the traffic flow information system or realizing that the parking structure the connected parking system has guided you to is fully booked are only two examples for what can happen to the customer if data is available but of poor quality. Here, responsibility lies with data providers.

To safeguard proper function of data based features, the automotive development processes for connected cars must include the appropriate methods, sub-processes and milestones that ensure robust provision of functional data for as long as the respective data based feature is used.

From producer to service provider. The almost unnoticed transformation.

The truly radical change for automakers though stems from the fact that in contrast to conventional vehicle functions, where their job is normally done when the car passes end-of-line inspection at the manufacturing plant, dependable operation of connected cars and their data based functions requires permanent efforts and support over the whole vehicle lifespan. For manufacturers, it is not sufficient anymore to hand over cars and – if required – provide repair and maintenance services, their role now includes continuously operating the vehicle’s features.

This is especially true for autonomous vehicles. In order to safely steer through traffic under all possible conditions, their control systems (which can be considered the most complex data based automotive feature by far) must continuously exchange a tremendous amount of data with their backend, and someone (i.e. the manufacturer) has to ensure that this functions safely and reliably.

At the end of the day, organization and processes must adapt to that transformation. As interaction with the vehicle increases “after sales”, companies have to clarify responsibilities for the ongoing operations of data based features as well as the management of their quality. The classic silo structure – development, production, sales and aftermarket – does not seem to be the right answer here anymore.

First published on LinkedIn on 8. October 2020

Posted in Article and tagged , , , , , , , , .

Leave a Reply

Your email address will not be published. Required fields are marked *