Application Delivery and Monitoring

This is part seven of a seven-part series on the growing importance of automotive software. Click here to read part one. You can also download our whitepaper, or visit siemens.com/aes to learn more.

Vehicle electrification, connectivity, automation, and shared mobility are driving a need for remarkably sophisticated software to enable features like advanced driver assistance systems (ADAS), battery management, vehicle-to-everything (V2X) communication, and more.

Each of these features requires a combination of complex software applications to operate, resulting in a massive increase in the complexity of in-vehicle software overall. As software engineers wrestle with the sophistication demanded of individual applications, they must also manage the configuration and calibration of these applications to match each vehicle variant. Each application configuration has to be deployed to the correct vehicle variant with the correct calibration for that variant.

But, configuring and deploying applications and software builds to each variant is not the only challenge. Latent bugs or issues may occur in field-operational vehicles, requiring the OEM to identify and resolve the issue as quickly as possible.

Application delivery and monitoring processes supply the final software to the vehicle structure and maintain them after delivery (figure 1). Common issues and pain-points that arise during this phase of development include:

• Last minute changes. Maintaining control over these changes, with a complete record of the need for the change, is critical and often ignored.
• Cross-domain changes. Last minute changes are not just a software issue; electrical systems, mechanical systems, and others frequently encounter design changes even after all the reviews and sign-offs are complete.
• Application configuration management. Vehicle platforms spawn dozens of discreet vehicle variants with a mix of shared and unique features, components, and embedded hardware. The software domain has to configure builds to match each of these variants.

Coordinating the delivery and monitoring of embedded applications

Today’s solutions have integrated test management tools to help create test cases and link them to corresponding work items such as requirements, change requests, other test cases, and more. The steps for each test procedure can be customized to separate a test specification and test items configuration so engineers can replicate test procedures to fully cover complex test conditions.

​Process knowledge is accessible directly in the project to ensure that all team members comply with specified processes, even if they have not memorized a process’ details. The solution can also automatically create bug reports and tasks for developers based on test failures to shorten the time to resolution. Finally, these solutions ensure extensive test coverage, execution, and results reporting across various abstractions, virtual and hardware based, and on-track testing for complete verification and validation of an application. 

Along with testing, the engineers need to assign and deploy the fully verified and validated software builds to specific product BoMs under hardware and system configuration constraints. All the while the engineers must try to reduce the cost of regulatory compliance and lower product fault risk.

​Modern solutions help by automating and streamlining the generation and organization of data. Test runs can be initiated automatically when a new build is released. These solutions can also accelerate the deployment phase by maintaining a repository of previous builds. With this baseline in place, the engineer only has to download changes, rather than an entirely new build, to make updates.

Software application design, however, is becoming less dependent on the hardware on which the application will run. As a result, it is very challenging to manage the compatibility between automotive embedded software applications and specific product variants without direct links between application builds and product BoMs. PLM integration allows software engineering teams to identify and visualize the impacts of hardware-software dependencies and publish data from the application development platform directly to the PLM environment.

Integrating hardware and software lifecycle management enables constant monitoring of where and how each application is being used in the “As-Released” BoM for the physical vehicle architecture (figure 2). The application usage can also be traced from the “As-Released” BoM down to the “As-Built” BoM, for vehicle assembly, and the “As-Serviced” BoM for updates in the field.

Throughout the application development, delivery, and monitoring, the embedded application development platform can connect with various tools to provide code performance coverage data, and to ensure alignment with methods and coding standards such as MISRA-C. As software engineers monitor the deployed software, traceability from the individual product all the way to the concept level requirements, specifications, and other data artifacts enables quick re-engineering response. This response is critical to resolving issues that come up in the field, improving consumer safety, and reducing or eliminating warrantee costs from faulty vehicles.

Example: Delivering a combined AEB+ACC module

As software developers commit software code changes in AGILE sprints (from part six), the unified application engineering platform links the code changes all the way back to the new system level requirements from the engineering change notice (ECN) in the PLM solution. The ECN workflow can be configured to lock functions affected by the ECN to prevent late changes from disrupting delivery, while AGILE methodologies help to reduce scope creep.

During testing, test engineers can view relevant data in the vehicle bill-of-materials (BoM), including the software and system requirements for added functions, the logical hardware level, and the part number for the physical ECU. This ensures that system level changes to the ECU models or peripherals (visible in System Modelling Workbench) are easily found.

With the application engineering platform coordinating across tools, issues during testing can be resolved early. For example, a SiL test on a virtual ECU model may return positive results. The same software build may fail some test cases during when using the actual ECU hardware (HiL) and CAN bus for network communication. With cross-tool collaboration, the engineers are able to find and resolve the issue.

With a successful HiL test, the software binary is finalized in the software build. Releasing the software build initiates vehicle-in-the-loop (ViL) testing with links to the hardware and software binary being tested. The ViL test case saved in the application engineering platform also includes test parameters that describe the nature of the test.

The fully verified and validated software build is published to the vehicle BoM. Each physical ECU in the BoM includes a software assembly with the tested software binary part number. In the case of multiple hardware variants, such as low-content and high-content ACCM variants, each physical variant in the PLM environment is associated to a logical ACCM in SMW. In the vehicle BoM, each variant will display a specific part number for the software configuration.

The application development and coordination platform provided key features to software teams delivering builds for the newly combined ACC and AEB features. Built-in tools prevent late-stage code changes to ensure that software delivery proceeds on schedule. Software testing is completed with a clear understanding of what to test, how to test it, and the reasons it needs to be tested. The application engineering platform also ensures that final, fully verified software binary shows up in the correct configured vehicle BoM.

Conclusion

Automotive application development is a multifaceted and challenging process from the initial definitions and planning stage right up to the final hurdle of delivering quality applications, in the right configuration, to the correct vehicle. This feat requires the collaboration of many cross-domain teams and stakeholders. A unified platform for automotive embedded application development and orchestration facilitates collaboration and visibility across disparate domains, including software, hardware, and systems engineering. Such a platform also enables companies to reuse proven software components to accelerate the development of new and varied applications.

To read more, download our whitepaper on application delivery and monitoring. You can also check out the previous blog, or jump to part one in the series, here.

To learn how a unified application development platform can help companies meet functional safety standards, like ISO 26262, please register for our upcoming webinar, Increase automotive functional safety with ISO 26262 compliance.

About the author: Piyush Karkare is the Director of Global Automotive Industry Solutions at Siemens Digital Industries Software. Over a 25 year career, Piyush has a proven history of improving product development & engineering processes in the electrical and in-vehicle software domains. His specialties include integrating processes, methods, and tools as well as mentoring product development teams, determining product strategy, and facilitating innovation.