Part 1 of this feature covered system models, description formats, and design data management.
If an existing function model has to be used in a new AUTOSAR project, the interaction described in the architecture-driven development noted in Part 1 can also be initiated from the function view. This function-driven development process is shown in the figure below. If the function is available in the form of a TargetLink® (a production code generator) model, it can be migrated by using the TargetLink AUTOSAR Module. The associated data dictionary is used to specify the attributes that each AUTOSAR software component (SWC) requires. When the model has been completed, TargetLink automatically generates a component description in the form of an AUTOSAR XML file, in addition to generating the AUTOSAR-compliant C code.
This description is imported into SystemDesk architecture design tool as a new software component. It can then be integrated into an overall system by linking it to other components. The interfaces can be checked for compatibility. If they are not compatible, for example, because deviating fixed-point scaling was used, the component developers have to adjust the interfaces. The RTE (Runtime Environment) cannot be generated until all software components are correctly connected.
The iterative nature of the procedure should be emphasized herewhen the software architect changes the SystemDesk model, he or she also creates new versions of the software component descriptions for the responsible developer. Parts that are different than the old data are indicated in the dSPACE Data Dictionary Manager. If a developer then creates a new version of the software component, the SystemDesk model can be updated without important information being lost. For example, the connections between the components and their properties are preserved.
Application and basic software
Software architecture according to AUTOSAR is subdivided into a platform-independent application layer and the platform-dependent layer of the basic software. The RTE is the generated mediation layer in the architecture.
The various requirements that apply to the software at different levels are reflected in the tools that are usually used for development. The software components in the application layer can be created on a model basis and automatically transformed into C code. For the basic software, libraries or generators are often used. Thus, data exchange between the development tools involved has to be defined in a specific project.
This process will be explained by means of the tools SystemDesk and EB tresos®. For software integration on a single ECU, all the elements required by the application, by the ECU hardware, and by the network, are put together for the selected ECU in SystemDesk.
The following steps have to be performed: Map the software components to the ECU.
Connect the interfaces of the software components to the inputs and outputs of the ECU: In the figure below, the peripheral interfaces of the ECU are modeled in a separate, hierarchical software component IOHwAb (I/O hardware abstraction). This function provides the Microcontroller Abstraction Layer (MCAL), i.e., the drivers for items such as PWM, ADC, or DIO interfaces, in the form of a software component. The signal interfaces of the application can be connected to the abstracted peripheral interfaces via sensor and actuator components.
Assign data elements from the interfaces of the software components to bus signals; which is necessary for all data elements that will not be used locally but communicated to other ECUs.
Define an operating system configuration; including assigning so-called runnables to tasks, taking into account their dynamic properties.
View a full-size image