Export ARXML and Generate C++ Code from AUTOSAR Adaptive Software Architecture

R2026b

In a single build action, you can export ARXML descriptions of compositions and components as well as generate algorithmic and service C++ code from an AUTOSAR Adaptive software architecture. You can build an AUTOSAR Adaptive software architecture model in these ways:

From the Modeling toolstrip, in the Share section, click Generate Code and Export ARXML.
Programmatically by using the slbuild function.

This example is part of a tutorial for developing AUTOSAR Adaptive software architectures. Navigate to a folder containing the supporting files required for this example by entering this command in your MATLAB^® Command Window:

openExample("autosarblockset/AuthorAUTOSARBrakeControlExample");

When you build an AUTOSAR Adaptive software architecture the software generates these outputs in a generic folder structure. The software saves build outputs in a folder with the same name as the software architecture model, in this example, the software saves the build outputs to folder my_adaptive_BrakeControlSystem/. This folder contains subfolders for each referenced software component model and its generated artifacts, in this example: Actuator/, Controller/, Sensors/, and Speedometer/. Alongside the software component, exists a stub/ folder containing files that describe the machine manifest and deployment configuration for the software architecture.

The software also saves the exported composition ARXML descriptions that describe AUTOSAR software composition corresponding to the software architecture, the AUTOSAR Adaptive Service Interfaces, data types, and build and deployment configurations. The exporter automatically creates an Architecture Export report that you can use to view the exported ARXML files. For example, view the SERVICE-INTERFACE definitions and the associated namespace configurations for the software composition by selecting my_adaptive_BrakeControlSystem_interface.arxml.

Architecture Export Report, my_adaptive_BrakeControlSystem is the current model, my_adaptive_BrakeControlSystem_interface.arxml is selected and contents displayed.

The exported ARXML composition files include descriptions of the software architecture, including its interfaces and data types, and any software compositions defined within the architecture model.

ARXML Composition Files	Contents
`my_adaptive_BrakeControlSystem_composition.arxml`	AUTOSAR software composition describing connections between components and compositions as they are modeled in the software architecture.
`my_adaptive_BrakeControlSystem_interface.arxml`	AUTOSAR Adaptive Service Interface definitions including the port interfaces defined in the data dictionary: `BrakeInterface`, `SensorInterface`, and `SpeedInterface` with their C++ namespace configurations.
`my_adaptive_BrakeControlSystem_datatype.arxml`	Data type definitions used across the architecture.
`Sensors_composition.arxml`	ARXML software composition description for the `Sensors` composition.
`stub/MachineManifest.arxml`	Defines execution machine, its mode declarations, process-to-machine mappings, and diagnostic logging and tracing configurations for each component referenced by the composition.

The exported ARXML software component descriptions are exported alongside their execution and service instance manifest files. This table shows the ARXML files exported for each AUTOSAR Adaptive software component, as well as the corresponding JSON file which is generated for each instance of an AUTOSAR Adaptive software component. For example if you have two Adaptive Component blocks that reference the same software component model then only one set of ARXML files is generated for the referenced software component, while a JSON file is generated for each Adaptive Component block that references that model.

ARXML Component and Manifest Files	Contents
`modelName_component.arxml`	ARXML descriptions of each adaptive software component, including AUTOSAR Adaptive Service Interface definitions with ports and events.
`modelName_ExecutionManifest.arxml`	Application service interface and deployment configurations. Consistent with `ExecutionManifest.json`
`modelName_ServiceInstanceManifest.arxml`	Defines the SOME/IP or DDS service communication bindings. Consistent with `ServiceInstanceManifest.json`
`componentBlockName/ExecutionManifest.json`	Application service interface and deployment configurations. Consistent with `ExecutionManifest.arxml`
`componentBlockName/ServiceInstanceManifest.json`	Maps each port to its middleware configuration, including service IDs, event IDs, eventgroup IDs, and QoS settings. Consistent with `ServiceInstanceManifest.arxml`
`componentBlockName/vsomeip.json`	SOME/IP middleware binding configuration.

The JSON manifest files configure how each component deploys to a target machine. You can customize these files for your specific network topology and middleware configuration without modifying the algorithmic code. The execution manifest defines the run-time identity of each component. It specifies the process name, application ID, log mode (console, file, or network), and a log description string. The AUTOSAR Adaptive platform uses these values to manage application lifecycle and diagnostic logging.

The service instance manifest maps the architecture-level port connections to concrete SOME/IP service bindings. For the Actuator component, the Velocity required port is bound to service ID 26020 with a getCurrentVelocity method, and the BrakeCmd provided port is bound to service ID 11255 with a Cmd event. This is where the architecture port BrakeCmd from the architecture model becomes an addressable network service. For example, this is the JSON description of architecture port BrakeCmd.

  "ProvidedPorts": [
    {
      "Name": "BrakeCmd",
      "InstanceSpecifier": "adaptive_ActuatorSWC/adaptive_ActuatorSWC_RootSwComponentPrototype/BrakeCmd",
      "InstanceID": "11255",
      "CommunicationMiddleware": "SOMEIP",
      "ServiceID": "11255",
      "MajorVersion": 0,
      "MinorVersion": 0,
      "SOMEIP_EventGroupID": 11255,
      "Data": [
        {
          "Name": "Cmd",
          "SOMEIP_EventID": 58740
        }
      ],

The vsomeip configuration completes the deployment picture with transport-level details. It specifies the unicast address (127.0.0.1 for local simulation), assigns the application a hex ID, defines services with reliable or unreliable transport ports, and maps events to event groups. You would modify these values when deploying to real hardware with multiple ECUs on a network. For more information about deploying AUTOSAR Adaptive software applications to specific hardware, see Deploy AUTOSAR Adaptive Application on Linux ARM64 Machine (Embedded Coder).

The build process generates C++ code that separates algorithmic logic from service code. The services header file declares the communication functions that bridge between the two layers. For the Actuator component, these are: get_Brake_Cmd (receives brake commands), set_BrakeCmd_Cmd (sends brake commands), and call_Velocity_getCurrentVelocity (calls the speedometer service). These functions are called by the algorithm code while their implementations exist in the generated service code. For example, in services header file adaptive_ActuatorSWC_services.h it contains declarations of the receiver, sender, and client service interfaces in the model.

/* receiver service interfaces */
extern SlSignalStatus get_Brake_BrakeCmd(bool *Brake_BrakeCmd_value);
extern SlSignalStatus get_Brake_Cmd(bool *Brake_Cmd_value);

/* sender service interfaces */
extern void set_BrakeCmd_BrakeCmd(bool rtu_BrakeCmd_BrakeCmd_value);
extern void set_BrakeCmd_Cmd(bool rtu_BrakeCmd_Cmd_value);

/* client service interfaces */
extern SlSignalStatus call_Velocity_getCurrentVelocity(double *velocity);

The algorithmic code uses these service interface functions and has no knowledge of SOME/IP service IDs, transport ports, or network addresses. This separation means you can retarget the deployment configuration by changing service IDs, changing the configured middleware, moving to different hardware, or switching to a different target platform such as Embedded Linux without changing the algorithmic code.

Export ARXML and Generate C++ Code from AUTOSAR Adaptive Software Architecture

See Also

Topics