Standardizing data interchanges among design tools in the ECU development process: Pt. 2 - Function-driven development and basic software

by Joachim Stroop, dSPACE GmbH , TechOnline India - December 23, 2008

Development tools that can process automotive electronics system models and description formats are becoming established. This article discusses the potential uses of data interchange in an AUTOSAR tool chain example.

Part 1 of this feature covered system models, description formats, and design data management.

Function-driven development
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 here—when 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 {pagebreak}When these steps have been completed, an RTE is generated in SystemDesk. The generated code is used later in the software integration on the ECU, in conjunction with the code for the application component. In addition, an operating-system configuration and a communication configuration (OS and COM, respectively) can be derived and exported in SystemDesk. The OS and COM are available in EB tresos for completely configuring the communication stack and generating the code parts for the stack and operating system. This procedure is summarized in the graphic below.

    The AUTOSAR initiative is introducing new format standards in the development of ECU software. These standards allow reliable data exchange between the tools that support essential tasks within the design process, i.e., system design, function design, and configuration of the basic software, along with general tasks involved in process management and version handling. The tools presented here can process the AUTOSAR format standards and can be coupled seamlessly, thereby providing a range of tools for developing AUTOSAR-compliant ECU software.

    Joachim Stroop is lead manager for System and Function Design Tools at dSPACE GmbH.

  • Comments

    blog comments powered by Disqus