Model AUTOSAR Adaptive Service Communication and Execution Behavior

R2026b

To model AUTOSAR Adaptive software component service communication and execution behavior, set the communication, execution, and auxiliary service properties that together define a software component service interface. These properties describe how a software component communicates and executes after you deploy it as an application. When you deploy an AUTOSAR Adaptive application, the service properties you configure for each software component port and element in Simulink® become the services the component provides and the services it requires of its target environment.

To view AUTOSAR ports from an AUTOSAR perspective, AUTOSAR Blockset software creates a corresponding AUTOSAR provided or required port for each software component port in a Simulink model. In the AUTOSAR Dictionary, an AUTOSAR Adaptive Service Interface defines the methods, events, and namespaces for a port. The software validates that the AUTOSAR Adaptive Service Interfaces described in the AUTOSAR Dictionary are consistent with the service properties you configure for each software component port and element in the Simulink model.

In Simulink, you use bus element ports and function ports on the software component boundary to model data-oriented event communication and method communication, respectively.

By default, each port maps to one AUTOSAR Adaptive Service Interface. You can define AUTOSAR Adaptive Service Interfaces with both events and methods, and view and edit them in the AUTOSAR Dictionary. For more information, see Model AUTOSAR Adaptive Service Interfaces with Methods and Events in Simulink.

Model AUTOSAR Adaptive Sender-Receiver Communication and Execution

Event-based data communication between AUTOSAR Adaptive software components occurs when a provider component sends events through provided ports and a consumer component receives those events through required ports. In Simulink, you model event-based data communication as sender-receiver communication by using In Bus Element blocks to receive events and Out Bus Element blocks to send events. Each required port and provided port corresponds to a data port on the software component boundary.

To model AUTOSAR Adaptive sender-receiver communication, follow this general workflow.

  1. Create or open a model configured for the AUTOSAR Adaptive Platform.

  2. Add In Bus Element blocks and Out Bus Element blocks to model receiving events from required services and sending events to provided services. Each bus element port maps to an AUTOSAR required or provided port.

  3. Define the structure of data that passes through a port with Simulink.dictionary.archdata.DataInterface objects. Use the Interface Editor (System Composer) to create, view, and edit these interfaces. Use the Architectural Data Editor to configure C++ namespaces and other port interface or data element code generation properties.

  4. Open the AUTOSAR Component Designer app and Property Inspector. Each receiver port data element has default service properties. In the Property Inspector, when you select a bus element port, you can configure these communication properties:

    • Receiver service — Set to Queued or LatestValue to determine whether a receiver service reads data from a middleware queue or from the most recent value received by the port, respectively. Use Queued when data arrival is buffered and processed in a sequence. Use LatestValue when you only need the most recent valid value.

    • Queue capacity — Specify the maximum number of samples that the middleware queue can hold. To set Queue capacity, set Receiver service to Queued.

    • Initial value — Specify the value used by the receiver before it receives the first valid value from the sender. For example, this value is used if the receiver port is not connected, the sender port is not yet initialized, or is initialized but has not yet sent any data.

    • Status element — Set to <Add Status Element> to add a status element associated with the data element. Status elements allow the software component to detect and handle communication conditions such as data not arriving on time and dropped server connections. The status element uses the built-in Simulink enumeration data type SlSignalStatus to handle communication health.

    • Timeout — Specify the maximum time, in seconds, since the port last received valid data. When the Timeout value is reached, the status element returns SlSignalStatus.TIMEOUT and the receiver holds the last valid value that it received from the sender.

    Similarly, configure these execution properties:

    • On data arrival, execute — Select the function that executes when a port receives data or a timeout occurs. To edit this value, the software component must be an export-function model.

    • Sample time — Set the periodic execution rate. To edit this value, the software component must be a rate-based model.

    Model adaptive_ActuatorSWC, Property Inspector is open Brake port element Cmd is selected. Service tab is selected showing communication and execution attributes for Brake.Cmd, with Receiver service set to Default: Queued, Queue capacity 16, Initial value 0, Timeout set to Inf. On data arrival, execute is set to OnBrakeCommand.

  5. Prepare your model for AUTOSAR code generation with the AUTOSAR Dictionary. In the AUTOSAR Dictionary, you can configure options for ARXML export, such as single file or modular file export, package paths, platform type packing, customizations for implementation data type referencing, data constraints, and software calibration access default values. For more information about configuring ARXML export with the AUTOSAR Dictionary, see Configure AUTOSAR Adaptive XML Options.

  6. Build the software components and deploy them to a POSIX-based target environment.

  7. Verify generated code with software-in-the-loop (SIL) simulations.

For more information about modeling AUTOSAR Adaptive software components, see Model AUTOSAR Adaptive Software Components. For more information about configuring AUTOSAR Adaptive service interfaces and properties, see Configure AUTOSAR Adaptive Software Components.

Model AUTOSAR Adaptive Client-Server Communication and Execution

Method communication enables an AUTOSAR Adaptive software component to invoke a method provided by another software component. A server component provides a method implementation through a server port, and a client component invokes that method through a client port. In Simulink, you model method communication as client-server communication with function ports, Function Caller blocks, and Simulink Function blocks. You must model clients and servers as separate software components. For more information about configuring AUTOSAR Adaptive client-server communication, see Configure AUTOSAR Adaptive Client-Server Service Communication.

To model AUTOSAR Adaptive client-server communication, follow this general workflow.

  1. Create or open an export-function model configured for the AUTOSAR Adaptive Platform, and add server ports to the boundary of the software component.

  2. Create or open a model configured for the AUTOSAR Adaptive Platform and add client ports to the boundary of the software component.

  3. Model AUTOSAR Adaptive server components by using Simulink Function blocks and server ports.

  4. Model AUTOSAR Adaptive client components by using Function Caller blocks and client ports.

  5. Define the interface of the port in a data dictionary with Simulink.dictionary.archdata.ServiceInterface objects. Use the Interface Editor (System Composer) to create, view, and configure the interface and its function elements and arguments in the model. Use the Architectural Data Editor to configure code generation properties.

  6. Open the AUTOSAR Component Designer app and Property Inspector. Configure these service attributes for each client port function element:

    • Timeout — Specify the maximum time, in seconds, that a client can wait for a response from the server. If the Timeout value is reached, then the status argument of the port changes its value to SlSignalStatus.TIMEOUT, and the client output arguments hold the last valid value that it received from the server.

    • Server response not required — Configure a client port interface for fire-and-forget method communication. Client port interfaces are defined by Simulink.dictionary.archdata.ServiceInterface objects. You can set this property only when the Simulink.dictionary.archdata.FunctionElement function prototype has no output Simulink.dictionary.archdata.FunctionArgument objects.

    • Caller behavior — Configure the client to invoke server methods either synchronously or asynchronously, using one of these values:

      • Wait for server results — The client sends a request and blocks execution until the server returns a response.

      • Allowed delayed server results — The client sends a request to the server and continues execution. Each time the function executes, the client checks whether server results are ready. If no new results are ready, the client outputs the most recent value that it received from the server.

    Service tab showing communication and execution attributes for Velocty.getCurrentVelocity, with Timeout set to Inf and Caller behavior set to Wait for server results

  7. Configure communication error handling with status arguments. Status arguments allow the software component to detect and handle communication conditions such as data not arriving on time and dropped server connections.

    In the Property Inspector, click Add Argument button and select Add status argument to append a status output to the client function prototype.

    Property Inspector for client port Velocity with function element getCurrentVelocity expanded. Status argument status is highlighted.

    The status argument uses the predefined SlSignalStatus enumeration data type, which reports OK, TIMEOUT, or COM_NOT_AVAILABLE at run time. Use the status return argument in the client function prototype to handle communication errors during server invocations, for example, timeouts or when servers are down.

  8. Validate and simulate the model.

  9. Prepare your model for AUTOSAR code generation with the AUTOSAR Dictionary. In the AUTOSAR Dictionary, you can configure options for ARXML export, such as single file or modular file export, package paths, platform type packing, customizations for implementation data type referencing, data constraints, and software calibration access default values. For more information about configuring ARXML export with the AUTOSAR Dictionary, see Configure AUTOSAR Adaptive XML Options.

  10. Build the software components to generate algorithmic C++ code, service implementation code, and export ARXML descriptions.

  11. Verify generated code with software-in-the-loop (SIL) simulations.

  12. Deploy the generated application to a POSIX-based target environment.

For more information about modeling AUTOSAR Adaptive software components, see Model AUTOSAR Adaptive Software Components. For more information about configuring AUTOSAR Adaptive service interfaces and specifications, see Model AUTOSAR Adaptive Service Communication and Execution Behavior.

Model AUTOSAR Adaptive Service Interfaces with Methods and Events in Simulink

By default, each bus element port maps to a separate AUTOSAR Adaptive Service Interface. To combine events and methods onto an AUTOSAR Adaptive Service Interface, on the Service tab in the Property Inspector, assign the same Service port name to a receiver port and a client port, or a sender port and a server port.

For example, open model adaptive_ActuatorSWC. Open the AUTOSAR Component Designer app and Property Inspector. In the model canvas, on the software component boundary select client port Velocity. In the Property Inspector, with the port selected, navigate to the Service tab. The service attribute Service port is set to Default: Velocity.

Model adaptive_ActuatorSWC, port Velocity is selected. Property Inspector is open with Service tab selected. Service attribute Service port is set to Default: Velocity.

Return to the model and select receiver port Brake on the software component boundary. The Property Inspector updates. With Brake selected in the Property Inspector, navigate to the Service tab. The service attribute Service port is also set to Velocity.

Model adaptive_ActuatorSWC, port Brake is selected. Property Inspector is open with Service tab selected. Service attribute Service port is set to Velocity.

After you generate code, in the AUTOSAR Dictionary confirm that AUTOSAR Adaptive Service Interface SpeedInterface has events Brake.BrakeCmd and Brake.Cmd and method getCurrentVelocity.

AUTOSAR Dictionary Service Interfaces expanded SpeedInterface Events node is selected showing Events BrakeCmd and Cmd. Methods nodes is expanded in the navigation tree showing Method getCurrentVelocity.

When you export ARXML, the exported file contains SpeedInterface as a SERVICE-INTERFACE with both events and methods.

<SERVICE-INTERFACE UUID="...">
    <SHORT-NAME>SpeedInterface</SHORT-NAME>
    <EVENTS>
        <VARIABLE-DATA-PROTOTYPE UUID="...">
            <SHORT-NAME>BrakeCmd</SHORT-NAME>
            <CATEGORY>VALUE</CATEGORY>
            <SW-DATA-DEF-PROPS>
                <SW-DATA-DEF-PROPS-VARIANTS>
                    <SW-DATA-DEF-PROPS-CONDITIONAL>
                        <SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
                        <SW-IMPL-POLICY>STANDARD</SW-IMPL-POLICY>
                    </SW-DATA-DEF-PROPS-CONDITIONAL>
                </SW-DATA-DEF-PROPS-VARIANTS>
            </SW-DATA-DEF-PROPS>
            <TYPE-TREF DEST="STD-CPP-IMPLEMENTATION-DATA-TYPE">/AUTOSAR/StdTypes/double</TYPE-TREF>
        </VARIABLE-DATA-PROTOTYPE>
        <VARIABLE-DATA-PROTOTYPE UUID="...">
            <SHORT-NAME>Cmd</SHORT-NAME>
            <CATEGORY>VALUE</CATEGORY>
            <SW-DATA-DEF-PROPS>
                <SW-DATA-DEF-PROPS-VARIANTS>
                    <SW-DATA-DEF-PROPS-CONDITIONAL>
                        <SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
                        <SW-IMPL-POLICY>STANDARD</SW-IMPL-POLICY>
                    </SW-DATA-DEF-PROPS-CONDITIONAL>
                </SW-DATA-DEF-PROPS-VARIANTS>
            </SW-DATA-DEF-PROPS>
            <TYPE-TREF DEST="STD-CPP-IMPLEMENTATION-DATA-TYPE">/AUTOSAR/StdTypes/double</TYPE-TREF>
        </VARIABLE-DATA-PROTOTYPE>
    </EVENTS>
    <METHODS>
        <CLIENT-SERVER-OPERATION UUID="...">
            <SHORT-NAME>getCurrentVelocity</SHORT-NAME>
            <ARGUMENTS>
                <ARGUMENT-DATA-PROTOTYPE UUID="...">
                    <SHORT-NAME>velocity</SHORT-NAME>
                    <CATEGORY>VALUE</CATEGORY>
                    <SW-DATA-DEF-PROPS>
                        <SW-DATA-DEF-PROPS-VARIANTS>
                            <SW-DATA-DEF-PROPS-CONDITIONAL>
                                <SW-CALIBRATION-ACCESS>READ-ONLY</SW-CALIBRATION-ACCESS>
                                <SW-IMPL-POLICY>STANDARD</SW-IMPL-POLICY>
                            </SW-DATA-DEF-PROPS-CONDITIONAL>
                        </SW-DATA-DEF-PROPS-VARIANTS>
                    </SW-DATA-DEF-PROPS>
                    <TYPE-TREF DEST="STD-CPP-IMPLEMENTATION-DATA-TYPE">/AUTOSAR/StdTypes/double</TYPE-TREF>
                    <DIRECTION>OUT</DIRECTION>
                </ARGUMENT-DATA-PROTOTYPE>
            </ARGUMENTS>
            <FIRE-AND-FORGET>false</FIRE-AND-FORGET>
        </CLIENT-SERVER-OPERATION>
    </METHODS>
</SERVICE-INTERFACE>

Tips

If you have software component models configured for the AUTOSAR Adaptive Platform that were created in a previous release, use the autosar.api.upgrade function to upgrade them to R2026b. For more information about upgrading AUTOSAR Adaptive software component models, see Upgrade AUTOSAR Adaptive Models.

See Also

| | |

Topics