The problem
Vehicle ECUs are built from AUTOSAR software components supplied by different teams, and much of that application software is designed in Simulink. Engineers must know how a model becomes an AUTOSAR component, which ARXML it produces and how generated code talks to the runtime environment. This project goes through that workflow on a small, realistic EV function.
Objectives
- Specify an application software component with inputs, outputs and timing.
- Model its behaviour in Simulink and test it in simulation.
- Map the model to AUTOSAR elements with AUTOSAR Blockset.
- Generate ARXML and C code and explain their structure.
- Verify generated code against the model with SIL tests.
What you need
Tools and toolboxes
- Simulink and Stateflow — Behaviour model of the coolant pump controller.
- AUTOSAR Blockset — AUTOSAR Component Quick Start, AUTOSAR Dictionary and Code Mappings editor.
- Embedded Coder — Generating AUTOSAR-compliant C code and ARXML.
- Simulink Test — Test harness and SIL back-to-back comparison.
Software
- MATLAB, Simulink, Stateflow, AUTOSAR Blockset, Embedded Coder and Simulink Test
Extra parts and data
None beyond the software above.
Key concepts
- Software component (SWC)
- The AUTOSAR unit of application software. It communicates only through ports, so it can be placed on any ECU without changing its code.
- Sender-receiver interface
- An interface carrying data elements from a provider port to receiver ports, used here for temperatures and the pump command.
- Runnable
- A function inside an SWC that the runtime environment calls, triggered by events such as a periodic timing event.
- RTE
- The runtime environment generated for each ECU. The SWC calls Rte_Read and Rte_Write functions instead of accessing signals or buses directly.
Step-by-step guide
- 1
Specify the component
Write a specification for a CoolantPumpCtrl component: inputs are battery temperature, motor inverter temperature, coolant temperature and vehicle state; outputs are pump duty in per cent and a pump fault flag. Behaviour: off below a threshold, proportional duty with hysteresis above it, full duty above a limit, and a minimum run time after shutdown when hot. It runs every 100 ms. Give every input and output a unit, range and resolution.
Checkpoint: A specification table of ports, data types, ranges and timing, plus numbered behaviour rules.
- 2
Build the behaviour model
Model the logic in Simulink: take the maximum of the temperature demands, compute duty from a 1-D lookup table, add hysteresis with a Stateflow chart for off, running and after-run states, and rate-limit the output. Use explicit data types such as single for temperatures and uint8 for duty. Keep the top level clean with one inport per input and one outport per output, since these become AUTOSAR ports.
Checkpoint: The model simulates with test inputs and its outputs follow the behaviour rules on hand-checked points.
- 3
Create test cases
Build a test harness with Simulink Test and write test cases for each behaviour rule: rising and falling temperature ramps across the thresholds, a hot shutdown that triggers after-run, an implausible sensor value and a fast temperature step. Add assessments for duty values, hysteresis widths and timing. Run the tests on the model and keep the results as the MIL baseline for later comparison with generated code.
Checkpoint: All test cases pass on the model and each behaviour rule is covered by at least one test.
- 4
Create the AUTOSAR mapping
Use the AUTOSAR Component Quick Start to configure the model as an AUTOSAR application component. Open the Code Mappings editor and map each inport to a receiver port and data element, and each outport to a sender port, using access modes such as explicit send and receive. Map the model's periodic step to a runnable triggered by a 100 ms timing event. Check the mapping for every port.
Checkpoint: The Code Mappings editor shows every inport and outport mapped, with the runnable on a 100 ms timing event.
- 5
Refine the AUTOSAR Dictionary
Open the AUTOSAR Dictionary and rename generated elements to meaningful names: interfaces such as IfTemperature and IfPumpCmd, ports such as RpBattTemp and PpPumpDuty, and the runnable as CoolantPumpCtrl_Run. Set the package paths for interfaces, data types and components according to a simple naming convention. Define application data types with units and compu methods where your release supports it, so the ARXML carries physical meaning.
Checkpoint: The dictionary uses consistent names and packages, documented in a short naming convention.
- 6
Generate code and ARXML
Build the model with Embedded Coder. Inspect the generated ARXML files: the component description with its ports and internal behaviour, the interface definitions, the data types and the timing. Inspect the C code: the runnable function, the Rte_Read and Rte_Write calls generated for each port, and the RTE header stub used for compilation. Draw a diagram that links model inports, ARXML ports and RTE calls.
Checkpoint: A diagram tracing each model port to its ARXML element and its RTE call in the code.
- 7
Verify with SIL
Run the test cases in SIL mode, which compiles the generated code with RTE stubs on the PC and runs it in the harness. Compare SIL outputs to the MIL baseline with tolerances chosen from data type resolution. Investigate any difference, for example rounding when converting to uint8. Record the code size and the number of RTE calls per runnable execution.
Checkpoint: SIL outputs match the MIL baseline within the stated tolerances for every test case.
- 8
Round-trip the ARXML
Import the generated ARXML into a fresh Simulink model with arxml.importer and createComponentAsModel to check that the description is complete and consistent. Compare the imported skeleton's ports and runnable with your original. Note how this round trip mirrors industry practice, where an architect delivers ARXML from a tool such as Vector DaVinci Developer and a function developer fills in behaviour in Simulink.
Checkpoint: The imported model has the same ports, interfaces and runnable timing as the original component.
- 9
Document the component
Write a component description covering the specification, model structure, AUTOSAR mapping, naming convention, generated artefacts and test results. Include the traceability diagram from step 6 and a short note on what would happen next in a real project: integration into a composition, RTE generation for an ECU and configuration of the basic software. Provide the model, tests and generated files.
Checkpoint: A component document and package that another student could integrate into a composition.
Testing & validation
- MIL tests covering each behaviour rule.
- Complete port and runnable mapping in the Code Mappings editor.
- SIL outputs equal to MIL within tolerance.
- ARXML round-trip producing a consistent component skeleton.
Expected results
A tested AUTOSAR Classic application component with generated ARXML and C code, traceable from specification to RTE calls.
Take it further
- Add a client-server port for reading calibration values.
- Run the generated runnable on the STM32 kit with a hand-written RTE stub.
- Add a second runnable triggered by a data-received event.
- Integrate the component into a thermal-management composition.
Viva and review questions
Why does the component use Rte_Read instead of reading the CAN signal directly?
Going through the RTE keeps the component independent of where the data comes from, so it can be moved to another ECU or bus without code changes.
What triggers your runnable?
A timing event every 100 ms, which the RTE maps to an operating system task on the ECU.
What is in the generated ARXML?
The component type with its ports and internal behaviour, the interface definitions, the data types and the runnable with its events.
Learn it at DIYguru
These DIYguru courses and programmes teach what this project needs.