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

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

Man does not come from A to B on data alone. The unbroken importance of automotive development in a world focused on digitalization.

In terms of future mobility, digitalization may be key for advanced vehicle features, online fleet control, and digital mobility services, but an in-depth expertise in software and data alone is certainly not sufficient. At the end of the day (if you don’t want to walk), you need a physical motorized vehicle which – regardless of whether it is a passenger car, a minivan or a bus, whether it is owned or shared, and whether you are the driver or a passenger -someone has to develop and manufacture.

Developing especially a premium passenger car is still an amazingly complex process. It starts with transforming the full bandwidth of customer, legal and economic requirements into a harmonious, consistent and competitive complete vehicle concept, followed by breaking this down and designing thousands of hard- and software pieces, merging them again into a complete vehicle, and ends with testing and validating the this vehicle, sometimes again and again.

While chatting with me about this, one of my former Automotive Engineering students at Clemson University mentioned that my textbook Automotive Development Processes – Processes for Successful Customer Oriented Vehicle Development would still be her “bible” when it comes to holistically understanding the interlaced work streams of complete vehicle development. Slightly flattered, I took my dusty copy out of the shelf and examined critically what I had compiled 11 years ago. My findings: Then, I didn’t even mention autonomous driving, and it seems that my confidence in the further development of high voltage batteries and thus the future of electric drivetrains in general was strongly limited. But while design and testing methods have certainly improved over the years in all areas of R&D, and especially agile techniques have brought the development of mechatronic systems to a new level, the overall approach of transforming customer expectations, market demand, regulatory framework and innovative technologies into product strategy, concepts and architectures, and then closely monitoring the desired complete vehicle properties during hardware and software development has not changed much ever since.

The fine art of conducting the highly sophisticated orchestra of the involved processes – from body design and crashworthiness to ECU programming and E/E system integration, from interior styling and cabin comfort to engine design and emission control, from spring-damper-system configuration and agility to connectivity and theft deterrence – is still the indispensable basis for successful complete vehicle development and compiled in this textbook.

And when we master these basics, it makes sense to go ahead with digitalization …

Share this post