AUTOSAR Interfaces, Ports and Runnables: Modelling a Window-Lift ECU

The problem

Every AUTOSAR project starts with an architecture of components, interfaces and ports described in ARXML, and new engineers often struggle to connect these abstract elements to real behaviour. A window-lift ECU is simple enough to understand completely but still needs several components, interface types and events, which makes it a good first AUTOSAR design exercise.

Objectives

• Decompose a window-lift function into AUTOSAR software components.
• Choose sender-receiver and client-server interfaces for each connection.
• Define ports, runnables and their triggering events.
• Generate ARXML and identify each element in it.
• Check the ARXML automatically with a script.

What you need

Key concepts

Port prototypes

Provider (P) ports offer data or services; receiver (R) ports use them. Each port is typed by an interface.

Client-server interface

An interface of operations with arguments, like a function call between components, used here for storing and reading the window position.

RTE events

Events that trigger runnables: a timing event for periodic work, a data-received event when new data arrives, or an operation-invoked event when a server operation is called.

ARXML

The AUTOSAR XML format that describes software components, interfaces, data types and system configuration in a tool-independent way.

Step-by-step guide

1. 1

   Write the window-lift requirements

   List the functions: move the window up or down while the switch is held, one-touch up and down on a long press, stop at end positions, reverse on pinch detection during upward motion, and remember the window position across power cycles. Define inputs such as switch state, motor current and a position sensor or hall counts, and outputs such as motor direction and enable. Number each requirement.

   Checkpoint: A numbered requirement list with inputs and outputs and their ranges.

2. 2

   Decompose into components

   Split the function into three or four application components: SwitchInput, which debounces and classifies switch presses; WindowCtrl, which holds the main state machine; AntiPinch, which evaluates motor current against a position-dependent threshold; and MotorActuator, which turns commands into direction and enable signals. Add a position storage service as a client-server connection. Draw the component diagram with every connection and justify each split in one sentence.

   Checkpoint: A component diagram with every connection labelled and the reason for each component.

3. 3

   Choose interfaces

   For each connection choose the interface type. Use sender-receiver interfaces for switch requests, pinch detected, motor command and position, with data elements of suitable types such as an enumeration for switch request and uint16 for position. Use a client-server interface with operations such as StorePosition and ReadPosition for the position storage service. Write each interface with its data elements or operations, types and units.

   Checkpoint: An interface table giving type, elements or operations, data types and units for every connection.

4. 4

   Define runnables and events

   For each component define its runnables and what triggers them: SwitchInput every 10 ms by a timing event, WindowCtrl every 10 ms, AntiPinch every 5 ms for fast reaction, and a WindowCtrl runnable triggered at shutdown that calls StorePosition. Decide which runnables read and write which ports. Note why the anti-pinch check needs a shorter period, linked to motor speed and the maximum pinch force reaction time you assume.

   Checkpoint: A runnable table with triggers, periods and port accesses for every component.

5. 5

   Model the components

   Create one Simulink model per component and configure each as an AUTOSAR component with the Quick Start. Implement simple behaviour: a debounce counter in SwitchInput, a Stateflow chart with idle, moving up, moving down, one-touch and reversing states in WindowCtrl, and a threshold comparison in AntiPinch. Use the AUTOSAR Dictionary to set interface, port and runnable names exactly as in your tables, and model the client-server call with a Function Caller block.

   Checkpoint: Each component model simulates, and its AUTOSAR Dictionary matches the interface and runnable tables.

6. 6

   Generate and read the ARXML

   Generate ARXML for every component. Open the files and find each element type: AR-PACKAGE, APPLICATION-SW-COMPONENT-TYPE, P-PORT-PROTOTYPE and R-PORT-PROTOTYPE, SENDER-RECEIVER-INTERFACE with its VARIABLE-DATA-PROTOTYPE, CLIENT-SERVER-INTERFACE with its OPERATION, SWC-INTERNAL-BEHAVIOR with RUNNABLE-ENTITY and TIMING-EVENT, and the data access points. Annotate one file by hand, linking each element to your design tables. Note how elements refer to each other by short-name paths, such as a port referring to its interface, because broken references are a frequent integration error.

   Checkpoint: An annotated ARXML excerpt where every element is linked to a row in the design tables.

7. 7

   Check the ARXML with a script

   Write a Python script with lxml that reads all ARXML files, handles the AUTOSAR XML namespace, and lists components, ports with their interfaces, runnables with their events and periods, and data accesses. Add checks: every R-port has a matching P-port of the same interface somewhere in the set, every runnable has a trigger and no interface is defined twice. Report problems with the element path.

   Checkpoint: The script prints a summary of the architecture and reports no errors on the final design.

8. 8

   Inject and catch errors

   Make deliberate mistakes in copies of the ARXML: change one port's interface reference, delete a timing event, and give two interfaces the same short name in one package. Run your script and confirm it detects each one with a clear message. Also validate the files against the AUTOSAR XML schema with an XML validator if you have the schema. This shows why automated checks matter in real projects with thousands of elements.

   Checkpoint: Each injected error is reported by the script with the element path.

9. 9

   Document the architecture

   Write a short architecture document: requirements, component diagram, interface and runnable tables, an annotated ARXML excerpt and the checking script with its results. Explain how this architecture would continue in a real project: a composition connecting the components, mapping to an ECU, RTE generation and basic software configuration in tools such as Vector DaVinci or EB tresos. Provide all models and files.

   Checkpoint: An architecture document with design tables, ARXML excerpts and the checking script.

Testing & validation

• Design tables consistent with the AUTOSAR Dictionary in each model.
• Generated ARXML containing every designed element.
• Script reports no errors on the final design.
• Script detects each injected error.

Expected results

A window-lift ECU architecture in AUTOSAR Classic with generated ARXML, an annotated walk-through of its structure and a script that checks its consistency.

Take it further

• Build a composition connecting the components and simulate it end to end.
• Add a mode-switch interface for the vehicle power mode.
• Map the composition onto two ECUs and define the CAN signals between them.
• Extend the checking script to report architecture metrics.

Viva and review questions

Learn it at DIYguru

These DIYguru courses and programmes teach what this project needs.