Use digital threads to link software and hardware in automotive

The major changes that are coming to vehicle design, such as AI for driver assistance on the way to full automated driving and electrification, are having knock-on effects on the way the electronic systems that control these systems are architected and designed.

In older generations of vehicle, it was reasonably straightforward for vehicle OEMs to outsource the development and production of subsystems to external suppliers. Braking, steering and infotainment systems are, in traditional vehicles, reasonably self-contained. But the emphasis is now on advanced applications that call on many different subsystems around the vehicle. Lane-position control, for example, needs input from multiple sensors mounted around the vehicle and the control system may need access to functions such as braking, acceleration, and steering, depending on how much control of the vehicle the application is allowed to take.

A white paper recently published by Mentor, a Siemens business, describes the issues vehicle OEMs and vendors in their supply chains face and potential solutions, summing up the core problem: “It is essential that the system context is considered across entire embedded software application development process.”

The development team for each application or feature needs to take account not just of the software lifecycle but how it interacts with the hardware platform. As schedule are compressed by competitive pressures, there will often be changes to sensor and actuator subsystems in addition to the ECUs needed to run the application code. Software needs to reflect the reality of these changes to ensure that problems are not left for later integration, when fixes become far more expensive.

The concept of the “digital thread” is important here. As the Mentor authors point out: “A common digital thread connecting software and physical systems together is the only way to take control of the increasing complexity of smart and connected products.”

The digital thread will “enable a closed-loop behavioral representation of a vehicle’s software and hardware systems for continuous validation throughout the product lifecycle. A robust digital thread will help engineers ensure that software features are fully compatible with the vehicle in which they are deployed and complete with evidence showing that all related tasks and deliverables are available on time. The digital thread will also track accountability for changes regarding not just who, but how and why”.

A tool that facilitates the management of the digital threads that make up the vehicle is Polarion, which is designed to “create a direct link between system-level changes and application development, ensuring the project and the overall system stay in sync”. Under Polarion’s control:

“The system-level definitions and hardware constraints are codified into system-level requirements and specifications. Software engineers can then decompose the needed mix of hardware and software requirements, noise factors, failure modes and effects analyses (FMEAs), test-cases, goals and begin embedded software application-level definitions and planning. During planning, software teams can assign tasks for modeling, coding, test-execution, build production, and more across the needed toolsets. At any given time, software engineers can peek into the system-level definitions and constraints and collaborate with other system users, or be notified if there are system-level changes to evaluate software-level impacts.

”The creation of, and any subsequent changes to, detailed software requirements will trigger software architecture and modeling changes. With the requirements, software engineers can update these models to align with control algorithms. Software engineers now execute detailed model-in-the-loop (MiL) tests to verify and validate that desired outcomes are achieved at the application and system-level before any code-level changes are triggered. This allows engineers to discover critical risks, issues and defects while staying aligned with system-level directives early in the process.”

As well as ensuring consistency between software and hardware overall, the software engineers need to ensure that each software build is delivered to the correct vehicle variant – and support the management of over-the-air updates to each of these variants when they are on the road. This is another aspect of Polarion-based management covered in the white paper.

The white paper shows an example of a typical flow, in this case for that of an adaptive cruise control module, when a change is required and how the information moves between each of the affected subsystems. The connection made possible by linking development to product life-cycle management ensures that the information is conveyed automatically and so reduce the possibility of mismatches making it to final integration just ahead of production. The white paper goes on to describe how the approach can also facilitate agile methodologies in concert with ISO26262-compliant processes so that manufacturers can continue to reduce development cycle times without compromising safety.