Skip to Main Content Skip to Search
Product Documentation

Generating Code for AUTOSAR Software Components

On this page…

Overview of AUTOSAR Support

Simulink Modeling Patterns for AUTOSAR

Workflow for AUTOSAR

Importing an AUTOSAR Software Component

Preparing a Simulink Model for AUTOSAR Code Generation

Generating AUTOSAR Code and Description Files

Configuring AUTOSAR Options Programmatically

Verifying the AUTOSAR Code with SIL and PIL Simulations

Limitations and Tips

Demos and Further Reading

Overview of AUTOSAR Support

Embedded Coder software supports AUTomotive Open System ARchitecture (AUTOSAR), an open and standardized automotive software architecture. Automobile manufacturers, suppliers, and tool developers jointly develop AUTOSAR.

The AUTOSAR standard addresses:

For more information, see:

Back to Top

Simulink Modeling Patterns for AUTOSAR

About Simulink Modeling Patterns for AUTOSAR

This section describes how you model AUTOSAR Software Components and related concepts in Simulink.

AUTOSAR Software Components

In AUTOSAR, application software consists of separate units, AUTOSAR Software Components.

The behavior of an AUTOSAR Software Component is implemented by a single or multiple runnable entities (runnables), which expose well-defined connection points, ports.

In Simulink, you can represent an AUTOSAR Software Component using a model or a subsystem. For example, the following figure shows modeling patterns for AUTOSAR Software Components (ASWC) labeled ASWC1, ASWC2, ASWC3, and ASWC4.

Runnables.  AUTOSAR Software Components contain runnables that are directly or indirectly scheduled by the underlying AUTOSAR operating system.

The following figure shows an AUTOSAR Software Component with two runnables, Runnable 1 and Runnable 2. Each runnable is triggered by RTEEvents, events generated by the AUTOSAR Runtime Environment (RTE). For example, TimingEvent is an RTEEvent that is generated periodically.

The components ASWC1, ASWC2 and ASWC4 contain single runnables. These components are represented by a subsystem or a model, and can be single- or multirate. However, the software implements each component as a single-tasking operation.

ASWC2 is modeled as a single-rate, single-tasking atomic subsystem.

You can generate the ASWC2 runnable, which corresponds to the step function of the subsystem. Use the Configure AUTOSAR Interface dialog box to specify the names of the initial and periodic runnables, as shown by the following figure.

The software generates TimingEvents for the runnables. The TimingEvent period for the periodic runnable is the fundamental sample time of the model or atomic subsystem. Specify this sample time in the Subsystem Parameters dialog box, in the Sample time (-1 for inherited) field.

The component ASWC3 contains multiple runnables.

Use the Export Functions feature to map the runnables to Simulink function-call subsystems. See Configuring Multiple Runnables and Exporting AUTOSAR Software Component. The software also generates an initialization runnable for the initialization function.

Use the Configure AUTOSAR Interface dialog box to specify the names of the multiple runnables and the periods of TimingEvents.

Multiple Instantiation.  AUTOSAR supports multiple instantiations of software components. However, Simulink supports multiple instantiations (reentrant code) only if a model is configured as a server operation. See Configuring a Server Operation.

To generate reentrant code for a model configured as a server operation, on the Code Generation > Interface pane, select the Generate reusable code check box.

AUTOSAR Communication

AUTOSAR Software Components provide well-defined connection points, ports. There are two types of AUTOSAR ports:

In addition, these AUTOSAR ports can reference two kinds of interfaces:

The following figure shows an AUTOSAR Software Component with four ports representing all port and interface combinations.

Sender-Receiver Interface.  A Sender-Receiver Interface consists of one or more data elements. Although a Require or Provide port may reference a Sender-Receiver Interface, the AUTOSAR Software Component does not necessarily access all the data elements. For example, consider the following figure.

The AUTOSAR Software Component has a Require and Provide port that references the same Sender-Receiver Interface, interface1. Although this interface contains data elements DE1, DE2, DE3, DE4, and DE5, the component does not utilize all the data elements.

The following figure is an example of how you model, in Simulink, an AUTOSAR Software Component that accesses data elements.

ASWC accesses data elements DE1 and DE2. You model data element access as follows:

ErrorStatus is a value that the AUTOSAR Runtime Environment (RTE) returns to indicate errors that the communication system detects for each data element. You can use a Simulink inport to model error status, for example, RPort1_DE1 (ErrorStatus).

Use the Configure AUTOSAR Interface dialog box to specify the AUTOSAR settings for each inport and outport. The following figure shows settings for ASWC.

For example, the Data Access Mode for RPort1_DE1 is set to ImplicitReceive. For information on how you specify settings, see Using the Configure AUTOSAR Interface Dialog Box.

Client-Server Interface.  A Client-Server Interface consists of one or more operation prototypes. An operation prototype contains one or more arguments of specific data types. A Client-Server Interface can be referenced by either a Require or Provide port.

The following figure shows an AUTOSAR Software Component with Require ports (RPort2 and NvM ) that reference Client-Server Interfaces (Interface2 and NvM).

Simulink provides the following modeling patterns for Client-Server Interfaces:

The following figure shows the use of the Invoke AUTOSAR Server Operation block in modeling an AUTOSAR Software Component in Simulink.

Use the Configure AUTOSAR Interface dialog box to specify the AUTOSAR settings for each inport and outport. See Using the Configure AUTOSAR Interface Dialog Box.

The following figure shows an AUTOSAR Software Component with a Provide port that references a Client-Server Interface.

In Simulink, you can model a single operation of an AUTOSAR Software Component that is referenced by a Client-Server Interface. Consider the following model.

Use the Configure AUTOSAR Interface dialog box to map the inports and outports to the arguments of the operation prototype. For example, the inports map to arguments upper, input, and lower.

For more information, see Configuring a Server Operation .

Calibration Parameters

About Calibration Parameters.  A calibration parameter is a value in an Electronic Control Unit (ECU). You tune or modify these parameters using a calibration data management tool or an offline calibration tool.

The AUTOSAR standard specifies the following types of calibration parameters:

The software supports import, export, and code generation for both types of calibration parameters.

Importing and Exporting Calibration Parameters.  You can import calibration parameters into the MATLAB base workspace.

For example, to import parameters from an AUTOSAR calibration component description, use arxml.importer.createCalibrationComponentObjects.

To provide your Simulink model with access to these parameters, assign the imported parameters to block parameters.

For more information, see Importing an AUTOSAR Software Component.

You can specify the type of calibration parameter exported by configuring properties of the corresponding block parameter in the base workspace. See Configuring Calibration Parameters and rtwdemo_autosar_legacy_script.

Inter-Runnable Variables

In AUTOSAR, inter-runnable variables are used to communicate primitive type data between runnables in the same component. You define these variables in a Simulink model by the signal lines that connect subsystems (runnables). For example, in the following figure, irv1, irv2, irv3, and irv4 are inter-runnable variables.

You can specify the names and data access modes of the inter-runnable variables that you export. See Configuring Inter-Runnable Variables.

Data Types

AUTOSAR specifies data types that apply to:

The data types fall into two categories:

You can use Simulink data types to define AUTOSAR primitive types.

AUTOSAR Data TypeSimulink Data Type
UInt4uint8
SInt4int8
UInt8uint8
SInt8int8
UInt16uint16
SInt16int16
UInt32uint32
SInt32int32
Float_with_NaNsingle
Floatsingle
Double_with_NaNdouble
Doubledouble
Booleanboolean
Char8uint8
Char16Not supported

AUTOSAR composite data types are arrays and records, which are represented in Simulink by wide signals and bus objects, respectively. In the Inport or Outport Block Parameters dialog box, use the Signal Attributes pane to configure wide signals and bus objects.

The following figure shows how to specify a wide signal, which corresponds to an AUTOSAR composite array.

The following figure shows how to specify a bus object, which corresponds to an AUTOSAR composite record.

You can use the Data Type Assistant on the Signal Attributes pane of the Inport or Outport Block Parameters dialog box to specify the data types of data elements and arguments of an operation prototype. If you select Mode to be Built in, then you can specify the data type to be, for example, single or boolean. Alternatively, if you select Mode to be Expression, you can specify an (alias) expression for data type. As an example, the following figure shows an alias UInt4 in the Data type field.

Enumerated Data Types.  AUTOSAR supports enumerated data types. For the import process, if there is a corresponding Simulink enumerated data type, then the software uses this data type. The software checks that the two data types are consistent. However, if there is no corresponding Simulink data type, then the software automatically creates the enumerated data type using the Simulink.defineIntEnumType class. This automatic creation of data types is useful when you want to import a large number of enumerated data types.

Consider the following example:

<SHORT-NAME>BasicColors</SHORT-NAME>
  <COMPU-INTERNAL-TO-PHYS>
  <COMPU-SCALES>
     <COMPU-SCALE>
        <LOWER-LIMIT>0</LOWER-LIMIT>
        <UPPER-LIMIT>0</UPPER-LIMIT>
        <COMPU-CONST>
           <VT>Red</VT>
....

The software creates an enumerated data type using:

Simulink.defineIntEnumType( 'BasicColors', ...
     {'Red', 'Green', 'Blue'}, ...
     [0;1;2], ...
     'Description', 'Type definition of BasicColors.', ...
     'HeaderFile', 'Rte_Type.h', ...
     'AddClassNameToEnumNames', false);

Structure Parameters.  Before exporting an AUTOSAR Software Component, MathWorks recommends that you specify the data types of structure parameters to be Simulink.Bus objects. See Structure Parameters and Generated Code in Simulink Coder documentation. Otherwise, the software displays the following behavior:

When importing an AUTOSAR Software Component, if a parameter structure has a data type name that corresponds to an anonymous struct, the software sets the data type to struct. However, if the component has data elements that reference this anonymous struct data type, the software generates an error.

Per-Instance Memory

AUTOSAR supports per-instance memory, which allows you to specify instance-specific global memory within a software component. An AUTOSAR run-time environment generator allocates this memory and provides an API through which you access this memory.

In Simulink, you can model per-instance memory through the use of Data Store Memory and Data Store Read/Write blocks together with an AUTOSAR.Signal data object that specifies, for example, the PerInstanceMemory custom storage class.

AUTOSAR also allows you to use per-instance memory as a RAM mirror for data in non-volatile RAM (NVRAM), which enables you to access and use NVRAM in your AUTOSAR application.

Once an AUTOSAR.Signal data object specifies the PerInstanceMemory custom storage class, you can configure this per-instance memory to be a mirror block for a specific NVRAM block by setting the attribute needsNVRAMAccess to true.

For detailed information about how you model per-instance memory, see the demo rtwdemo_autosar_PIM_script. For an outline, see Using Data Store Memory Blocks to Specify Per-Instance Memory.

AUTOSAR Terminology

TermNotes
AUTOSAR Runtime Environment (RTE)

  • Layer between Application and Basic Software layers

  • Realizes communication between:

    • AUTOSAR Software Components

    • AUTOSAR Software Components and Basic Software

AUTOSAR Software Component

  • A software component containing one or more algorithms, which communicates with its environment through ports

  • Connected to the AUTOSAR Runtime Environment (RTE)

  • Relocatable (not tied to a particular ECU)

CharacteristicsValues of characteristics can be changed on an ECU through a calibration data management tool or an offline calibration tool.
Client-Server Interface

  • PortInterface for client-server communication

  • Defines operations provided by server and used by client

Composite data typesCategory of data types, such as one of the following:

  • Array — Contains more than one element of the same type, and has zero-based indexing

  • Record — Non-empty set of objects, where each object has a unique identifier

ComSpecDefines specific communication attributes.
DataElementPrototype (data element) Data value (signal) exchanged between a sender and a receiver.
Data types

  • Either primitive or composite

  • Types data elements, arguments of operations in a Client-Server Interface, and constants

ErrorStatusIndicates errors detected by communication system. Runtime Environment defines the following macros for sender-receiver communication:

  • RTE_E_OK: no errors

  • RTE_E_INVALID: data element invalid

  • RTE_E_MAX_AGE_EXCEEDED: data element outdated

OperationPrototype (operation)

  • Invoked by a client

  • Provides value for each argument with direction in or inout, which must be of the correct data type

  • Client expects to receive a response to the invoked operation, part of which is a value with direction out or inout

PortInterface

  • Characterizes information provided or required by a port

  • Can be either Sender-Receiver Interface or Client-Server Interface

Primitive data typesCategory of data types that allow a direct mapping to C intrinsic types.
Provide port (PPort)Port providing data or service of a server.
Require port (RPort)Port requiring data or service of a server.
RTEEventEvent or situation that triggers execution of a runnable by the Runtime Environment (RTE). The software supports the following RTEEvents:

  • OperationInvokedEvent (applicable to server operations)

  • TimingEvent

  • DataReceivedEvent

Runnable entity (runnable)Part of AUTOSAR Software-Component that can be executed and scheduled independently of other runnable entities (runnables).
Sender-Receiver Interface

  • PortInterface for sender-receiver communication

  • Defines data elements sent by sending component (with Provide port providing Sender-Receiver Interface) or received by receiving component (with Require requiring Sender-Receiver Interface)

Sender Receiver AnnotationAnnotation of data elements in a port that implements Sender-Receiver Interface.
Sensor Actuator Software ComponentAUTOSAR Software Component dedicated to the control of a sensor or actuator.
ServiceLogical entity of Basic Software that offers functionality, which is used by various AUTOSAR Software Components.

Back to Top

Workflow for AUTOSAR

This section describes how you use Embedded Coder software to generate AUTOSAR-compliant code.

The following diagram shows a workflow that you can follow.

In this round-trip workflow, you perform the following tasks:

  1. Import previously specified AUTOSAR Software Components, including definitions of calibration parameters, into Simulink. See Importing an AUTOSAR Software Component and Configuring Calibration Parameters.

  2. Incorporate your Simulink design into the skeleton model or subsystem created by the import process.

  3. Export, generating code and description files. This process involves configuring the AUTOSAR interface, validating this interface, and then building your Simulink models. See:

    You can also verify your generated code in a simulation. See Verifying the AUTOSAR Code with SIL and PIL Simulations.

  4. Merge generated code and description files with other systems using an AUTOSAR authoring tool. See demo rtwdemo_autosar_roundtrip_script.

    You can use the authoring tool to export specifications, which can be imported back into Simulink.

Back to Top

Importing an AUTOSAR Software Component

Use the arxml.importer class to:

For a complete list of methods, see AUTOSAR in the Embedded Coder Function Reference documentation.

Use arxml.importer methods in the following order:

  1. Call the constructor arxml.importer, for example, arxml.importer('mySoftwareComponentFile.arxml'), to create an importer object that looks for atomic software components in the specified XML file. In the Command Window, you see reports describing identified atomic software components. You can have multiple components. For example:

    The file "mySoftwareComponentFile.arxml" contains:
  1 Atomic-Software-Component-Type:
    '/ComponentType/complex_type_component'
  3 CalPrm-Component-Type:
    '/ComponentType/MyCalibComp1'
    '/ComponentType/MyCalibComp2'
    '/ComponentType/MyCalibComp3'

    To change the main file and update the list of components, use arxml.importer.setFile.

    Each software component requires an arxml.importer object. For each arxml.importer object, specify the file that contains the software component that you want.

  2. Use arxml.importer.setDependencies if you need to specify additional dependent XML files containing the information that completes the software component description (for example, data types, interfaces). You can specify a cell array of files or a single file.

    Complete specifying dependencies only for components that you intend to import into Simulink.

  3. To import a parsed atomic software component into a Simulink model, call one of the following methods. If you have not specified all dependencies for the components, you will see errors.

    • arxml.importer.createComponentAsSubsystem — Creates and configures a Simulink subsystem skeleton corresponding to the specified atomic software component description.

    • arxml.importer.createComponentAsModel — Creates and configures a Simulink model skeleton corresponding to the specified atomic software component description.

      For example:

      importer_obj.createComponentAsModel('/ComponentType/complex_type_component')

    • arxml.importer.createCalibrationComponentObjects — Creates Simulink calibration objects corresponding to the specified AUTOSAR calibration component description.

      For example:

      [success] = createCalibrationComponentObjects(importer_obj,
'CreateSimulinkObject', true)

    See also the limitation, Cannot Import Internal Behavior.

After you import your software component into Simulink, you can modify the skeleton model or subsystem. For parameters from a calibration component, after importing the parameters into the MATLAB workspace, assign the calibration parameters to block parameters in your model.

To configure AUTOSAR code generation options and XML export options, see:

To see how to import, modify, and export AUTOSAR Software Components, view the demo Import and Export an AUTOSAR Software Component.

Back to Top

Preparing a Simulink Model for AUTOSAR Code Generation

Using the Configure AUTOSAR Interface Dialog Box

Use the Configure AUTOSAR Interface dialog box to configure your AUTOSAR code generation and XML import and export options. Alternatively, you can control all AUTOSAR options programmatically. See Configuring AUTOSAR Options Programmatically.

In any model using the autosar.tlc system target file, you can open the Configure AUTOSAR Interface dialog box by right-clicking a subsystem and selecting Code Generation > AUTOSAR Single or Multi-Runnable Component > Configure.

Single-Runnable menu options are enabled for only atomic or function-call subsystems.

Multi-Runnable menu options are enabled for only virtual subsystems.

To configure your AUTOSAR options:

  1. If the Configure I/O for server operation check box is selected, clear it. Select this check box only when you want to configure your Simulink model as a server operation (see Configuring a Server Operation).

  2. Specify Component type. From the drop-down list, select one of the following:

    • Application — For an AUTOSAR application software component

    • Sensor Actuator — For an AUTOSAR sensor/actuator software component.

    The key difference between a sensor/actuator component and an application component is that a sensor/actuator component can access the I/O hardware abstraction part within the ECU abstraction layer.

  3. Click Get Default Configuration to populate the controls for your model.

    The runnable names, XML properties, and I/O configuration are initialized. If you click Get Default Configuration again later, only the I/O configurations are reset to default values.

  4. Under Configure AUTOSAR Interface, use the controls to change your AUTOSAR code generation options and XML export options. For example, send and receive communication options such as port and interface names, data access modes, and initial and periodic runnable names.

    • On the Input/Output tab, designate inports and outports as data sender/receiver ports, error status receivers, or as access points to basic software.

      To designate inports and outports as sender or receiver ports, set each port's Data Access Mode to one of the following:

      • Implicit (recommended). Data is buffered by the Run-Time Environment (RTE).

      • Explicit. Data is not buffered.

      Under Properties, use the port interface settings to reflect your AUTOSAR port best practices. For example, some AUTOSAR users like to group related data into the same AUTOSAR port. You can achieve this arrangement by duplicating AUTOSAR port names. Alternatively, you can use the AUTOSAR port to group information individually. In this case, a common approach is to set all Data element settings to something neutral, for example, 'data', and leave the AUTOSAR port names as they are. You can also use the AUTOSAR Interface name for any best practices that you might have. For example, you can set up interfaces for individual AUTOSAR ports by ensuring that the interface names change when the AUTOSAR port name changes, for example, by prefixing the AUTOSAR interface of the corresponding AUTOSAR port name with an 'if_'.

      Under Properties, specify Interface type, which sets the isService attribute of the port interface. From the drop-down list select one of the following:

      • Application software — When data is provided by AUTOSAR Software Component

      • Basic software — When data is provided by AUTOSAR Services

      For more information on all these options, see AUTOSAR in the Embedded Coder Function Reference documentation.

      You also use Data Access Mode to designate ports to access basic software or error status. See Configuring Ports for Basic Software and Error Status Receivers.

    • On the Runnables tab, specify the names of your initial and periodic runnables, for example, Runnable_Init and Runnable_Step.

    • On the XML Options tab, specify:

      1. The form of your Exported XML file packaging. Select Modular (default) if you want to publish the XML descriptions as separate files. If you want to combine the XML descriptions, select Single file.

      2. The names and package paths of the XML files that you publish when you generate code.

    See Exporting AUTOSAR Software Component.

  5. After configuring your options, click Validate, which calls runValidation. If there are problems, you see messages describing why the configuration is invalid. See also Modifying and Validating an Existing AUTOSAR Interface.

  6. If validation succeeds, click OK to return to the Configuration Parameters dialog box.

  7. Save your model and then generate code (Ctrl+B) to export your AUTOSAR component.

Configuring Single Runnables for DataReceivedEvents.  The AUTOSAR Runtime Environment uses the event type DataReceivedEvent to trigger a runnable only when the value of a received data element is updated.

The software supports two data access modes that enable DataReceivedEvents to act as triggers, ExplicitReceive and QueuedExplicitReceive. The latter, in principle, allows the queuing of events. However, by default, the software restricts the queue length to one event only. If you want a different queue length, you must edit the generated XML file.

To create a runnable trigger with a DataReceivedEvent:

  1. Under Configure AUTOSAR Interface, select the Input/Output tab.

  2. If you want an input data signal to be a trigger (for example, Input) set Data Access Mode for the corresponding inport to ExplicitReceive or QueuedExplicitReceive.

  3. Select the Runnables tab. To create a new trigger event, click Add Event. By default, from the Event Type drop-down list, the software selects DataReceivedEvent.

  4. In the Event Name column, specify an event name.

  5. In the Trigger Port column, from the drop-down list, select the Simulink port, for example, Input.

  6. To create an additional trigger event, repeat steps 3 – 5. You can remove a trigger event by selecting the event row and clicking Delete Event.

  7. To verify that you have configured the event triggers, click Validate.

Configuring Ports for Basic Software and Error Status Receivers

You can configure ports to access AUTOSAR services and device drivers (AUTOSAR basic software), and to access communication error status in your model. You can configure ports programmatically or by using the AUTOSAR Model Interface dialog box. To open the dialog box, right-click a subsystem and select Code Generation > AUTOSAR Single or Multirunnable Component > Configure.

In the dialog box, you can specify the Data Access Mode of every port.

Configuring Client-Server Communication

AUTOSAR allows client-server communication between:

An AUTOSAR Client-Server Interface defines the interaction between a software component that provides the interface and a software component that requires the interface. The component that provides the interface is the server. The component that requires the interface is the client.

In Simulink, you can:

Once you create a client-server interface, you can generate a Simulink library of configurable, client-server subsystems that reference the:

For information on how to generate this library, see Creating Configurable Subsystems from a Client-Server Interface

You can deploy the client-server subsystem in a Simulink model and, using the Mode Switch for Invoke AUTOSAR Server Operation, run the model in either a simulation or code-generation mode. See Simulating and Generating Code for Client-Server Communication.

For a demo on generating and using an AUTOSAR Client-Server Interface, see rtwdemo_autosar_clientserver_script.

Configuring a Server Operation.  In the Configure AUTOSAR Interface dialog box, you can configure your Simulink model as a server operation. Then you can generate AUTOSAR-compliant code and XML files, including the client-server interface.

  1. Select the Configure I/O for server operation check box. The Input/Output tab becomes the Server Operation tab.

  2. Click Get Default Configuration to populate the controls for your model.

    The runnable names, XML properties, and I/O configuration are initialized. If you click Get Default Configuration again later, only the I/O configurations are reset to default values.

    On the Configure AUTOSAR Interface pane, use the controls to change your AUTOSAR code generation options and XML export options.

  3. On the Server Operation tab, specify the following:

    • Server port name. Use a valid AUTOSAR short-name identifier.

    • Operation prototype . The names of the prototype and its arguments must be valid AUTOSAR short-name identifiers, for example, rtwdemo_autosar_server_operation(IN double upper, IN double input, IN double lower, OUT double output).

    • Interface name. The path reference of the client-server interface. Use a valid AUTOSAR short-name path, for example, csinterface.

    • Server type. From the drop-down list, select either Application software or Basic software.

  4. On the Runnables tab, specify the names of your initial and periodic runnables, for example, Runnable_Init and Runnable_Step.

  5. On the XML Options tab, specify:

    1. The form of your Exported XML file packaging. Select Modular (default) if you want to publish the XML descriptions as separate files. If you want to combine the XML descriptions, select Single file.

    2. The names and package paths of the XML files that you publish when you generate code.

    See Exporting AUTOSAR Software Component.

  6. After you configure your options, click Validate, which calls runValidation. If there are problems, you see messages describing why the configuration is invalid. See also Modifying and Validating an Existing AUTOSAR Interface.

  7. If validation succeeds, click OK to return to the Configuration Parameters dialog box.

  8. Save your model.

  9. To generate AUTOSAR-compliant code and XML files, select Tools > Code Generation > Build Model.

Configuring the Invoke AUTOSAR Server Operation Block.  You can use the Invoke AUTOSAR Server Operation block in your Simulink model to configure a client port (that accesses either application software or AUTOSAR Basic Software). You can then build the model to generate AUTOSAR-compliant code and XML files.

  1. Drag an Invoke AUTOSAR Server Operation block into your model.

  2. Double-click the block to open the Invoke AUTOSAR Server Operation dialog box. Specify the following:

    • Client port name. A valid AUTOSAR short-name identifier.

    • Operation prototype. The names of the prototype and its arguments must be valid AUTOSAR short-name identifiers, for example, rtwdemo_autosar_server_operation(IN double upper, IN double input, IN double lower, OUT double output).

    • Interface path. The path reference of the client-server interface. You must use a valid AUTOSAR short-name path, for example, /AUTOSAR/Interface.

    • Server type. From the drop-down list, select either Application software or Basic software.

    • Show error status. If you want the client port to receive the error status of client-server communication, select this check box.

    • Sample time. Set this parameter to -1 to inherit the sample time.

  3. Click OK. Your Invoke AUTOSAR Server Operation block is updated.

  4. Connect the updated Invoke AUTOSAR Server Operation block to your model.

  5. Select Tools > Code Generation > Build Model. AUTOSAR-compliant code and XML files for the client port are generated.

Creating Configurable Subsystems from a Client-Server Interface.  You can generate a Simulink library of configurable subsystems by applying the createOperationAsConfigurableSubsystems method to the arxml.importer object with the client-server interface. For example:

% Create an AUTOSAR importer object
obj = arxml.importer('rtwdemo_autosar_csinterface.arxml');

% Create the client-server operation configurable subsystem library
obj.createOperationAsConfigurableSubsystems('/PortInterface/csinterface', ...
                                            'CreateSimulinkObject', false);

yield the following PortInterface_csinterface library.

Simulating and Generating Code for Client-Server Communication.  Use the Template block from the client-server subsystem library to construct a model that can be run in either code-generation or simulation mode.

  1. Drag the Template block from the subsystem library into your model window and connect it to other blocks.

  2. Place the Mode Switch for Invoke AUTOSAR Server Operation in your model window.

To simulate the model:

  1. Double-click the Mode Switch for AUTOSAR Server Operation to change the current mode from code generation to simulation.

  2. Select Simulation > Start.

To generate code for the model:

  1. Double-click the Mode Switch for AUTOSAR Server Operation to change the current mode from simulation to code generation.

  2. Select Tools > Code Generation > Build Model.

Configuring Multiple Runnables

You can use function-call subsystems within a wrapper subsystem to represent multiple runnables in a single AUTOSAR Software Component, and export each function-call subsystem as an AUTOSAR runnable.

If you group function-call subsystems within your wrapper subsystem into virtual subsystems, for example, to improve the graphical layout of your model, you can still export the function-call subsystems as AUTOSAR runnables. For information about virtual subsystems, see Creating Subsystems and Virtual Blocks in the Simulink documentation.

The software supports the following blocks within a wrapper subsystem:

The software also supports the use of Simulink library blocks when creating multiple runnables from subsystems. See Simulink Block Library Support for Multiple Runnables.

Use the Configure AUTOSAR Interface dialog box to specify an AUTOSAR interface for each function-call subsystem that you want to export as a runnable. To open this dialog box, right-click the top-level wrapper subsystem and select Code Generation > AUTOSAR Multi-Runnable Component > Configure. For information on how you configure multiple runnables, see:

See also the AUTOSAR Code Generation for Multiple Runnable Entities demo.

Configuring Inter-Runnable Variables.  Inter-runnable variables communicate primitive type data between runnables in a component. You define these inter-runnable variables by the signal lines that connect subsystems. For an example, see Inter-Runnable Variables.

By default, the software assigns the signal name to the exported inter-runnable variable. If you want to edit the name, before generating code, double-click the signal name and enter a new name. However, you can specify a different name for the exported variable. In addition, you can specify the data access mode of the inter-runnable variable.

To configure an inter-runnable variable:

  1. In the Configure AUTOSAR Interface dialog box, select the Inter-Runnable Variables tab. You see Simulink signals with (default) inter-runnable names and data access modes.

  2. For each signal that you want to configure:

    1. In the Inter-Runnable cell, specify your AUTOSAR name for the exported variable.

    2. In the Data Access Mode cell, from the drop-down list, select either Explicit or Implicit (recommended).

  3. Click OK.

When you select a signal, links appear under Source ports for signal .

Each link corresponds to an instance of the signal and is associated with a source port in the Simulink model. Click a link to go to the corresponding model signal. For example, clicking rtw.../ASWC/Runnable1/2 takes you to the following.

Specifying Execution Period.  You may need to use blocks that depend on time for a software component with multiple runnables, for example, the Discrete-Time Integrator block. In this case, you can specify a timer for each AUTOSAR runnable. The timer increments at each execution of the runnable.

Use the Configure AUTOSAR Interface dialog box to specify the execution period:

  1. Select the Runnables tab.

  2. Under Runnable, select a runnable, for example, Runnable1.

  3. In the Execution Period cell for the runnable's TimingEvent, enter the execution period.

  4. Click OK.

The timer data type generated depends on the execution period and the application life span. To specify the application life span:

  1. Select Configuration Parameters > Optimization.

  2. In the Application lifespan (days) field, enter the required value.

Configuring Multiple Runnables for DataReceivedEvents.  The AUTOSAR Runtime Environment uses the event type DataReceivedEvent to trigger runnables only when the value of a received data element is updated.

The software supports two data access modes that enable DataReceivedEvents to act as triggers, ExplicitReceive and QueuedExplicitReceive. The latter, in principle, allows the queuing of events. However, by default, the software restricts the queue length to one event only. If you want a different queue length, you must edit the generated XML file.

To create runnable triggers with DataReceivedEvents:

  1. Under Configure AUTOSAR Interface, select the Input/Output tab.

  2. If you want an input data signal to be a trigger, for example, RPort_DE1, from the corresponding Data Access Mode drop-down list, select either ExplicitReceive or QueuedExplicitReceive.

  3. Select the Runnables tab. Under Runnable, select the runnable that you want to configure, for example, Runnable1.

  4. Click Add Event to create a new trigger event. By default, from the Event Type drop-down list, the software selects DataReceivedEvent .

  5. In the Event Name column, specify an event name.

  6. In the Trigger Port column, from the drop-down list, select the Simulink port, for example, RPort_DE1.

  7. To create an additional trigger event, for example, using NvM_ReadBlock, repeat steps 4 – 6. You can remove a trigger event by selecting the event row and clicking Delete Event.

  8. To verify that you have configured the trigger events, click Validate.

Simulink Block Library Support for Multiple Runnables.  The software supports the use of Simulink library blocks when creating multiple runnables from subsystems. This support allows you to use:

Use the Configure AUTOSAR Interface dialog box to configure the linked subsystem. When you save the configured subsystem, the software saves the AUTOSAR configuration in the model file of the subsystem. The software does not store the AUTOSAR configuration of the subsystem as a parametrized link — see Modifying Linked Blocks.

For information about Simulink library blocks, see Working with Block Libraries in the Simulink documentation.

As an example, consider the demo model rtwdemo_autosar_multirunnables where the wrapper subsystem ASWC is replaced by MRB_instance, a link to a block from my_autosar_lib.

You can go to the block library by selecting MRB_instance and typing Ctrl+L.

Configuring Calibration Parameters

You can specify the type of calibration parameter that you export by configuring properties of the corresponding block parameter in the base workspace.

For example, to configure an internal calibration parameter for your AUTOSAR model:

  1. Create an AUTOSAR.Parameter object.

    1. Open the Model Explorer (Ctrl+H).

    2. In the Model Heirarchy view, under Simulink Root, select Base Workspace.

    3. Select Add > Add Custom. The Model Explorer – Select Object dialog box opens.

    4. Specify a value in the Object Name(s) field, for example, myPrm.

    5. From the Object class drop-down list, select AUTOSAR.Parameter.

    6. Click OK. A new object myPrm appears in the base workspace.

  2. In the Contents pane, select the object, for example, myPrm.

  3. Using the Dialog pane, configure the following properties of this data object:

    • Value — Specify a value for the calibration parameter. For an internal calibration parameter, this value represents the initial value.

    • Data type. For information about a creating data type, for example, a bus object data type, see Using the Data Type Assistant in the Simulink documentation.

    • Storage class — To specify an internal calibration parameter, from the drop-down list, select InternalCalPrm. You must then specify Per instance behavior. Select one of the following:

      • Parameter shared by all instances of the Software Component

      • Each instance of the Software Component has its own copy of the parameter

    For information about the Dialog pane, see The Model Explorer: Dialog Pane in the Simulink documentation.

  4. In the Block Parameters dialog box, assign the data object to your model, for example:

Before you generate code, you must:

Specifying these parameters allows the software to export the calibration parameters. See Generating Code with Custom Storage Classes.

For calibration component parameters, after you export your AUTOSAR components, you must include your calibration interface definition XML file to import the parameters into an authoring tool.

Using Data Store Memory Blocks to Specify Per-Instance Memory

You can model per-instance memory through the use of Data Store Memory blocks together with an AUTOSAR.Signal data object. For a detailed example, see the rtwdemo_autosar_PIM_script demo. The following is an outline of the required steps:

  1. In the base workspace, create an AUTOSAR.Signal object.

  2. Set the storage class of this object to PerInstanceMemory.

  3. If required, set needsNVRAMAccess property to true.

  4. Create a Data Store Memory block that references the AUTOSAR.Signal object. See Data Store Memory in the Simulink Reference documentation.

When you build your model, the XML files that are generated define an exclusive area for each Data Store Memory block that references per-instance memory. Every runnable that accesses per-instance memory runs inside the corresponding exclusive area. If multiple AUTOSAR runnables have access to the same Data Store Memory block, the exported AUTOSAR specification enforces data consistency by using an AUTOSAR exclusive area. With this specification, the runnables have mutually exclusive access to the per-instance memory global data, which prevents data corruption.

If you set needsNVRAMAccess to true, then a SERVICE-NEEDS entry (schema version 3.0) or NVRAM-MAPPINGS entry (schema version 2.1) is declared in XML files to indicate that the per-instance memory is a RAM mirror block and must be serviced by the NvM manager module.

Creating an AUTOSAR.Signal Object.  To create an AUTOSAR.Signal object in the base workspace:

  1. Open the Model Explorer (Ctrl+H).

  2. In the Model Heirarchy view, under Simulink Root, select Base Workspace.

  3. Select Add > Add Custom. The Model Explorer – Select Object dialog box opens.

  4. Specify a value in the Object Name(s) field, for example, nvmImplicitRW.

  5. From the Object class drop-down list, select AUTOSAR.Signal.

  6. Click OK. A new object nvmImplicitRW appears in the base workspace.

Modifying and Validating an Existing AUTOSAR Interface

You can validate your AUTOSAR interface using the Configure AUTOSAR Interface dialog box. See Using the Configure AUTOSAR Interface Dialog Box. The following steps show how you can modify and validate your AUTOSAR interface programmatically:

  1. Get the handle to an existing model-specific RTW.AutosarInterface object that is attached to your loaded Simulink model. Enter: 

    obj = RTW.getFunctionSpecification(modelName)

    modelName is a string specifying the name of a loaded Simulink model, and obj returns a handle to an RTW.AutosarInterface object attached to the specified model.

    Test the AUTOSAR interface object. Enter: 

    isa(obj,'RTW.AutosarInterface')

    This test must return 1. If the model does not have an AUTOSAR interface object, the function returns [].

  2. To view and change items, use the AUTOSAR get and set functions listed in AUTOSAR in the Embedded Coder Function Reference documentation.

  3. Validate the function prototype using RTW.AutosarInterface.runValidation.

  4. If validation succeeds, save your model and then generate code.

Back to Top

Generating AUTOSAR Code and Description Files

Selecting an AUTOSAR Schema

The default AUTOSAR schema version is 3.1. If you need to change the schema version, you must do so before exporting your AUTOSAR Software Component. Embedded Coder supports the following AUTOSAR schema versions:

To select a schema version:

  1. Open the Configuration Parameters dialog box. In any model that uses the autosar.tlc system target file, AUTOSAR Code Generation Options appears in the tree.

  2. Click AUTOSAR Code Generation Options to open the AUTOSAR Code Generation Options pane.

  3. From the Generate XML file for schema version drop-down list, select the schema version that you require.

Specifying Maximum SHORT-NAME Length

The AUTOSAR standard specifies that SHORT-NAME XML elements must not be greater than 32 characters in length. However, your authoring tool may support the use of longer elements, for example, to name ports and interfaces. The software allows you to specify the maximum length of your SHORT-NAME elements.

Before you build your model, on the Code Generation > AUTOSAR Code Generation Optionspane, in the Maximum SHORT-NAME length field, specify the maximum length of your SHORT-NAME elements. You may specify a maximum length of up to 128 characters. The default is 32 characters.

Configuring AUTOSAR Compiler Abstraction Macros

Compilers for 16-bit platforms (for example, Cosmic and Metrowerks for S12X or Tasking for ST10) use special keywords to deal with the limited 16-bit addressing range. The location of data and code beyond the 64 k border is selected explicitly by special keywords. However, if such keywords are used directly within the source code, then software must be ported separately for each microcontroller family, that is, the software is not platform-independent.

AUTOSAR specifies C macros to abstract compiler directives (near/far memory calls) in a platform-independent manner. These compiler directives, derived from the 16-bit platforms, enable better code efficiencies for 16-bit micro-controllers without separate porting of source code for each compiler. This approach allows your system integrator, rather than your software component implementer, to choose the location of data and code for each software component.

For more information on AUTOSAR compiler abstraction, see www.autosar.org

Configuring AUTOSAR Compiler Macro Generation.  Before you build your model, on the Simulink Coder AUTOSAR Code Generation Options pane, select the Use AUTOSAR compiler abstraction macros check box.

When you build the model, the software applies compiler abstraction macros to global data and function definitions in the generated code.

For data, the macros are in the following form:

where

For functions (model and subsystem), the macros are in the following form:

where

Example

If you do not select the Use AUTOSAR compiler abstraction macros check box, the software generates the following code:

/* Block signals (auto storage) */
BlockIO rtB;

/* Block states (auto storage) */
D_Work rtDWork;

/* Model step function */
void Runnable_Step(void)

However, if you select the Use AUTOSAR compiler abstraction macros check box, the software generates macros in the code:

/* Block signals (auto storage) */
VAR(BlockIO, SWC1_VAR) rtB;

/* Block states (auto storage) */
VAR(D_Work, SWC1_VAR) rtDWork;

/* Model step function */
FUNC(void, SWC1_CODE) Runnable_Step(void)

Root-Level Matrix I/O

The software supports matrix I/O at the root-level by generating code that implements matrices as one-dimensional arrays. However, this behavior is not the default. Before you build your model, on the AUTOSAR Code Generation Options pane, select the Support root-level matrix I/O using one-dimensional arrays check box.

Exporting AUTOSAR Software Component

After configuring your AUTOSAR export options, generate code to export your AUTOSAR Software Component.

To generate code and XML files:

The software component C code and the following XML files are exported to the build folder.

When Configure AUTOSAR Interface > XML Options > Exported XML file packaging is set to ...File NameDescription

Modular

modelname _behavior.arxml

Specifies the software component internal behavior

modelname _implementation.arxml

Specifies the software component implementation

modelname _interface.arxml

Specifies the software component interfaces, including extra interfaces

modelname _component.arxml

Specifies the software component type, including additional ports added to the Simulink model

modelname _datatype.arxml

Specifies the software component data types, including any modified or additional data types

Single file

modelname.arxml

Contains all specifications

You can merge the software component information back into an AUTOSAR authoring tool. This software component information is partitioned into separate files to facilitate merging. The partitioning attempts to minimize the number of merges that you must do. You do not need to merge the data type file into the authoring tool because data types are usually defined early in the design process. You must, however, merge the internal behavior file because this information is part of the model implementation.

For examples of how to generate AUTOSAR-compliant code and export AUTOSAR Software Component description XML files from a Simulink model, see the following demos.

Back to Top

Configuring AUTOSAR Options Programmatically

To control AUTOSAR options programmatically, use the AUTOSAR functions listed in the following tables in the Embedded Coder Function Reference documentation.

Back to Top

Verifying the AUTOSAR Code with SIL and PIL Simulations

Overview

You can carry out model-based verification of AUTOSAR software components using software-in-the-loop (SIL) and processor-in-the-loop (PIL) simulations. Use SIL for verification of generated source code on your host computer, and PIL for verification of object code on your production target.

Using the SIL and PIL Simulation Modes

You can run a top model or Model block that is configured for the AUTOSAR target (autosar.tlc) using the Software-in-the-Loop (SIL) and Processor-in-the-Loop (PIL) simulation modes.

For more information, see Top-Model SIL or PIL Simulation and Model Block SIL or PIL Simulation.

AUTOSAR Top Model SIL and PIL Support.  For a top model running in SIL or PIL simulation mode, the software does not support the following AUTOSAR features:

Logging Invariant Output Signals.  

Through signal logging, you can configure your top model to log invariant output signals. However, the software will log these invariant signals as periodically sampled data.

AUTOSAR Model Block SIL and PIL Support.  The software supports testing of AUTOSAR components that are modeled as model reference components. These model reference components are implemented as standard model reference Simulink Coder targets and do not contain any special AUTOSAR behavior.

Using a SIL or PIL Block for AUTOSAR Verification

To verify source code, you create a SIL block, which wraps the generated code in an S-function. The AUTOSAR target automatically configures the generated S-function to route simulation data using AUTOSAR run-time environment (RTE) API calls.

To verify the behavior of production-intent object code, you create a PIL block. You must provide an implementation of the target connectivity API for this block.

To carry out a verification using a SIL or PIL block:

  1. In the Configuration Parameters dialog box, select Code Generation, and clear the check box Generate code only. If you select Generate code only, the software does not create a SIL or PIL block.

  2. Select Code Generation > SIL and PIL Verification.

  3. From the Create block drop-down list, select either SIL or PIL. Click OK.

  4. To create your SIL or PIL block, generate code in the usual way. See Exporting AUTOSAR Software Component and Configuring Multiple Runnables.

  5. Once the SIL or PIL block is built, replace the existing component in your model with the new block.

  6. Simulate the model and check the output to verify that the code produces the same data as the original subsystem.

For more information about configuring and running simulations with SIL or PIL blocks, see Using a SIL or PIL Block.

AUTOSAR SIL and PIL Block Support.  The following features are not supported:

Runnable with Stateflow Chart Using Absolute Time.  

Consider a runnable (function-call subsystem) in a model, which contains a Stateflow chart using absolute-time temporal logic. Replace the runnable with a SIL block and run a simulation with the model. If the SIL block is executed conditionally in the model, then the results of the SIL simulation differ from the results of the Normal mode simulation.

Runnables in Feedback Loops.  

If your model has function-call subsystems and you export a runnable that has context-dependent inputs (for example, feedback signals), then the results of a SIL/PIL simulation with the generated code may not match the results of the Normal mode simulation of your model. See Exported Functions in Feedback Loops.

Back to Top

Limitations and Tips

Cannot Import Internal Behavior

Internal behavior is not parsed. This means any I/O information stored at the runnable level (for example, implicit or explicit) is not imported, and all internal I/O settings default to implicit. You can subsequently configure these I/O ports with the setIODataAccessMode method or in the Configure AUTOSAR Interface dialog box.

Cannot Copy Subsystem Blocks Without Losing Interface Information

If you copy and paste a subsystem block to create a new block in either a new model or the same model, the software does not copy the AUTOSAR interface information stored with the original subsystem block to the new subsystem block.

Source of Initial Output Value for Function-Call Subsystem Outport

Before exporting a runnable from a function-call subsystem with an outport, you must set the Outport block parameter SourceOfInitialOutputValue to Dialog. Otherwise, when you try to export the runnable, the software generates an error indicating this requirement. See Outport in the Simulink Reference.

Error If No Default Configuration

If you do not configure your model using the Get Default Configuration button or the RTW.AutosarInterface.getDefaultConf method, when you build the model the software produces an error message indicating this.

The Generate Code Only Check Box

If you do not select the Generate code only check box, the software produces an error message when you build the model. The message states that you can build an executable with the AUTOSAR target only if you:

Specify Sample Time Independent Server Operation Model

For a server operation model, MathWorks recommends that you set the Periodic sample time constraint on the Solver configuration parameters dialog pane to Ensure sample time independent. With this parameter, you can specify the sample time of the client model that invokes the server model (through an Invoke AUTOSAR Server Operation block) independently of the server model. If you do not specify this parameter, you need to check that the client block calls the server block at the same sample time. Otherwise, the data returned from the server model may be invalid.

Invoke AUTOSAR Server Operation Block in Referenced Model

The software does not support the use of the Invoke AUTOSAR Server Operation block in a referenced model.

Cannot Save Importer Objects in MAT-Files

If you try to save an arxml.importer object in a MAT-file, you lose all the information. If you reload the MAT-file, then the object is null (handle = –1), because of the Java™ objects that compose the arxml.importer object.

Using the Merge Block for Inter-Runnable Variables

You can use the Merge block to merge inter-runnable variables. However, you must do the following:

In addition, the signal from the function-call subsystem outport that enters a Merge block must not be conditionally computed. Consider the following example.

The output from the subsystem F_condition is the conditional output from Enabled Subsystem. When you try to validate or build the model, the software generates an error.

If you use an S-Function block instead of the Enabled Subsystem block, the software generates a warning when you validate or build the model.

Using Goto and From Blocks Within Wrapper Subsystems

If your wrapper subsystem contains Goto and From blocks, you can generate code and XML files for multiple runnables. However, you must:

AUTOSAR Compiler Abstraction Macros

The software does not generate AUTOSAR compiler abstraction macros for data or functions arising from the following:

Intrinsic Fixed-Point Types for Model Configured as Server

The software does not support operation prototype arguments with intrinsic fixed-point data types. For example, ufix5 shown in the following figure.

The software produces an error when you build the model.

To work around this limitation, before building the model, create a Simulink.NumericType base workspace object with the required property values. For example, to create a Simulink.NumericType object ufix5, enter the following in the Command Window: 

>> ufix5 = Simulink.NumericType;
>> ufix5.DataTypeMode = 'Fixed-point: binary point scaling';
>> ufix5.Signedness = 'Signed'
>> ufix5.WordLength = 16
>> ufix5.FractionLength = 0
>> ufix5.IsAlias = 1;
>> ufix.HeaderFile = 'Rte_Type.h'

For more information, see Simulink.NumericType in the Simulink documentation.

Server Operation Model with Tunable Parameters

The software does not provide AUTOSAR support for a model that is configured as a server operation and has tunable parameters with storage class set to SimulinkGlobal (Auto).

Migrating AUTOSAR Development Kit Models

Use the autosar_adk_migrate function to migrate an AUTOSAR Development Kit (ADK) model (from releases before R2008a) to the AUTOSAR interface.

Enter: 

autosar_adk_migrate(PATHNAME)

to migrate the ADK model/system specified by the full path name PATHNAME from the ADK settings to the new AUTOSAR interface. The model must be open before you invoke this function. MathWorks recommends that you save the migrated model to a different file name.

Back to Top

Demos and Further Reading

AUTOSAR Demos

For detailed explanations of AUTOSAR workflows with Embedded Coder software, see the demos in the following table.

DemoHow to ...
AUTOSAR Code Generation:
rtwdemo_autosar_legacy_script		Generate AUTOSAR-compliant code and export AUTOSAR Software Component description XML files from a Simulink model
Using an AUTOSAR Client-Server Interface
rtwdemo_autosar_clientserver_script		Configure and generate AUTOSAR-compliant code and export AUTOSAR-compliant XML files for a Simulink model with an AUTOSAR client-server interface
AUTOSAR Code Generation for Multiple Runnable Entities:
rtwdemo_autosar_multirunnables_script		Configure and generate AUTOSAR-compliant code and export AUTOSAR Software Component description XML files for a Simulink model with multiple runnables.
Import and Export an AUTOSAR Software Component:
rtwdemo_autosar_roundtrip_script		Use an AUTOSAR authoring tool with Simulink to develop AUTOSAR Software Components. Learn how to import software component interfaces into Simulink, modify and export them, and merge the completed software component back into an AUTOSAR authoring tool.
Using Data Stores to Access Per-Instance Memory:
rtwdemo_autosar_PIM_script		Publish an AUTOSAR Software Component with per-instance memory

Further Reading

For more information, see the AUTOSAR Web site: http://www.autosar.org/

Back to Top

  

Generating Code ModulesGenerating Code Modules Generating Reentrant Code from MATLAB CodeGenerating Reentrant Code from MATLAB Code

Related Products & Applications

Get Simulink trial software

Learn more about Simulink through this collection of videos, articles, technical literature and the Getting Started with Simulink Guide.

Get this Simulink Kit

 © 1984-2012- The MathWorks, Inc.    -   Site Help   -   Patents   -   Trademarks   -   Privacy Policy   -   Preventing Piracy   -   RSS