In brief
- Software integration is especially difficult when it comes to autonomous driving vehicles. Traditional approaches capitulate to the sheer number of components and delivered assets
- Increasingly pressuring market demands make the situation for suppliers and Tier-1s even worse, as they struggle to deliver quality on time
- With model-based systems engineering, software factories and data-driven software development, Luxoft has identified three essential pillars for successful system integration in the area of autonomous driving
Software integration is a complex task. System integration for software-defined vehicles (SDVs) and autonomous driving (AD) is even more complex. With markets and economics becoming ever more pressuring, traditional integration processes reach their limit. In this blog post, we explain why traditional approaches fail in the automotive domain. Then we present three paradigms that can lead toward a successful future of system integration.
Expectations are shifting
What are the AD market trends that are bringing traditional integration approaches to their limit?
- Electrical/Electronic (E/E) architecture is fundamentally changing
Vehicles are becoming computers on wheels. In the past decade, vehicles used numerous single electronic control units (ECUs) that were loosely connected via a communication bus of some sort. When reaching more than 100 ECUs per car, it became clear that this development was a dead-end. Nowadays, a domain controller architecture is used, clustering parts of the car’s architecture into domains — like the ones for chassis, connectivity, infotainment or advanced driving assistance systems (ADAS). These domain controllers typically use a system on chip (SoC) as the main component. In the future, expect to see a shift toward even more centralized zone controllers and the use of one, central, high-performance computer (HPC).
- Economies are taking their toll
Cost-sensitive solutions, a faster time to market and bigger return-on-invest are omnipresent demands. Delivering software faster and with better quality, using fewer resources is like squaring the circle
- Interaction between participants is evolving
Automakers are building up in-house expertise to regain control over the software and hardware development. To achieve this, they establish new ways of cooperation; former mere suppliers become real partners in research and development. Tier-1s and suppliers need to adapt their working models to fit into this new relation model
- Integration is getting more complex
Software and hardware have to work together. Different suppliers deliver different parts of the system’s software (e.g., applications, algorithms, safe operating systems, drivers, hardware abstraction layers and much more). Each software part is designed to run on hardware from different vendors. Building a flawlessly working system is a mammoth task. The whole car becomes a software integration platform
- The complexity gap is increasing
A study by McKinsey1 found that the complexity of software for SDVs has quadrupled over the past 10 years, whereas productivity has grown only by a factor of 1.5. To close this gap, automakers would need a much bigger workforce than they can afford
To become or remain a successful system integrator, you have to manage this increasing complexity. At the same time, you must improve your productivity — and other aspects, like the ease of maintenance and traceability. This is easier said than done, but the following three pillars should help you achieve these goals.
3 pillars for successful integration
More efficient development and integration methods are needed. Luxoft has identified three paradigms that system integrators need to implement if they want to remain successful in the area of AD. These three pillars are the foundation for future success. Here they are:
Pillar one: Model-based systems engineering
Model-based systems engineering (MBSE) is designed to handle complexity in large, intricate systems. The MBSE approach differs from traditional system engineering in the sense that MBSE can be compared to document-based approaches:
- Models and tools are used to address the limitations that isolated data silos and their dependencies have
- Models serve as a central source of truth for system and software information, allowing different domains to access and store their data in one and the same place
- The structured nature of models allows system- and software-engineers to define the system’s structure from top to bottom
MBSE also provides and uses multiple views, or perspectives, of a system. These views show the organization and separation of different aspects of the system, promoting reusability and maintainability. Each view can be developed and updated independently and aligned with iterative development approaches. This iterative development allows for continuous refinement, feedback, validation and adaptation:
- The requirements viewpoint ensures that all necessary requirements are identified and addressed
- The functional analysis viewpoint transforms requirements into a specification, simplifying the understanding and guiding the system design
- The logical architecture viewpoint deconstructs the system and examines its internal structure
- The technical architecture viewpoint focuses on platform-specific realization, ensuring compatibility and efficient implementation
Although MBSE may require more upfront work — such as defining processes and creating precise infrastructure models — the long-term benefits are remarkable: With a well-maintained model you can reuse artifacts across all development levels, detect errors at an early stage and mitigate risks effectively. This all lowers costs. And last, but not least, MBSE also enhances the communication between the participants.
Pillar two: Software factory
A software factory can be defined as a group of software assets that is used to help produce computer software applications or components according to specific end-user requirements. Take our software factory tour here.
Just like in a brick-and-mortar factory, various departments are responsible for their dedicated tasks. The number and tasks may differ, but they always match the purpose of the factory. The goal of a software factory is early cross-domain and end-to-end testing. To achieve that, software is developed with a central testing strategy in mind and stored in a central repository. Testing starts early with software-in-the-loop (SiL) tests, implementing a shift-left testing approach and making tests possible even before the actual ECU hardware is available. Version management ensures that all possible configurations are tested properly.
Pillar three: Data-driven software development
The numerous test drives that are necessary for the verification of AD systems already create huge amounts of data. Why not make use of this data by using it for enhancing software quality and as input for training AI models? That’s data-driven software development. But, instead of just collecting and building huge amounts of data, it’s better to focus on sensible and useful data for development and testing. Collecting data for rare and unexpected events is what separates the good from the mediocre integrators. This is not trivial — a whole publicly funded research project, just better Data, set out to enhance this area. And Luxoft, as a consortium member, is part of this endeavor.
To learn more about how to harness data for creating test scenarios with AI, read this blog about Generative AI for autonomous driving.
Get fit for the future
Implementing all these changes is no mean feat, but it promises huge benefits. With all three pillars built up, an improvement in productivity and quality can be expected:
- Maintenance becomes easier with the increased use of reusable software assets
- Virtual testing and validation within the software factory saves time and money. It also makes a shift-left approach possible (testing as early as possible to catch and fix bugs as early as possible)
- Cross-domain accessibility enables an efficient and well aligned development process with reliable reporting
Assess the processes that you have in place today. Are they fit for a future in AD? Luxoft’s advisory team can support with an in-depth analysis. No matter if your integration foundation is missing one or all of the pillars, Luxoft can help you implement, rebuild and strengthen it. Contact us to get started.
Uwe Klaus Brandenburg
As Vice President Autonomous Driving, Uwe is responsible for Luxoft’s advances in the field of autonomous vehicles, AD function development and virtual validation. Before joining Luxoft, he was ADAS Chief Technology Office and Engineering Head, overseeing product and technology road maps and managing autonomous driving projects for global customers. His areas of expertise are the development of ADAS sensors (for mono, stereo and night vision cameras, and radar), domain controllers and complete ADAS systems for highly automated driving.
Andreas Mütsch
Andreas is a technical writer and software developer at DXC Luxoft. As part of the solutions team, he is responsible for the accuracy and reliability of technical articles and documentation. As a software developer, he helped to bring several generations of in-car infotainment systems to market. His mission is to close the gap between writing and coding in technical projects. Andreas holds a degree in applied physics. In his private life, he is the author of several books and an award-winning self-publisher.
