The Autosar Model is a software design model that can support both ECU software development and detailed architecture development.



The SystemWeaver views used to support this model are: 

Autosar Meta Model

Below is the basic SystemWeaver Autosar Meta Model. 

Components

The component types used include: 

  • Software component:  Represents the software logic
  • Sensor Actuator Software Component: Represents the interface to the hardware (abstraction of the driver)


Connection Model

The connection model used is implicit. This means that if one component sends a specific interface and another component receives the same interface the components are connected through that interface.



To multi-instantiate components, the components are added to instances representing the specific instances. The interfaces of the instantiated components are made unique on the edge of the instance.


Data Types

There are two types of data types. In some cases both are needed, for instance, when developing software that can run on different types of hardware (i.e., with floating point and without floating point processor)



Implementation Data Type

This type is used when implementing an ECU. It has both a CompuMethod describing the data type and a swBaseType describing the representation of the data type, e.g., uint8, int32, etc.



Application Data Type

This type is used to give input to do a signal database and when implementation is done later. It does not have a swBaseType since the specific representation of the signal is decided when designing the network.


Editing Data types

The Datatype view in SystemWeaver is used to edit data types. It is hard-coded and an available option when selecting any items included in the Autosar meta model. 


Note: The use of this view requires the SWExtension.Autosar extension for the swExplorer client.



It can be turned on and off in Configure the explorer by an Architect. 


Designing Using the Autosar Model

The system is often decomposed into smaller parts (functions, areas, etc.) where each part of the software is designed and later allocated onto ECUs. 


Component Graph

To graphically visualize the design, the Component graph view can be used. The Component graph is a C# plugin. Configuration of the Component graph is covered in a separate meta model training. 

Selecting a design function activates the Component graph menu option on the Items ribbon. This graphical view is interactive in that you can add components, add new interfaces to components, and connect interfaces directly in the graph!


Configuration of ECU Allocation

Software components need to be allocated to ECUs to document the system and document which ECUs are running the software. Allocation of software components is done using the ECU Allocation view.


The allocation is performed on the closest common parent to both the allocated and functional design.


The ECU allocation view is multi-configurable which means that the view can be instantiated several different times with different names. This is done using Configure the explorer.



Below is an example of ECU configuration where there is only one configuration <EcuAllocationConfig> being used. Additional uses can be added within the <EcuAllocationConfigs> tag. The tags are each described below as well. 


<EcuAllocationConfigs>
(A) <EcuAllocationConfig id="Config1">
(B) <ViewSettings>
<Caption>ECU Allocation</Caption>
<RibbonGroup>Design</RibbonGroup>
<Description>ECU Allocation</Description>
</ViewSettings>
(C)<DesignArchitecture>BIVD</DesignArchitecture>
(D)<FunctionalPath>/ITFD/ITAP/ITFC</FunctionalPath>
(E)<AllocationPath>/ITLD/ARPA</AllocationPath>
(F)<AllocationComponentPart>ARSC</AllocationComponentPart>
</EcuAllocationConfig>
</EcuAllocationConfigs>


id: Each instance of the ECU Allocation view should have a unique id. The id only needs to be unique for the ECU Allocation views in the one database. (A)

ViewSettings: Specifies the name of the menu button, the Ribbon group that the button should be placed in and the hover-text for the button. (B)

DesignArchitecture: Specifies for which item type the view will be activated, i.e., the closest common parent. In this case, it will be active when selecting the “Design architecture”. (C)

FunctionalPath: Specifies the path from the closest common parent, i.e., “Design architecture”, down to the software components in the functional architecture. This path specifies how to find the components that should be allocated. (D)

AllocationPath: Specifies the path from the closest common parent, i.e., “Design architecture”, down to all allocation targets (ECUs). This is the path to find all ECUs that components can be allocated onto. (E)

AllocationComponentPart: The part used to add components onto ECUs. (F)


Allocating Components

Once the ECU Allocation view has been configured, components can easily be added to ECUs. To access it, select the design architecture item. The option will then display on the Items ribbon. Click the ECU Allocation menu option. 

The view shows the design functions in gray and the components available for allocation in white. Each available ECU is displayed as a column. The colors in the matrix indicate the allocation and version status.


Red
 The component has not been allocated.
Green
The correct version of the component with respect to the design function is allocated onto the ECU.
Yellow
The version of the component on the ECU is of an incorrect version with respect to the design function


Exporting an Autosar System

When components are allocated onto ECUs, an Autosar description of the system can be generated using Autosar Export. The tool is a C# plugin called SWExtension.AutosarNetworkExport.dll. The export option is available when selecting an Autosar System item in the tree and is compatible with the Autosar meta model.



To export an Autosar System, select where the Autosar xml file shall be stored and click Export. 

Importing an Autosar System

Autosar descriptions of Systems, ECUs or components can be imported using Autosar Import. The Autosar Importer is a C# plugin called SWExtension.AutosarNetworkImporter.dll. Like the export tool, the import option is available when selecting an Autosar System item in the tree and is compatible with the Autosar meta model. To import, simply:

  1. Add the Autosar files
  2. Load the files (analyzes the Autosar description)
  3. Import the Autosar description which creates ECUs and components.