RTA-BSW User Guide V3.2 - ETAS · specialized rules such as multiplicity constraints. An ARXML ﬁle is deﬁned using an AU- ... 1.AUTOSAR Motivation and Goals 2.RTA-RTE User Guide

RTA-BSW v3.2.0RTA-BSW User GuideStatus: Release

ETAS

Copyright

The data in this document may not be altered or amended without special notification from ETAS GmbH.ETAS GmbH undertakes no further obligation in relation to this document. The software described in itcan only be used if the customer is in possession of a general license agreement or single license. Usingand copying is only allowed in concurrence with the specifications stipulated in the contract.

Under no circumstances may any part of this document be copied, reproduced, transmitted, stored in aretrieval system or translated into another language without the express written permission of ETASGmbH.

©Copyright 2019 ETAS GmbH, Stuttgart

The names and designations used in this document are trademarks or brands belonging to therespective owners.

Document RTA-BSW User Guide v3.2.0 R01 EN - 03.2019

RTA-BSW v3.2.0 RTA-BSW User Guide 2

ETAS CONTENTS:

Contents:1 Introduction 2

1.1 Applicable Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Safety Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Definitions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.4 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 How to use this User Guide 5

3 AUTOSAR 63.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.3 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.4 Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.5 Multi-core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 RTA-BSW Architecture and Workflow 174.1 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.2 Integration with ISOLAR-AB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.3 Activities and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174.4 Creating a System Template and Software Component Template . . . . . . . . . . . . 184.5 BSW Configuration Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.6 BSW Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.7 Handling Validation Errors Thrown By CodeGen . . . . . . . . . . . . . . . . . . . . . . 24

5 Limitations 26

6 Integration Hints 28

7 Integration Advice 297.1 SchM Enter and Exit API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.2 Configuration MemMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297.3 Callback functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

8 Migration 308.1 ConfGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308.2 CodeGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

9 Diagnostic Workflow 329.1 Importing ODX Files as DEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329.2 Additional Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

10ETAS Contact Addresses 4110.1 ETAS HQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4110.2 ETAS Subsidiaries and Technical Support . . . . . . . . . . . . . . . . . . . . . . . . . 41


ETAS Introduction

1 Introduction

The RTA-BSW User Guide describes how to work with the RTA-BSW product on electronic control units. Theguide also includes generic description of AUTOSAR BSW and the interactions between the componentsthat make up the BSW. RTA-BSW includes multiple stacks that aggregate related BSW modules:

∙ RTA-BASE System Services supporting ECU and BSW initialization

∙ RTA-COM for vehicle network communication

∙ RTA-CAN for CAN-based communication

∙ RTA-ETH for Ethernet-based communication

∙ RTA-LIN for LIN-based communication

∙ RTA-MEM supports persistent data storage

∙ RTA-DIAG supports ASW/BSW diagnostics and logging

∙ RTA-SAFE supports functional safety including watchdog

∙ RTA-XCP supports eXtended Calibration Protocol

∙ RTA-HWD(CAN) supports CAN hardware access

∙ RTA-HWD(Eth) supports Ethernet hardare access

∙ RTA-HWD(Lin) supports Lin hardware access

∙ RTA-SEC supports device based security

RTA-BSW is provided as a plug-in to the ETAS AUTOSAR Authoring Tool, ISOLAR-AB.

1.1 Applicable Versions

This document applies to RTA-BSW v3.2.0. This is compatible with:

∙ ISOLAR-AB v5.0.1

Within RTA-BSW, all stacks are at v3.2.0, with the following exceptions:

∙ RTA-OS

∙ RTA-RTE

which can be installed separately.

As far as possible the configuration of RTA-BSW and RTA-RTE uses standard ARXML and therefore theconfiguration aspects described in this User Guide are also applicable to later versions of the software.

1.2 Safety Notice

Warning: Any configuration(s) described in this User Guide are provided as an example onlyand must be reviewed and adapted for specific project requirements before use.

1.3 Definitions and Abbreviations

ARXML AUTOSAR XML used to describe SWCs, Systems and ECU configurations.

ASW AUTOSAR Application Software. In AUTOSAR the application consists of multiple com-municating SWCs including service, application and complex device driver SWCs.


ETAS Introduction

BSW AUTOSAR Basic Software modules. AUTOSAR defines a comprehensive BSW architec-ture consisting of service, interface and driver BSW modules that provide a device in-dependent ECU abstraction to ASW and thus promote SWC reuse and relocation. SeeSection 4 for a list of AUTOSAR BSW modules.

BSW Stack A slice through the AUTOSAR Layered SW Architecture that comprises function-ally related BSW modules from the Service, ECU Abstraction and Microcontroller Abstrac-tion layers.

CAN Controller Area Network – peer-to-peer message protocol designed for automotive use.

CDD Complex Device Driver – a custom BSW module for accessing hardware for which AU-TOSAR defines no standardized access. The form of the upper interface of a CDD isstandardized – ports – and therefore accessible to ASW using the RTE. However, the func-tionality provided by the CDD, for example how it accesses hardware, is implementationspecific.

DTC Diagnostic Trouble Code.

ECU Electronic Control Unit. In the context of AUTOSAR, an ECU comprises one microcon-troller/peripherals and associated ASW and AUTOSAR configuration. In particular, AU-TOSAR does not consider the mechanical design in the definition of an ECU and thus if asingle housing contains multiple microcontrollers each requires its own AUTOSAR config-uration and BSW stack.

E/E Electrical and Electronic.

FlexRay Automotive bus supporting high data rate communication with a static, time-sliced,segment providing real-time messages and a dynamic segment for event-triggered com-munication.

EEPROM Electronically Erasable Programmable Read-only Memory.

I-PDU Interaction Layer PDU.

IOC Inter-OsApplication Communication – OS API for sending and receiving data betweenOsApplications.

MCAL Microcontroller Abstraction Layer – the lowest software layer of the Basic Softwarewithin the AUTOSAR SW architecture. The MCAL contains internal drivers (BSW with di-rect access to the microcontroller and its internal peripherals) and serves to make higherlayers independent of the microcontroller.

OSEK Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug (OpenSystems and their Interfaces for the Electronics in Motor Vehicles). OSEK include thespecification of OSEK-OS and OSEK-COM which were used as the basis for the AUTOSAROs and Com BSW modules

PDU Protocol Data Unit – a set of messages sent/received over a network as a coherent entity.

PIM Per-Instance Memory – provides instance-specific state accessed through an RTE gener-ated API.

Schema A XML file that describes the permitted structure and content type of another XMLfile including data types, available elements and their permitted order as well as morespecialized rules such as multiplicity constraints. An ARXML file is defined using an AU-TOSAR supplied schema.

SPI Serial Peripheral Interface – synchronous serial interface using a master-slave architec-


ETAS Introduction

ture and widely used in automotive embedded systems.

SWC AUTOSAR Software Component – Functional unit within ASW. An AUTOSAR applicationconsists of multiple SWCs.

TP Transmission Protocol – Transport mechanism used to transmit and receive I-PDUs largerthan a single bus frame.

UDS Unified Diagnostic Services – Standardized set of diagnostic services defined byISO—15765 and supported by the AUTOSAR Dcm module.

VFB AUTOSAR Virtual Function Bus. The VFB is an abstract composition of the ASW includingall SWCs in the system their connections but not the mapping to particular ECUs. TheVFB enables integration of ASW to occur early in the development phase and permitsverification of the consistency of the communication relationship between SWCs.

1.4 Bibliography

1. AUTOSAR Motivation and Goals

2. RTA-RTE User Guide

3. RTA-OS User Guide

4. RTA-BSW Installation and Getting Started Guide, v3.2.0, ETAS GmbH

5. ISOLAR-AB Getting Started Guide, ETAS GmbH

6. RTA-OS Getting Started

7. RTA-RTE Getting Started Guide

8. RTA-BSW Reference Manual, v3.2.0, ETAS GmbH

1.5 Conventions

OCI_CANTxMessage msg0 Code snippets are shown in a monospaced Couriertypeface.

Choose File->Open. Menu commands and buttons are shown in boldface.

Press <ENTER>. Keyboard commands and variable text items areshown in angled brackets.

The ‘Open File’ dialog box is displayed. Names of program windows, dialog boxes, fields, etc.are shown in quotation marks.

Select the file setup.exe Path and file names, new terms and general empha-sis are shown in italics.


http://www.autosar.org/about/basics/motivation-goals/

ETAS How to use this User Guide

2 How to use this User Guide

The RTA-BSW User Guide describes how to work with RTA-BSW within a development process forAUTOSAR-based ECUs.

AUTOSAR provides an introduction to AUTOSAR BSW and the three key concepts:

∙ Architecture

∙ Methodology

∙ Interfaces.

Readers already familiar with AUTOSAR development can skip this section.

RTA-BSW Architecture and Workflow describes how to use RTA-BSW based on an example workflow. Thisincludes:

∙ How to use the ConfGen tool to derive the BSW configuration from the System Description.

∙ How to use the CodeGen tool to generate the BSW source code.


ETAS AUTOSAR

3 AUTOSAR

This chapter introduces the AUTOSAR initiative and explores the key AUTOSAR concepts of architecture,methodology and interfaces that together contextualize RTA-BSW.

3.1 Motivation

The AUTOSAR initiative arose from a recognition that the complexity of automotive software was everincreasing and that this complexity was likely to prove overwhelming as the amount of software in avehicle increased exponentially. The principal motivations of AUTOSAR [1] directly address the increasingcomplexity:

∙ Management of E/E complexity associated with growth in functional scope.

∙ Scalability of solutions within and across product lines.

∙ Improved quality and reliability of E/E systems.

AUTOSAR aims to meet these goals through the definition of a modular development approach – withan emphasis on configuration – that permits the integration of solutions from multiple suppliers usingwell-defined roles and responsibilities. The AUTOSAR approach relies on three key concepts:

∙ Architecture – Definition of an automotive SW architecture (including a comprehensive BSW stack)providing progressive degrees of abstraction that promote application and basic software re-use andre-locatability.

∙ Methodology – Definition of a systematic method of working between suppliers and OEMs that per-mits seamless interactions with a common configuration language.

∙ Interfaces – Definition of the syntax and semantics of interactions including the interfaces betweenmodules in the architecture and between suppliers and OEMs when exchanging solutions.

3.2 Architecture

AUTOSAR focuses on embedded automotive ECUs and therefore the AUTOSAR SW architecture exhibitscertain key properties:

∙ Strong Hardware Interaction – automotive application software (ASW) makes extensive use of sensorsand actuators in the ECU hardware.

∙ High Network Interaction – a vehicle contains multiple networks and each ECU connects to at leastone of the networks.

∙ Limited Computational Resources – the microcontrollers used have limited resources – both comput-ing power and memory.

∙ Real-time – ASW must respond to stimuli within a certain time limit.

The complexity of automotive software has increased rapidly in recent years. AUTOSAR aims to providea mechanism to control that complexity while retaining the properties above.

3.2.1 AUTOSAR Layered SW Architecture

The AUTOSAR Layered SW Architecture is the key to how AUTOSAR provides a mechanism to manage thecomplexity of automotive software. The AUTOSAR architecture structures ECU software as a hierarchyof application software (ASW, consisting of multiple SWCs) and basic software (BSW) modules. Withinthe architecture description, AUTOSAR defines a mapping of the ASW/BSW to architectural layers, theresponsibilities of each layer and the relationship between BSW modules.


ETAS AUTOSAR

Fig. 3.1: Layers within the AUTOSAR SW Architecture

The figure above shows the layers within the AUTOSAR Layered SW Architecture. Each layer encapsu-lates and abstracts the functionality and behaviour of the layer below:

Application Software AUTOSAR models application software as collection of loosely cou-pled and highly cohesive SWCs. This design enables modular application developmentand independent implementation/test of individual SWCs (modules). A loosely coupledarchitecture implies limited dependencies between SWCs and is desirable to permit therelocation of SWCs on different ECUs without changing the system design. Likewise, ahighly cohesive architecture limits the individual responsibilities of a module – an indi-vidual SWC will typically perform a small set of tasks. When combined with a looselycoupled architecture, a highly cohesive set of SWCs enables the development of robustsystems of reusable components.

AUTOSAR Run-Time Environment (RTE) The RTE provides communication and schedulingservices to application software. The purpose of the RTE is to make application softwareindependent of a mapping to a specific ECU. This permits SWCs to be reused or relocatedto different ECUs in a vehicle.

Service Layer Modules that provide basic services for applications, RTE, and BSW modules.

ECU Abstraction Layer Provides an API for access to peripherals and devices regardless oftheir location (microcontroller internal/external) and their connection to the microcon-troller (port pins, type of interface). The ECU Abstraction provides an interface to theServices Layer that is both microcontroller and ECU independent.

Microcontroller Abstraction Layer (MCAL) The lowest software layer of the AUTOSAR Ba-sic Software containing drivers for internal devices, such as Fls and Eep, and memory-mapped external devices. These drivers have direct access to the internal hardware.

Microcontroller Hardware Contains “internal” devices located inside the micro-controller,e.g. internal EEPROM or CAN controllers. Driver for internal devices are located in theMicrocontroller Abstraction Layer

The aim of the AUTOSAR Layered SW Architecture is to increase the re-usability of the application soft-ware by providing an abstract, uniform and standardized interface between the application SW and thehardware in the form of the BSW. By increasing re-usability the overall complexity of automotive soft-ware is also reduced as repeated work. Each layer of the AUTOSAR SW architecture encapsulates somedependency:


ETAS AUTOSAR

∙ The Service Layer offers abstracted services to both ASW (through the Run-time Environment) andother BSW modules. The facilities offered by the abstracted services are available on any AUTOSARECU promoting the portability and re-use of ASW.

∙ The ECU Abstraction Layer provides an AUTOSAR defined abstraction layer between the micro-controller hardware layout (e.g. number and type of CAN controllers) and the Service Layer above.This ensures that the Service Layer can operate without regard fot the particular characteristics ofthe individual ECU hardware.

∙ The Microcontroller Abstraction Layer (MCAL) contains the drivers for internal MCU hardwaredevices and encapsulates hardware specific characteristics of the MCU. This encapsulation providesan AUTOSAR defined interface to the ECU Abstraction Layer that makes it independent of the MCUhardware.

3.2.2 BSW Module Classification

As well as their assignment to layers within the AUTOSAR SW architecture, BSW modules can be furtherclassified as belonging to one of a number of module types. Each type has particular characteristics andresponsibilities:

Interface BSW module providing a functional abstraction of the associated Driver modulethrough the provision of a generic API that is independent of the characteristics of thedevice. An Interface module does not change data before passing to the Driver. Typically,Interface modules are located in the ECU Abstraction Layer.

Handler BSW module that is an Interface module that also supports concurrent access and/orasynchronous access by multiple clients. A Handler will typically perform buffering andarbitration. Since it is a form of Interface, it does not change data. AUTOSAR includes fewspecific Handler modules since the functionality is usually combined within an Interfaceor Driver module.

Manager BSW module that offers specific services to multiple clients simultaneously. A man-ager extends that Handler use-case to support abstraction for multiple clients where thisis not possible for a pure handler. However, unlike a handler a manager can changeand/or adapt the data before passing to the Interface. A Manager is typically located inthe Service Layer.

Driver BSW module that controls a specific HW device. A driver can control either internal orexternal devices. Drivers for internal devices and memory-mapped external devices arein located in the Microcontroller Abstraction Layer since they access the microcontrollerdirectly. Drivers for external devices are located in the in ECU Abstraction Layer.

Complex Device Driver (CDD) BSW module that spans the architecture having both a di-rect interface to microcontroller hardware as well as providing an AUTOSAR interface foraccess by ASW. The functionality of a CDD is not standardized by AUTOSAR however, theupper interface is configured using ports and therefore accessible by ASW through theRTE.

Note: Use of a CDD by ASW implies a dependency on specific hardware capabilities of theECU and therefore a reduction in the portability of the ASW.

Library A collection of related utility functions accessible by all BSW modules and the RTE. Alibrary function is re-entrant (can be invoked by multiple BSW modules simultaneously),stateless and executes in the context of the caller. AUTOSAR specifies libraries for bithandling, interpolation, cryptography, etc.


ETAS AUTOSAR

3.2.3 BSW Stack

A BSW stack defines a slice through the AUTOSAR Layered SW Architecture that comprises modules fromthe Service, ECU Abstraction and Microcontroller Abstraction layers. At a high-level, the functionalityoffered by the layers within the AUTOSAR Architecture is described by the functional blocks as shownin the figure below: The functional blocks form the basis for the BSW stacks that collectively compriseRTA-BSW.

Fig. 3.2: AUTOSAR Layered SW Architecture – High Level Structure

A BSW stack is typically defined on a functional level and consists of modules that cooperate to providefunctionally related services to the application layer. The following stacks are considered in this UserGuide:

RTA-BASE ECU and BSW initialization and state management.

RTA-COM Vehicle network communication using Com, PduR and bus-specific modules.

RTA-MEM Persistent (across driving cycles) storage using non-volatile memory.

RTA-DIAG Event logging and interaction with post-driving cycle diagnostic and service.

3.2.4 BSW Interactions

AUTOSAR defines how and when BSW modules within the Layered SW Architecture can interact.


ETAS AUTOSAR

Fig. 3.3: BSW Interactions within the AUTOSAR Layered SW Architecture

Within the Services Layer, AUTOSAR permits “horizontal” interactions between modules, e.g. the Demmodule saves fault data using the NVRAM manager both of which are service modules. Likewise, AU-TOSAR permits horizontal interactions between modules in the ECU Abstraction Layer. However, hori-zontal interactions are not allowed between modules in the Microcontroller Abstraction Layer. AUTOSARmakes an exception for complex drivers; these are permitted to use horizontal interfaces to any BSWmodule. A “vertical” interaction occurs when one SW Layer accesses interfaces of the SW layer aboveor below. Single vertical interactions, e.g. from Service Layer to ECU Abstraction Layer, are clearly per-mitted since they define the interfaces that connect stacks together. In addition, a BSW module mayaccess a lower layer module of another layer group, e.g. SPI for external hardware. The bypassing ofone software layer – i.e. a vertical interaction that skips a layer – should be avoided and is discouragedwithin AUTOSAR and not used by the standardized BSW. AUTOSAR does not permit the bypassing of twoor more software layers. To avoid dependencies on hardware, AUTOSAR does not permit the bypassingof the MCAL by modules within the Service and ECU Abstraction Layers. Finally, any BSW module in anylayer may interact with system services. This exception is important for services provided by the Operat-ing Systems since it means that a single mechanism for data consistency and scheduling can be appliedto the BSW.


ETAS AUTOSAR

Fig. 3.4: AUTOSAR Layered SW Architecture Interaction MatrixThis figure shows the AUTOSAR defined permitted interaction matrix for modules within the BSW. The figure is

intended to be read row-wise and the circle indicates access via a call-back only.

A Complex Device Driver (CDD) has unique characteristics in the AUTOSAR architecture. It provides astandardized mechanism for accessing non-standard microcontroller hardware directly and providing anAUTOSAR interface accessible by ASW through the RTE. Due to its position within the layered architectureit has restricted access to BSW modules based on the following rules:

∙ A BSW module that is accessed by a CDD must expose a configurable interface (e.g. specify thenames of call-back routines).

∙ The BSW module interface must be re-entrant because access from both the upper-layers and theCDD may occur.

∙ In addition, a BSW manager module must not be used because interactions between the calls fromthe manager and the CDD may leave the module in an invalid state.

3.3 Methodology

The AUTOSAR Methodology defines how ECU software is developed by dividing the development processinto a number of separable actions that cover all aspects of ECU SW development from the creation of asystem-level description through to generation of each ECU’s executable.


ETAS AUTOSAR

Fig. 3.5: AUTOSAR Methodology

The AUTOSAR methodology works in conjunction with the AUTOSAR Interfaces that standardize the dataexchange formats used within the development process.

3.3.1 System Design

The System Design phase defines the abstract application architecture, network topology and mappingof application to ECUs and communication to network signals.

∙ Application architecture is described using the concepts of the AUTOSAR Virtual Function Bus (VFB).The VFB comprises an abstract view of ASW and their interconnections and thus enables integrationof ASW to occur early in the development phase.


ETAS AUTOSAR

∙ The network topology – what signals are present and on to which networks they are mapped, whatbuses are present in the vehicle and how they are connected to ECU instances.

∙ The software mapping of ASW to ECUs.

The result of the System Design phase is an AUTOSAR System Description consisting of one or moreARXML files. The System Description describes the entire vehicle architecture and can therefore grow toa significant size. Since it contains all information about the vehicle (some of which will be proprietary) itmay not be allowed for an OEM distribute the entire System Description to a supplier.

As a result, the AUTOSAR methodology defines a sub-process within System Design to derive either aSystem Extract (containing information pertaining to one functional sub-system) or an ECU Extract (con-taining information for a single ECU) from the complete system description. This allows relevant systeminformation to be provided to the suppliers without also providing unnecessary proprietary information.

Fig. 3.6: AUTOSAR System Description, System Extract and ECU Extract hierarchy

3.3.2 ECU Configuration

An ECU Extract of the System Description contains sufficient information for configuration/generationof the BSW modules and the RTE for a single ECU. For example, the ECU Configuration (ECUC) ValueCollection for an ECU Extract will define the signals (frames) that are sent/received by that ECU and noothers. The ECU extract is derived from the System Description by removing elements of other ECUs –this process is automated by ISOLAR-AB.

3.3.3 BSW and RTE Generation

RTA-BSW provides two separate tools to aid the user in generating embedded BSW Code. These are:

RTA-BSW ConfGen The ConfGen tool provides an automated method to derive a defaultECU Configuration from a System Description, System Extract or Ecu Extract.

RTA-BSW CodeGen The CodeGen tool provides a suite of Code Generators that produce theembedded code for the BSW modules using the provided ECU Configuration.

The integrator is responsible for applying any desired manual updates (using ISOLAR-AB) to the defaultECU Configuration produced by ConfGen before invoking the CodeGen tool to generate the BSW embed-ded code.

3.3.4 Application Development

The ASW Development process is largely independent of System Design. The latter requires only alimited set of information about each SWC, e.g. the ports used to communicate, and therefore ASWdevelopment can proceed in parallel with System Design. The AUTOSAR methodology thus permits theindependent implementation and testing of SWCs. By separating the implementation and test of differentSWCs AUTOSAR promotes re-use of the SWC within a new ECU and simplifies integration by the OEM.


ETAS AUTOSAR

3.4 Interfaces

The AUTOSAR Interfaces defines when and how participants within the AUTOSAR Methodology, such asOEM and supplier, exchange information.

3.4.1 Data Exchange Formats

AUTOSAR defines several standardized data formats for exchanging information related to SWC, Systemsand ECU configuration descriptions.

SWC Description ARXML describing the interfaces, dynamic behavior and resource require-ments of the SWC. The syntax and semantics of the SWC Description are described bythe AUTOSAR Software Component Template and is typically created by the supplier andprovided to the OEM along with the relevant source or object-code implementation files.

BSW Module Description ARXML describing the interfaces, dynamic behavior and resourcerequirements of a BSW module. The syntax and semantics of the BSW Module Descrip-tion are described by the AUTOSAR BSW Module Description Template and is typicallycreated by the BSW generation process for BSW modules that present an AUTOSAR in-terface to the RTE.

System Description ARXML description of vehicle E/E architecture including network topol-ogy and signals, ECU topology and SWC mapping to ECUs. The AUTOSAR System Tem-plate defines the syntax and semantics of a System Description.

ECU Extract ARXML description for an ECU provided by the OEM to the ECU supplier. TheECU Extract, in conjunction with the ECUC Description, permits configuration and gener-ation of the BSW and RTE for the ECU. The AUTOSAR System Template defines the syntaxand semantics of an ECU Extract (this is the same AUTOSAR configuration syntax usedfor the System Description).

ECUC Description ARXML description of BSW configuration parameters and derived fromthe ECU Extract and BSW Module Descriptions. The ECUC Description uses a system ofcontainers that group the corresponding parameters and, optionally, sub-containers. Theparameters configure the specific parts of BSW, e.g. a top-level Com container containsthe entire configuration for the module. The Com container will include multiple subcontainers (that in turn may contain additional sub-containers) that configure differentaspects of the module including the ComSignals, etc.

The system of containers and parameters that form the ECUC Description is defined by an AUTOSAR-supplied ECU Configuration Parameter Definition file. This ARXML file defines the available containersand parameters for every standardized BSW module. The approach is both flexible and extensible – ven-dor specific parameters can also be modelled through additional ARXML description file that describeshow and when the parameters should be defined. All AUTOSAR data exchange formats use XML consis-tent with a schema defined by AUTOSAR. Since both supplier and OEM use the same schema, a commoninterpretation of the exchange is possible. The AUTOSAR schema is updated with each release of AU-TOSAR to reflect new and modified features.

3.4.2 Interfaces in the Layered SW Architecture

Within the Layered SW Architecture, AUTOSAR distinguishes between three different API forms:

∙ AUTOSAR Interface – AUTOSAR define the syntax using the Software Component Template. The SWCimplementer defines the semantics, e.g. the data items transmitted or received using the interface.

∙ Standardized AUTOSAR Interface – AUTOSAR defines both the syntax and semantics. The SoftwareComponent Template defines the syntax. The respective AUTOSAR specification defines the interfacesemantics, i.e. what ports, data items and operations are included in the interface.

∙ Standardized Interface – both the syntax and semantics defined by AUTOSAR and consisting of C


ETAS AUTOSAR

functions.

The figure below shows the interface forms used within the AUTOSAR Architecture.

A Service Layer BSW module can present either a Standardized AUTOSAR interface or a StandardizedInterface to the upper layer RTE as AUTOSAR define both the syntax (interface form) and semantics(behavior of the module) to ensure portability of ASW. In contrast, ASW use AUTOSAR Interfaces sinceAUTOSAR defines only the syntax of data exchange format, the Software Component Template. The userdefines the semantics of the interface embodied within the application functionality.

Fig. 3.7: Interfaces in the AUTOSAR Layered SW Architecture

3.5 Multi-core

RTA-BSW does not support the distribution of BSW across multiple ECU Partitions and therefore micro-controller cores. As a result, the following constraints apply when using a multi-core ECU:

∙ All BSW modules must be mapped to a single ECU partition

∙ The ECU partition containing the BSW must set the ECUC parameterEcucPartitionBswModule-Execution to true.

∙ All other ECU partition must also set the ECUC parameter EcucPartitionBswModule-Execution tofalse.

The Os module (RTA-OS) supports multi-core applications and the EcuM module can be configured tostart the OS on each applicable core. The RTE (RTA-RTE) supports multi-core applications with elementsof the ASW mapped to multiple ECU partitions. The RTE uses the OS’s IOC API for communication betweenSWCs in different partitions and this mechanism does not support access to BSW which uses a C functionbased API to interface with the RTE. Consequently, RTE and BSW interactions must occur within the same


ETAS AUTOSAR

ECU partition.

Warning: Any ASW that needs access to BSW (e.g, to NvM for non-volatile memory use orCom for inter-ECU communication) must be mapped to the same ECU partition as the BSW.

It is not always possible to map the ASW SWCs that access BSW to the same ECU partition as the BSW,e.g. different partitions may have software with different safety integrity levels. If this is the case, thena proxy SWC within the BSW partition forwards access to the BSW from ASW in a different partition.

The figure below illustrates a system where BSW access by SwcB is forwarded using RTE generatedinter-partition communication to SWC Proxy in the same partition as the BSW.

Fig. 3.8: Multi-core access to BSW using proxy SWC


ETAS RTA-BSW Architecture and Workflow

4 RTA-BSW Architecture and Workflow

4.1 Installation

RTA-BSW is provided as a plug-in to ISOLAR-AB; please consult the separate RTA-BSW Installation andGetting Started Guide [4] for detailed installation instructions.

RTA-OS and RTA-RTE are not installed as part of RTA-BSW. Refer to the RTA-OS Getting Started [6] and RTEGetting Started Guide [7] documents for installation instructions for these modules.

4.2 Integration with ISOLAR-AB

RTA-BSW is a plug-in for the ISOLAR-AB AUTOSAR Authoring Tool. The RTA-BSW plug-in comprises twotools, ConfGen and CodeGen, used to create configuration and code for services and ECU abstractionmodules.

∙ ConfGen – traverses the AUTOSAR System Template (EcuInstance, SystemSignal, etc.) and createsan equivalent configuration in EcucValueDescription format, which allows specific parametrizationand is the input for BSW code generation tools.

∙ CodeGen – an AUTOSAR BSW code generation tool, consuming configuration in EcucValueDescriptionformat to create source code equivalent in .c/.h format using the RTA-BSW Code Generator.

The following sections (BSW Configuration Generation, BSW Code Generation) provide information onusing these two tools focusing on the different options that they present.

4.3 Activities and Outputs

RTA-BSW Activities and Outputs illustrates the activities and generated outputs present in the intendedworkflow for the RTA-BSW plug-in.

This workflow contains some key steps:

1. The AUTOSAR System Description ARXML file(s) are created entirely using an AUTOSAR AuthoringTool, such as ISOLAR-AB, or by importing information from legacy files, such as DBC.

2. The user augments the System Description with additional ASW configuration, i.e. SWCs and com-positions, using the AUTOSAR Software Component Template ARXML to define the VFB Configura-tion.

3. RTA-BSW ConfGen uses the System Description and ASW Configuration(s) to create a default BSWConfiguration using ECUC Value Collection ARXML.

4. The default BSW Configuration extended with additional configuration provided by the user.

5. RTA-BSW CodeGen generates the BSW implementation – this includes C source code and, for mod-ules that present an AUTOSAR interface to the RTE, one or more BSWMD files for inclusion with theRTE generator’s configuration.



Fig. 4.1: RTA-BSW Activities and Outputs

4.4 Creating a System Template and Software Component Template

As shown in Figure 10, RTA-BSW operates on an AUTOSAR System Template and upon Software Compo-nent Templates to generate the BSW Configuration. The ISOLAR-A Getting Started Guide [5] describeshow both types of template are prepared. The RTA-RTE Getting Started Guide [7] also provides configura-tion advice, for example data mappings for complex data types. The use of legacy file imports provides aroute to quickly populating the system template with some information that ConfGen can use to generateBSW configuration automatically.

4.4.1 Legacy File Import

ISOLAR-A supports the import of a number of different legacy file formats to perform the initial populationof the AUTOSAR System Description. RTA-BSW ConfGen (described in 4.5) uses imported legacy files togenerate configuration for specific BSW modules as shown in below:

File format Modules configured automatically

DBC RTA-CAN (CanIf, CanNM, CanSM) RTA-COM (Com, ComM, IpduM, Nm, PduR)

Using ISOLAR-AB to import legacy file formats is described in Section 5.3 (“Creating an AUTOSAR SystemTemplate in ISOLAR-AB”) of the ISOLAR-AB Getting Started Guide [5].

4.5 BSW Configuration Generation

The RTA-BSW ConfGen tool generates BSW configuration information using data from the System Tem-plate and from Application Software Component Templates. To start ConfGen:

1. Select an AUTOSAR Project.

Note: The selected project should contain at least the System Template Description (i.e. theSWCs, their mapping to ECUs, network information including mapping data communicated bySWCs to network signals) To make full use of this tool it is recommended that the completeVirtual Functional Bus (VFB) configuration is present.

2. Click on the ConfGen toolbar icon.

3. Select the ECU Instance for which you wish to generate the EcucValueDescription values.



4. Click [OK] and the ConfGen process will begin, reporting results to the console.

When ConfGen completes, the project will contain EcucValueDescription ARXML files and Parameter def-initions (ParamDefs). This will allow you to customize the ECU configuration and generate AUTOSARBSW.

4.5.1 Repeating Configuration Generation

If a BSW configuration already exists, then BSW Import ( button) deletes the following files before re-creating them with the replacement configuration:

∙ Project_EcucValues.arxml – ECU configuration values for all modules (apart from CAN).

∙ Can_EcucValues.arxml – ECU configuration values for CAN.

Warning: Repeating ConfGen will delete and then recreate the Project_EcucValues.arxml andCan_EcucValues.arxml files. As a result, the process will also delete any changes made by theuser that are contained within these files.

The AUTOSAR splitable mechanism provides a means to ensure that additions to the default configu-rations are not lost when regenerating the configuration. To exploit the splitable mechanism, defineadditional Ecuc parameters and reference values in separate ARXML files using the same ARPackage andEcucContainer structure as the default values.

The RTA-BSW generation tools – RTA-OS, RTA-RTE and RTA-BSW – will ensure that the split items in different



Ecuc containers are “combined” to form a single item.

4.5.2 ConfGen Parameters

It is possible to change the default values used by ConfGen to produce the default ECU Configuration.

Adding a rule to the Settings/algo.properties file found in the System project will override the defaultvalue used by ConfGen if the user cannot otherwise change the value by configuring the system template.

Note: algo.properties is only able to change default values that cannot otherwise be config-ured in the System Template.

Rules in the algo.properties file take the form of a comma-separated list of defaults:

manprop_{module}_{specifier} = {parameter}:{default_value}, ...

{module} The name of the module that contains the parameter.

{specifier}

∙ ALL to apply to all instances of the module.

∙ The SHORT-NAME of the instance to apply the parameter.

{parameter} The name of the parameter to set. (If there is a naming collision in the module,it is necessary to use the full path of the parameter)

{default_value} The new default value to use.

Can Mailbox Mapping

Some hardware requires that the Can Mailboxes are presented in a particular order. This can be sup-ported by setting a mailbox mapping rule in the algo.properties file.

If the MbSortingPref rule is specified, the mailboxes will be ordered alphabetically with a comma-separated list of sorting criteria:

MbSortingPref=criteria1, criteria2,...

The criteria can be one of:

∙ canHandleType

∙ canAddressingMode

∙ direction

∙ controllerName

∙ mask

∙ canControllerId

The ordering for a criteria will be reversed by prepending the optional ~ the desired criteria. For example:

MbSortingPref=direction,~controllerName,canHandleType

Warning: The behaviour is undefined when a criteria is to be sorted both forwards and re-versed.



Can Controller Mailbox Assignment

The number of mailboxes assigned to a Can Controller may be configured in the algo.properties file usingthe following rule:

NumberofMB_{SHORT-NAME}={max_mailboxes}

{SHORT-NAME} The short name of the Can Controller being configured.

Note: If this rule is not specified then there is no limit to the number of mailboxes that can beassigned to a controller.

One mailbox will be assigned for each frame if possible. Should there be more frames than the mailboxlimit then the following steps will be performed in order until the limit is no longer exceeded.

1. All Standard RX messages are combined into one Mailbox, all Extended RX messages are com-bined into one Mailbox, all Tx messages with a period less than property PduTimingLimit will geta dedicated Mailbox.

2. If either the remaining number of Standard or Extended messages are smaller than half the remain-ing mailboxes then these are assigned one Mailbox each and the other messages packed.

3. If there are more Standard and Extended messages than half of the remaining Mailboxes then theStandard Mailboxes are packed into half the remaining Mailboxes and the Extended in the remaininghalf.

4.6 BSW Code Generation

The RTA-BSW Code Generation tool ‘CodeGen’ generates source code and header files (.c/.h) for thecurrently selected project. You can run the CodeGen tool either from within ISOLAR-AB, or outside theapplication using the Windows CLI (Command Line Interface).

The process of code generation is controlled by the launch configuration, which contains parametersrelating to how the code will be generated. The settings in the launch configuration control which moduleswill be included, which installed version(s) of RTA-BSW will be used, the path used for the output and otheroptional settings.

If you do not specifically create a launch configuration, a default launch configuration will be createdwhen the CodeGen process is started. In this case, module selection will be based on the BSW con-figuration you created with the ConfGen tool (see BSW Configuration Generation) and the version(s) ofRTA-BSW selected in the project. The output path will default to {ProjectPath}/src/BSW/Gen.

4.6.1 Running CodeGen from ISOLAR-AB

If you want to run CodeGen using the default launch configuration, you may skip steps 1 through 4.Otherwise, begin from step 1.

1. From the Run menu, select Run Configuration.

2. In the Run Configurations dialog, right-click on the CodeGen Launch Configuration entry andthen select New from the pop-up menu.



3. In the BSW Generation Config dialog tab, set the following options:

∙ Select RTA-BSW Click Select and then choose the installed versions of RTA-BSW to be supported.This will control the available modules displayed in the Modules pane as long as a valid project isselected.

∙ Select Project Click Select and then choose the workspace project the configuration will be appliedto. If this is a valid AUTOSAR project and an RTA-BSW version has been selected, then the list ofmodules will be populated with available modules.

∙ Select Output Path Click browse and then select the desired output folder (by default the path willbe set to {ProjectPath}/src/BSW/Gen. The process will then organise the generated files by modulein the selected directory.

∙ Module List Use the tick box selectors to indicate which modules will be included in the code gen-eration.

∙ Generate C/H Select this option to output the dynamically generated .c/.h source files for the se-lected modules.

∙ Generate ARXML Select this option to output the dynamically generated *.arxml configuration filesfor the selected modules.



∙ Generate static BSW Code When selected CodeGen will output only the static .c/.h source files forthe selected modules.

∙ Generate Integration Code Select this option to output the example integration .c/.h source filesfor the selected modules.

∙ Delete Existing Output Folder Select this option to delete any previously generated code beforegenerating the new code.

4. When you have set all the options you require, click Apply and then click Close.

5. On the ISOLAR-AB toolbar, click the CodeGen button.

Code generation will now take place, using either the launch configuration you specified previously, or thedefault launch configuration if you skipped steps 1 through 4. Note that the default launch configurationwill include ALL applicable modules. The generated files will be created in the specified output directory.

Note: For more information about the modules that can be generated, please refer to theRTA-BSW Reference Manual [8]. Stacks that do not have a valid license will be disabled.

Note: Temporary generated configuration values (EcucValues passed from one module toanother during code generation) are available in _fwd/ecuc_configuration_values_fwd.arxmland should not be modified. These configuration values will be regenerated and used duringcode generation.

4.6.2 Running CodeGen from the Command Line

When running CodeGen from the Windows CLI, default launch configurations are not created. Thereforeyou must create a launch configuration for the project from within the ISOLAR-AB application beforeattempting this procedure.

The procedure below assumes the use of Windows 10. In earlier version of Windows, the commandprompt may be invoked using the Command Prompt shortcut on the Start menu or by running theexecutable program cmd from the Run window.

Note: Adding the ISOLAR-AB installation folder path to your Windows environmental variablePATH will allow you to run the CLI version of CodeGen from any folder.

To run CodeGen from the Windows CLI, follow these steps:

1. If you have not already done so, follow steps 1 through 4 as described in Running CodeGen fromISOLAR-AB to create a launch configuration for the project.

2. In Windows Explorer, navigate to the ISOLAR-AB installation folder (by default this is C:ProgramFilesETASISOLAR-ABx.x).

3. With the folder selected, type cmd followed by <ENTER> in the address bar. This will open a com-mand prompt in the selected folder.

4. On the command line, type bswGen <project>, where <project> is the path and name of theproject you wish to generate code for, and then press <ENTER>. You will see text similar to thefollowing output appear on screen, together with any messages written to the BSW log duringexecution.



5. Wait until the message RTA-BSW CodeGen commandline execution is completed is displayed.This indicates the end of the CodeGen process.

6. Close the command window. You will find the generated files either in the output folder specifiedin the launch configuration, or the default output path {ProjectPath}/src/BSW/Gen if no other pathwas specified.

4.7 Handling Validation Errors Thrown By CodeGen

If the Configuration of the BSW Project, used as the input to CodeGen, contains invalid configuration ormismatches to the AUTOSAR specification Validation Errors will be thrown. The first notification of anerror the user will see is the CodeGen Build Error Dialog, shown below.

Fig. 4.2: CodeGen Build Error Dialog.

After the dialog has been dismissed details about the errors can be found in the Problems Log win-dow. Each error displayed will contain a description about the issue and in many cases the name ofthe file or parameter that caused the error. In the example error below the parameter can be seen as“EcuMMainFunctionPeriod” and more detail for its location is given as “under ‘EcuMGeneral’”

Fig. 4.3: Error Seen In The Problems Log.

Many errors contain detailed descriptions that cannot be entirely shown in the limited space of the prob-lems log. However hovering over an error will bring up the tooltip which contains a complete description.

Fig. 4.4: Error Details Tooltip.



4.7.1 CLI Error Messages

If you are using the Windows CLI to run CodeGen, you may encounter the following errors:

RTA-BSW install verification failed. Please ensure RTA-BSW is installed properly and try again.

There is an error in the installation. This could be caused if manual changes are made to the BSWinstallation manually, or by installing BSW manually into an incompatible version of ISOLAR (such asISOLAR-A without ISOLAR-B).

Specified project "C:\ETASData\ISOLAR-AB\workspace\<project_name>" does not exist.

The specified project path/name does not exist.

!ENTRY com.bosch.autosartool.rtabsw.application 4 0 2019-02-14 12:16:47.499!MESSAGE Problems occurred when invoking code from plug-in "com.bosch.autosartool.rtabsw.→˓application": IO error while attempting to import project.

The specified path is not a valid project, or you do not have permission to access the specified project.

!ENTRY com.bosch.autosartool.rtabsw.application 4 0 2019-02-14 12:12:21.459!MESSAGE Problems occurred when invoking code from plug-in "com.bosch.autosartool.rtabsw.→˓application": The target project does not contain a launch configuration.Please configure the project first using the RTA-BSW GUI.

A launch configuration for the target project is required. You must use the RTA-BSW GUI to create a launchconfiguration for the project before running CodeGen.

!ENTRY com.bosch.autosartool.rtabsw.application 4 0 2019-02-14 12:20:26.816!MESSAGE Problems occurred when invoking code from plug-in "com.bosch.autosartool.rtabsw.→˓application": The target project launch config is invalid. Please configure the project first→˓using the RTA-BSW GUI.

The project’s launch configuration is invalid. Typically this means the launch config is from an olderversion of BSW, or that one or more of the launch configuration parameters is invalid. This can be fixedby opening the launch configuration and checking that all the settings are current, and that the RTA-BSWfield is set to the correct version.


ETAS Limitations

5 Limitations

Summary Reference (REFERENCE-VALUES in the configuration arxml files) overrides are not sup-ported.

Impact User cannot use algo.properties file to configure the references.

Workaround Manually configure any required reference values after configuration generation com-pletes.

Summary If the System Template is splitted across multiple arxml files, then the configurationgeneration script will not generate the necessary configurations for all required RTEcallbacks.

Impact This can result in the generated code not functioning as expected. One common impactis that no RX Com signal can be received at runtime.

Workaround Ensure that the System Template is specified in a single arxml file.

Summary If the old CodeGen Launch Configuration of deleted project is still present and otherprojects are imported, the “Project” field will be updated to the first opening project,alphabetically sorted.

Impact This can lead to further confusions for the user.

Workaround Remove the faulty, obsolete CodeGen Launch Configuration manually when a projectis deleted from workspace or renamed.

Summary When importing/migrating a project between AR versions, EcucValues can exist that donot correspond to current RTA-BSW’s paramdef. These issues are not detected beforecausing errors in CodeGen..

Impact User may not realise that their project contains invalid EcucValues that (correctly) resultin failure of CodeGen.

Workaround Ensure that all EcucValues are associated with current RTA-BSW’s Paramdefs. Normally,when migrating a project between AR versions/RTA-BSW versions, the manually con-figured modules (Ex: BswM, EcuM, Crc,. . . ), which is not generated by ConfigurationGeneration, need to be checked and configured again to adapt to the new Paramdefs.

Summary For SPC58NE target, as mentioned in AUTOSAR_MCAL_CAN_UM.pdf, “CanFilterMask”and “CanFilterMaskRef” are meaningless. However, these parameters are needed forAutomatic configuration of BASIC mailboxes.

Impact Automatic configuration of BASIC mailboxes on SPC58NE is not supported.

Workaround Configure the RX FIFOs manually.

Summary Parameter type changes, which may occur when a new version of RTA-BSW is installed,can result in misleading CodeGen errors stating that multiplicity < 1.

Impact Correcting the multiplicity error displayed will cause a subsequent CodeGen invocationto fail with a parameter type mismatch error.

Workaround The parameter type and value in ISOLAR-AB should be set appropriately, according tothe information shown in the Description View.


ETAS Limitations

Summary RTA-BSW does not show the complete configuration on ISOLAR-B.

Impact Some EcucValues are created automatically during CodeGen. As a result, the Ecu con-figurations can appear to be incomplete according to ISOLAR-B despite being sufficientfor RTA-BSW.

Workaround No workaround.

Summary E2EXF Module is missing required dependencies

Impact Generating the E2EXF module will not produce all the code required to use E2EXF ser-vices due to dependencies on BSW modules that are not currently included in RTA-BSW.

Workaround No workaround


ETAS Integration Hints

6 Integration Hints

Summary The ConfGen and CodeGen buttons will be disabled if a project is not selected.

Hint The ConfGen and CodeGen buttons will only be enabled if there is an open project se-lected in the Autosar Explorer view, otherwise they will be disabled.


ETAS Integration Advice

7 Integration Advice

Warning: All integration files are only examples and it is user’s responsibility to modify ap-propriately.

This section contains integration advice that is generally applicable across all modules.

7.1 SchM Enter and Exit API

Some RTA-BSW modules use the macro SCHM_ENTER_DEFAULT() and SCHM_EXIT_DEFAULT() in theirsource code to suspend and resume interrupts. In the integration folder, RTA-BSW provides anintegration file SchM_Default.h. This file should be used to provide the implementation of theSCHM_ENTER_DEFAULT() and SCHM_EXIT_DEFAULT() macros using the interrupt functions provided bythe OS.

By default with using RTA-OS:

RTA-OS generates function SuspendAllInterrupts() and ResumeAllInterrupts(). These functions areused in BSW and RTE to trigger OS to suspend and resume all interrupts while executing critical code.

7.2 Configuration MemMaps

Memory mapping is supported by RTA-BSW modules. However, for specific hardware and compilersthe user may need to modify the file Bsw_MemMap.h. For more details please refer to the AutosarSpecification for Memory Mapping.

7.3 Callback functions

Some RTA-BSW modules provide template functions (they may simply be stub functions) that are requiredto integrate the BSW modules with the rest of the System. The user is responsible for implementing theseintegration functions appropriately.


ETAS Migration

8 Migration

When migrating a project to a newer version of RTA-BSW, the following points need to be considered:

8.1 ConfGen

∙ ParamDefs updating: Execute ConfGen to get the new ParamDefs.

∙ Config/BSW/

∙ EcucValues/:

∙ Make a backup of *_EcucValues.arxml files that are not generated by ConfGen or CodeGen.If the relevant ParamDefs in the new version are changed, the corresponding EcucValuesmust be modified to conform to the new ParamDefs. In some cases this will involved such asrenaming, restructuring or removing the parameters/containers.

∙ *_EcucValues.arxml files that are generated by ConfGen or CodeGen should be deleted asthese will be regenerated by the relevant tools.

∙ ParamDefs/: Some ParamDefs will be added, replaced or removed. Therefore, this folder shouldbe removed before ConfGen.

∙ ConfGen_version.h will be regenerated during ConfGen.

∙ Project_EcucValues.arxml will be regenerated during ConfGen. If specific manual changes havebeen made to this file then backup the file and transfer the manual changes to the one generatedby new version of RTA-BSW.

∙ CanEcucValues.arxml will be regenerated during ConfGen. If specific manual changes have beenmade to this file then backup the file and transfer the manual changes to the one generated bynew version of RTA-BSW.

∙ Tools/

∙ ide_properties.txt to be removed.

∙ Settings/

∙ algo.properties should be marked as Old as it could be out of date due to the following:

∙ The rules of algo.properties configuration (see BSW Configuration Generation) should bechecked for modifications to the keywords. If there are any changes, the algo.propertiesmust be updated according to new keywords.

∙ The configuration of new parameters may need to be added.

∙ The configuration of removed/renamed parameters need to be removed/renamed.

8.2 CodeGen

∙ Config/BSW/

∙ SWCD/: This folder should be removed before CodeGen because all files will be regenerated byCodeGen.

∙ BSWMD/: This folder should be removed before CodeGen because all files will be regenerated byCodeGen.

∙ *_Model_Export.arxml: These files should be removed as their content has been moved to/_fwd/ecuc_configuration_values_fwd.arxml.


ETAS Migration

∙ Platform_types files: Generated during CodeGen, if it is necessary to modify these files for spe-cific purposes of projects, then they must be stored and reused after CodeGen.

∙ Other files which are generated by ConfGen and CodeGe should be removed.

∙ src/BSW/Gen/

∙ Module Folders and integration folder: Integration files should be backed up outside of the srcfolder. This backup will be used to compare with the new integration files generated by rerunningCodeGen.

∙ Remove the src/BSW/Gen folder or equivalent output folder.


ETAS Diagnostic Workflow

9 Diagnostic Workflow

9.1 Importing ODX Files as DEXT

The AUTOSAR DEXT (Diagnostic Extract Template) specification describes a protocol for configuring BSWmodules for diagnostic operations. DEXT describes the format of the diagnostic data, and its origin inthe ECU’s application software. This differs from the widely used ODX (Open Diagnostic Data Exchange)standard, an XML-based format which performs a similar role but does not specify the data’s origin.

ISOLAR-AB supports import of ODX formatted data and conversion to DEXT via the ODX Importer incombination with the ODX to DEXT add-on. The RTA-BSW ConfGen tool can generate configuration infor-mation for the Diagnostic Event Manager (Dem) and Diagnostic Communication Manager (Dcm) modulesfrom a valid DEXT file. However, some manual configuration will be required to supply configurationparameter values that cannot be automatically generated.

9.1.1 Supported Services

The following diagnostic services are supported for conversion from ODX to DEXT, and subsequent gen-eration of configuration parameter values in ConfGen. For each service found in the ODX file, a DEXTservice instance will be created under the relevant DEXT service class as listed below.

Service Name ID DEXT Service Instance DEXT Service Class

SessionControl 0x10 DiagnosticSessionControl DiagnosticSessionControlClass

ReadDataByIdentifier 0x22 DiagnosticReadDataByIdenti-fier

DiagnosticReadDataByIdentifier-Class

WriteDataByIdentifier 0x2E DiagnosticWriteDataByIdenti-fier

DiagnosticWriteDataByIdentifier-Class

InputOutputControl-ByIdentifier

0x2F DiagnosticIOControl DiagnosticIOControlClass

ClearDiagnosticInfor-mation

0x14 DiagnosticClearDiagnosticIn-formation

DiagnosticClearDiagnosticInfor-mationClass

ReadDTCInformation 0x19 DiagnosticReadDTCInforma-tion

DiagnosticReadDTCInformation-Class

SecurityAccess 0x27 DiagnosticSecurityAccess DiagnosticSecurityAccessClass

CommunicationControl 0x28 DiagnosticComControl DiagnosticComControlClass

ReadDataByPeriodicI-dentifier

0x2A DiagnosticReadDataByPeriodi-cID

DiagnosticReadDataByPeriodicID-Class

DynamicallyDefine-DataIdentifier

0x2C DiagnosticDynamicallyDefine-DataIdentifier

DiagnosticDynamicallyDefine-DataIdentifierClass

RoutineControl 0x31 DiagnosticRoutineControl DiagnosticRoutineControlClass

9.1.2 Prerequisites

This procedure assumes that you are already running the RTA-BSW plugin in ISOLAR-AB and have loadeda project into the workspace which conforms to the RTA-BSW requirements described in the RTA-BSWGetting Started Guide [7].

9.1.3 Importing an ODX File

1. Launch the ODX Importer from the toolbar by clicking the ODX Importer button.



2. In the ‘ODX Importer Wizard’ dialog, click Browse, select the ODX file you wish to import (the fileshould have the type extension .odx-d), and then click Next.

3. In the ‘Select Services’ dialog, place a check mark next to each service you wish to import data for(all are selected by default) and then click Finish.

Note: The remaining steps in this procedure describe how to import a DBC file containingthe communication matrix information into the System Template. IF you wish to configure asystem manually, you can omit the remaining steps in this procedure.



4. Click the toolbar button shown below to launch the DBC importer.

5. In the ‘Select File’ dialog, click the Browse button (1) in the DBC pane and use the file selectorto specify the name and location of the DBC file to import. The Network pane (2) will display thenetwork name and type, populated from the DBC file contents.

6. Click the Browse button (3) in the ARPackage Name pane, use the ‘New AR Package’ dialog to selectthe .arxml file already created during the ODX import in steps 1-3 and then click OK.



7. In the ‘Select File’ dialog, click Next.

8. In the ‘Select ECUs’ dialog, select the target ECU instance you wish to include in the System Tem-plate and then click Next.

9. In the ‘Select Frames’ dialog, select the frames you wish to be included in the System Template andthen click Finish.



10. Wait until the confirmation dialog indicating the DBC import is complete appears, and then clickOK.

11. In ‘AR Explorer’, select the DiagnosticContributionSet element as shown below, and then use thedelete control (1) in the ‘Properties’ dialog to remove EcuInstance_DEXT from the ‘ECUInstances’list box.

12. Use the add control (2) to add the required target EcuInstance to the ‘ECUInstances’ list box.



13. Select the DiagnosticServiceTable element as shown below, and then use the drop-down menuto change the EcuInstance property to the required target EcuInstance.

14. In ‘AR Explorer’, right-click on the EcuInstance_DEXT element and then select Delete from thepop-up menu.



This completes the import process. You may now run the Confgen tool (see see BSW ConfigurationGeneration), which will create a set of configuration parameters for the diagnostic modules based on theimported DEXT data. The values assigned to some of these parameters will be based on default values,while others must be configured manually. These parameters are listed in the Additional Configurationsection below.

9.2 Additional Configuration

9.2.1 Default Configuration

The following parameters are assigned default values during the Confgen process. The assigned defaultscan be modified by editing the project’s algo.properties file. Note that some defaults depend on otherconfigurations, and may need to be manually added if the dependent conditions are not present in thetarget project.

Parameter Default Value

Dem/DemGeneral/DemGeneralInterfaceSupport FALSE

Dem/DemGeneral/DemDataElementClass/DemExternalCS-DataElementClass/DemDataElementUsePort

TRUE

Dem/DemConfigSet/DemEventParameter/DemEventAvailable TRUE

Dem/DemGeneral/DemRbGeneral/DemRbSupportSuspicious FALSE

Dem/DemGeneral/DemRbGeneral/DemRbDebugData OFF

Dem/DemGeneral/DemRbGeneral/DemRbDebugDataBefor-eInit

FALSE

Dem/DemGeneral/DemAvailabilitySupport DEM_NO_AVAILABILITY

Dem/DemGeneral/DemClearDTCBehavior DEM_CLRRESP_NONVOLATILE_FINISH

Dem/DemGeneral/DemDevErrorDetect FALSE

Dem/DemGeneral/DemEventCombinationSupport DEM_EVCOMB_DISABLED

Dem/DemGeneral/DemMaxNumberEventEntryPermanent 0

Continued on next page



Table 9.1 – continued from previous page


Dem/DemGeneral/DemMaxNumberPrestoredFF 5

Dem/DemGeneral/DemSuppressionSupport DEM_NO_SUPRESSION

Dem/DemGeneral/DemTaskTime 0.01

Dem/DemGeneral/DemTriggerDcmReports FALSE

Dem/DemGeneral/DemTriggerDltReports FALSE

Dem/DemGeneral/DemTriggerFiMReports FALSE

Dem/DemGeneral/DemTriggerMonitorInitBeforeClearOk FALSE

Dem/DemGeneral/DemVersionInfoApi FALSE

Dcm/DcmConfigSet/DcmDsd/DcmDsdRequestManufactur-erNotificationEnabled

FALSE

Dcm/DcmConfigSet/DcmDsd/DcmDsdRequestSupplierNotifi-cationEnabled

FALSE

Dcm/DcmConfigSet/DcmDsl/DcmDslBuffer/DcmDslBufferSize 255

Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocol-Row/DcmTimStrP2ServerAdjust

0.01

Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocol-Row/DcmTimStrP2StarServerAdjust

0.01

Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocol-Row/DcmDslProtocolPriority

0

Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocol-Row/DcmSendRespPendOnTransToBoot

TRUE

Dcm/DcmConfigSet/DcmPageBufferCf/DcmPagedBufferEn-abled

FALSE

Dcm/DcmGeneral/DcmDevErrorDetect FALSE

Dcm/DcmGeneral/DcmTaskTime 0.01

Dcm/DcmGeneral/DcmVersionInfoApi FALSE

Dcm/DcmGeneral/DcmRbGeneral/DcmRbConfirmForDSDGen-eratedNegRes

FALSE

Dcm/DcmGeneral/DcmRbGeneral/DcmRbOSTimerUse CyclicCount

Dcm/DcmGeneral/DcmRbGeneral/DcmRbRTEsupport TRUE

Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUse-Port

USE_DATA_SENDER_RECEIVER(except when DcmDspDataTypeis UINT8_DYN then default isUSE_DATA_SYNCH_FNC)

Dcm/DcmConfigSet/DcmDsp/DcmDspDidInfo/DcmDspDidCon-trol/DcmDspDidControlMask

DCM_CONTROLMASK_NO

DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmDspSecu-rityDelayTimeOnBoot

10

DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmDspSecu-rityUsePort

USE_ASYNCH_CLIENT_SERVER

Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmDspSecuri-tyRow/DcmDspSecurityAttemptCounterEnabled

FALSE

Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmDspSecuri-tyRow/DcmRbDspSecurityNumAttLock

0

Continued on next page



Table 9.1 – continued from previous page


Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmRbDspSe-curityStoreSeed

FALSE

DcmDsp/DcmDspRoutine/DcmDspRoutineUsePort TRUE

Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocol-Row/DcmDslProtocolMaximumResponseSize

255

DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslCon-nection/DcmDslMainConnection/DcmDslProtocolRxTester-SourceAddr

0

DcmDsp/DcmRbDspSesSecUsedInProtocol UDS

Dcm/DcmConfigSet/DcmDsp/DcmRbDspReadDTC/DcmRbD-spReadDTCMaxNumDTCRead

1

Dcm/DcmConfigSet/DcmDsp/DcmRbDspReadDTC/DcmRbD-spReadDTCMaxNumRecordRead

1

9.2.2 Manual Configuration

The following parameters must be manually configured in the ISOLAR-AB application after running theConfgen tool.

∙ Dem/DemGeneral/DemNvRamBlockId

∙ Dem/DemInternalDataElementClass/DemDataElementDataSize

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslMain-Connection/DcmDslProtocolComMChannelRef

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslMain-Connection/DcmDslProtocolRx

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslMain-Connection/DcmDslProtocolTx

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslPeriod-icTransmission

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslRe-sponseOnEvent


ETAS ETAS Contact Addresses

10 ETAS Contact Addresses

10.1 ETAS HQ

ETAS GmbHBorsigstraße 2470469 StuttgartGermany

Phone: +49 711 3423-0

Fax: +49 711 3423-2106

WWW: www.etas.com

10.2 ETAS Subsidiaries and Technical Support

For details of your local sales office as well as your local technical support team and product hotlines,take a look at the ETAS website:

ETAS subsidiaries WWW: www.etas.com/en/contact.php

ETAS technical support WWW: www.etas.com/en/hotlines.php

10.2.1 RTA Hotline

The RTA hotline is available to all RTA users with a valid support contract.

∙ [email protected]

∙ +44 (0)1904 562624. (0900-1730 GMT/BST)

Please provide support with the following information:

∙ Your support contract number.

∙ Your AUTOSAR XML and/or OS configuration files.

∙ Reproduction steps that result in an error message.

∙ The version of the ETAS tools you are using.


mailto:[email protected]

Documents

RTA-BSW User Guide V3.2 - ETAS · specialized rules such as multiplicity constraints. An ARXML ﬁle is deﬁned using an AU- ... 1.AUTOSAR Motivation and Goals 2.RTA-RTE User Guide