In addition to decoupling the aftertreatment system software and hardware, KPIT’s client needed to add new features to the system. They also needed to address drawbacks with their existing development workflow, which was based on writing embedded C code by hand. In this workflow, engineers had few opportunities to validate system requirements until well into the project, when the requirements could be tested on the electronic control unit
(ECU). The client wanted to reduce manual coding and verify their designs earlier in development.

At the same time, the client wanted an open, standard automotive software architecture to ensure that the software delivered would be compatible with other software that would run on the same ECU.

KPIT engineers established a software development workflow for their client based on AUTOSAR and Model-Based Design.

In this workflow, engineers began by analyzing system requirements and defining an architecture comprising individual AUTOSAR software components.

Next, the team defined the software requirements of the individual components, using an AUTOSAR authoring tool to set up interfaces and add other configuration details.

Following a top-down approach, the team exported software component description ARXML files from the authoring tool. They imported these files directly into Simulink to create a skeleton Simulink model that contains interface blocks and the AUTOSAR-related settings defined in the authoring tool.

Working in Simulink and Stateflow^®, they elaborated this skeleton model of the application software, adding sequential logic and other blocks to implement new features.

After checking the model for compliance with MathWorks Automotive Advisory Board (MAAB) guidelines, the team ran model-in-the-loop simulations to test the functionality of the design against requirements.

The team generated AUTOSAR-compliant C code together with updated software component description ARXML files using Embedded Coder^® and the Embedded Coder Support Package for AUTOSAR Standard.

They used the generated C code to conduct software-in-the-loop tests, verifying that the results from these tests match the simulation results from the Simulink model.

The team imported the updated ARXML files back into the AUTOSAR authoring tool so that the new application software can be integrated with other AUTOSAR software components before deployment to the ECU.

Using this workflow, KPIT and its client successfully completed the aftertreatment system software, which is currently undergoing final testing. KPIT's client is now using Model-Based Design on other AUTOSAR projects.

• Development time reduced by up to 40%. Model-Based Design with Simulink reduced development time by anywhere from 10% to 40% compared with standard development practices, which are slower due to manual coding and the inability to verify requirements before flashing the ECU.
• AUTOSAR round-trip engineering workflow established. After the interfaces in the AUTOSAR authoring tool were configured, KPIT imported them into Simulink to establish a one-to-one map between software components in the two tools. AUTOSAR-compliant code and component description files was automatically generated from their Simulink models, and the ARXML files were imported into KPIT's authoring tool.
• AUTOSAR implementation streamlined for Model-Based Design. “Our client can now focus on developing their application software and control strategy, because they no longer have to worry about the workflow or tool chain for AUTOSAR,” says Mahesh. “MathWorks has continued to enhance Simulink support for AUTOSAR, and we are confident that any changes to AUTOSAR standards will also be supported.”