ETAS RTA-BSW User Guide

RTA-BSW v3.2.0

RTA-BSW User Guide

Status: 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 it can only be used if the customer is in possession of a general license agreement or single license. Using and 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 a retrieval system or translated into another language without the express written permission of ETAS

GmbH.

©Copyright 2019 ETAS GmbH, Stuttgart

The names and designations used in this document are trademarks or brands belonging to the respective 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

1.1

Applicable Versions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2

1.3

Safety Notice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Definitions and Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4

1.5

Bibliography

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Conventions

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 How to use this User Guide

5

3 AUTOSAR

3.1

Motivation

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2

3.3

3.4

3.5

Architecture

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

6

6

Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Multi-core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

15

2

2

2

2

4

4

4 RTA-BSW Architecture and Workflow

4.1

4.2

Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Integration with ISOLAR-AB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

17

17

4.3

4.4

4.5

4.6

4.7

Activities and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Creating a System Template and Software Component Template . . . . . . . . . . . .

BSW Configuration Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

BSW Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Handling Validation Errors Thrown By CodeGen . . . . . . . . . . . . . . . . . . . . . .

17

18

18

21

24

5 Limitations

6 Integration Hints

26

28

7 Integration Advice

7.1

SchM Enter and Exit API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

29

7.2

7.3

Configuration MemMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Callback functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

29

8 Migration

8.1

30

ConfGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

8.2

CodeGen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

9 Diagnostic Workflow

9.1

Importing ODX Files as DEXT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

32

9.2

Additional Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

10 ETAS Contact Addresses

10.1

ETAS HQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

41

10.2

ETAS Subsidiaries and Technical Support

. . . . . . . . . . . . . . . . . . . . . . . . .

41


1

1.1

1.2

ETAS Introduction

Introduction

The RTA-BSW User Guide describes how to work with the RTA-BSW product on electronic control units. The guide also includes generic description of AUTOSAR BSW and the interactions between the components that 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.

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 the configuration aspects described in this User Guide are also applicable to later versions of the software.

Safety Notice

Warning: Any configuration(s) described in this User Guide are provided as an example only and 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 communicating SWCs including service, application and complex device driver SWCs.


ETAS

BSW AUTOSAR Basic Software modules. AUTOSAR defines a comprehensive BSW architecture consisting of service, interface and driver BSW modules that provide a device independent ECU abstraction to ASW and thus promote SWC reuse and relocation. See

Section 4 for a list of AUTOSAR BSW modules.

BSW Stack A slice through the AUTOSAR Layered SW Architecture that comprises functionally related BSW modules from the Service, ECU Abstraction and Microcontroller Abstraction 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 is standardized – ports – and therefore accessible to ASW using the RTE. However, the functionality provided by the CDD, for example how it accesses hardware, is implementation specific.

DTC Diagnostic Trouble Code.

ECU Electronic Control Unit. In the context of AUTOSAR, an ECU comprises one microcontroller/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 a single housing contains multiple microcontrollers each requires its own AUTOSAR configuration 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 communication.

EEPROM Electronically Erasable Programmable Read-only Memory.

I-PDU Interaction Layer PDU.

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

OsApplications.

MCAL Microcontroller Abstraction Layer – the lowest software layer of the Basic Software within the AUTOSAR SW architecture. The MCAL contains internal drivers (BSW with direct access to the microcontroller and its internal peripherals) and serves to make higher layers independent of the microcontroller.

OSEK Offene Systeme und deren Schnittstellen für die Elektronik im Kraftfahrzeug (Open

Systems and their Interfaces for the Electronics in Motor Vehicles). OSEK include the specification of OSEK-OS and OSEK-COM which were used as the basis for the AUTOSAR

Os 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 generated API.

Schema A XML file that describes the permitted structure and content type of another XML file including data types, available elements and their permitted order as well as more specialized 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-

Introduction


ETAS Introduction

1.4

1.5

ture and widely used in automotive embedded systems.

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

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

UDS Unified Diagnostic Services – Standardized set of diagnostic services defined by

ISO—15765 and supported by the AUTOSAR Dcm module.

VFB AUTOSAR Virtual Function Bus. The VFB is an abstract composition of the ASW including all SWCs in the system their connections but not the mapping to particular ECUs. The

VFB enables integration of ASW to occur early in the development phase and permits verification of the consistency of the communication relationship between SWCs.

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

Conventions

OCI_CANTxMessage msg0

Choose File->Open .

Press <ENTER>.

The ‘Open File’ dialog box is displayed.

Select the file setup.exe

Code snippets are shown in a monospaced Courier typeface.

Menu commands and buttons are shown in boldface.

Keyboard commands and variable text items are shown in angled brackets.

Names of program windows, dialog boxes, fields, etc.

are shown in quotation marks.

Path and file names, new terms and general emphasis are shown in italics.


2

ETAS How to use this User Guide

How to use this User Guide

The RTA-BSW User Guide describes how to work with RTA-BSW within a development process for

AUTOSAR-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. This includes:

∙ 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

3.1

3.2

3.2.1

AUTOSAR

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

Motivation

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

∙ 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 – with an emphasis on configuration – that permits the integration of solutions from multiple suppliers using well-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 and re-locatability.

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

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

Architecture

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

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

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

∙ Limited Computational Resources – the microcontrollers used have limited resources – both computing 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 provide a mechanism to control that complexity while retaining the properties above.

AUTOSAR Layered SW Architecture

The AUTOSAR Layered SW Architecture is the key to how AUTOSAR provides a mechanism to manage the complexity of automotive software. The AUTOSAR architecture structures ECU software as a hierarchy of application software (ASW, consisting of multiple SWCs) and basic software (BSW) modules. Within the architecture description, AUTOSAR defines a mapping of the ASW/BSW to architectural layers, the responsibilities 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 encapsulates and abstracts the functionality and behaviour of the layer below:

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

AUTOSAR Run-Time Environment (RTE) The RTE provides communication and scheduling services to application software. The purpose of the RTE is to make application software independent of a mapping to a specific ECU. This permits SWCs to be reused or relocated to 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 of their location (microcontroller internal/external) and their connection to the microcontroller (port pins, type of interface). The ECU Abstraction provides an interface to the

Services Layer that is both microcontroller and ECU independent.

Microcontroller Abstraction Layer (MCAL) The lowest software layer of the AUTOSAR Basic Software containing drivers for internal devices, such as Fls and Eep, and memorymapped 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 the

Microcontroller Abstraction Layer

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


ETAS AUTOSAR

3.2.2

∙ The Service Layer offers abstracted services to both ASW (through the Run-time Environment) and other BSW modules. The facilities offered by the abstracted services are available on any AUTOSAR

ECU promoting the portability and re-use of ASW.

∙ The ECU Abstraction Layer provides an AUTOSAR defined abstraction layer between the microcontroller 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 of the individual ECU hardware.

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

BSW Module Classification

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

Interface BSW module providing a functional abstraction of the associated Driver module through the provision of a generic API that is independent of the characteristics of the device. 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/or asynchronous access by multiple clients. A Handler will typically perform buffering and arbitration. Since it is a form of Interface, it does not change data. AUTOSAR includes few specific Handler modules since the functionality is usually combined within an Interface or Driver module.

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

Driver BSW module that controls a specific HW device. A driver can control either internal or external devices. Drivers for internal devices and memory-mapped external devices are in located in the Microcontroller Abstraction Layer since they access the microcontroller directly. 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 direct interface to microcontroller hardware as well as providing an AUTOSAR interface for access by ASW. The functionality of a CDD is not standardized by AUTOSAR however, the upper interface is configured using ports and therefore accessible by ASW through the

RTE.

Note: Use of a CDD by ASW implies a dependency on specific hardware capabilities of the

ECU 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. A library 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 bit handling, 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 from the Service, ECU Abstraction and Microcontroller Abstraction layers. At a high-level, the functionality offered by the layers within the AUTOSAR Architecture is described by the functional blocks as shown in the figure below: The functional blocks form the basis for the BSW stacks that collectively comprise

RTA-BSW.

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

3.2.4

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

Guide:

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.

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 Dem module 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, horizontal interactions are not allowed between modules in the Microcontroller Abstraction Layer. AUTOSAR makes an exception for complex drivers; these are permitted to use horizontal interfaces to any BSW module. A “vertical” interaction occurs when one SW Layer accesses interfaces of the SW layer above or below. Single vertical interactions, e.g. from Service Layer to ECU Abstraction Layer, are clearly permitted since they define the interfaces that connect stacks together. In addition, a BSW module may access a lower layer module of another layer group, e.g. SPI for external hardware. The bypassing of one software layer – i.e. a vertical interaction that skips a layer – should be avoided and is discouraged within AUTOSAR and not used by the standardized BSW. AUTOSAR does not permit the bypassing of two or more software layers. To avoid dependencies on hardware, AUTOSAR does not permit the bypassing of the MCAL by modules within the Service and ECU Abstraction Layers. Finally, any BSW module in any layer may interact with system services. This exception is important for services provided by the Operating Systems since it means that a single mechanism for data consistency and scheduling can be applied to the BSW.


ETAS AUTOSAR

Fig. 3.4: AUTOSAR Layered SW Architecture Interaction Matrix

This 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.

3.3

A Complex Device Driver (CDD) has unique characteristics in the AUTOSAR architecture. It provides a standardized mechanism for accessing non-standard microcontroller hardware directly and providing an

AUTOSAR interface accessible by ASW through the RTE. Due to its position within the layered architecture it 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 the names of call-back routines).

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

CDD may occur.

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

Methodology

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


ETAS AUTOSAR

Fig. 3.5: AUTOSAR Methodology

3.3.1

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

System Design

The System Design phase defines the abstract application architecture, network topology and mapping of 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 integration of 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, what buses 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 more

ARXML files. The System Description describes the entire vehicle architecture and can therefore grow to a significant size. Since it contains all information about the vehicle (some of which will be proprietary) it may 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 a

System Extract (containing information pertaining to one functional sub-system) or an ECU Extract (containing information for a single ECU) from the complete system description. This allows relevant system information 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

3.3.3

3.3.4

ECU Configuration

An ECU Extract of the System Description contains sufficient information for configuration/generation of the BSW modules and the RTE for a single ECU. For example, the ECU Configuration (ECUC) Value

Collection for an ECU Extract will define the signals (frames) that are sent/received by that ECU and no others. The ECU extract is derived from the System Description by removing elements of other ECUs – this process is automated by ISOLAR-AB.

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 default

ECU Configuration from a System Description, System Extract or Ecu Extract.

RTA-BSW CodeGen The CodeGen tool provides a suite of Code Generators that produce the embedded 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 default

ECU Configuration produced by ConfGen before invoking the CodeGen tool to generate the BSW embedded code.

Application Development

The ASW Development process is largely independent of System Design. The latter requires only a limited set of information about each SWC, e.g. the ports used to communicate, and therefore ASW development can proceed in parallel with System Design. The AUTOSAR methodology thus permits the independent implementation and testing of SWCs. By separating the implementation and test of different

SWCs AUTOSAR promotes re-use of the SWC within a new ECU and simplifies integration by the OEM.


ETAS AUTOSAR

3.4

3.4.1

3.4.2

Interfaces

The AUTOSAR Interfaces defines when and how participants within the AUTOSAR Methodology, such as

OEM and supplier, exchange information.

Data Exchange Formats

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

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

BSW Module Description ARXML describing the interfaces, dynamic behavior and resource requirements of a BSW module. The syntax and semantics of the BSW Module Description are described by the AUTOSAR BSW Module Description Template and is typically created by the BSW generation process for BSW modules that present an AUTOSAR interface to the RTE.

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

ECU Extract ARXML description for an ECU provided by the OEM to the ECU supplier. The

ECU Extract, in conjunction with the ECUC Description, permits configuration and generation of the BSW and RTE for the ECU. The AUTOSAR System Template defines the syntax and semantics of an ECU Extract (this is the same AUTOSAR configuration syntax used for the System Description).

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

The system of containers and parameters that form the ECUC Description is defined by an AUTOSARsupplied ECU Configuration Parameter Definition file. This ARXML file defines the available containers and parameters for every standardized BSW module. The approach is both flexible and extensible – vendor specific parameters can also be modelled through additional ARXML description file that describes how and when the parameters should be defined. All AUTOSAR data exchange formats use XML consistent with a schema defined by AUTOSAR. Since both supplier and OEM use the same schema, a common interpretation of the exchange is possible. The AUTOSAR schema is updated with each release of AU-

TOSAR to reflect new and modified features.

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 SWC implementer 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 Software

Component Template defines the syntax. The respective AUTOSAR specification defines the interface semantics, 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 Standardized

Interface 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 since

AUTOSAR defines only the syntax of data exchange format, the Software Component Template. The user defines 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 microcontroller 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 parameter

EcucPartitionBswModule-Execution to true .

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

The Os module (RTA-OS) supports multi-core applications and the EcuM module can be configured to start the OS on each applicable core. The RTE (RTA-RTE) supports multi-core applications with elements of the ASW mapped to multiple ECU partitions. The RTE uses the OS’s IOC API for communication between

SWCs in different partitions and this mechanism does not support access to BSW which uses a C function based 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 or

Com 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, then a 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 generated inter-partition communication to SWC Proxy in the same partition as the BSW.

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


4

4.1

ETAS

4.2

4.3

RTA-BSW Architecture and Workflow

RTA-BSW Architecture and Workflow

Installation

RTA-BSW is provided as a plug-in to ISOLAR-AB; please consult the separate RTA-BSW Installation and

Getting 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]

Getting Started Guide [7] documents for installation instructions for these modules.

and RTE

Integration with ISOLAR-AB

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

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

∙ CodeGen – an AUTOSAR BSW code generation tool, consuming configuration in EcucValueDescription format 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 on

using these two tools focusing on the different options that they present.

Activities and Outputs

RTA-BSW Activities and Outputs

illustrates the activities and generated outputs present in the intended workflow 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 Authoring

Tool, 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 compositions, using the AUTOSAR Software Component Template ARXML to define the VFB Configuration.

3. RTA-BSW ConfGen uses the System Description and ASW Configuration(s) to create a default BSW

Configuration 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 modules that present an AUTOSAR interface to the RTE, one or more BSWMD files for inclusion with the

RTE generator’s configuration.


ETAS RTA-BSW Architecture and Workflow

Fig. 4.1: RTA-BSW Activities and Outputs

4.4

4.4.1

Creating a System Template and Software Component Template

As shown in Figure 10, RTA-BSW operates on an AUTOSAR System Template and upon Software Component Templates to generate the BSW Configuration. The ISOLAR-A Getting Started Guide

[5] describes how both types of template are prepared. The RTA-RTE Getting Started Guide [7] also provides configuration advice, for example data mappings for complex data types. The use of legacy file imports provides a route to quickly populating the system template with some information that ConfGen can use to generate

BSW configuration automatically.

Legacy File Import

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

4.5

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 System

Template in ISOLAR-AB”) of the ISOLAR-AB Getting Started Guide

[5]

.

BSW Configuration Generation

The RTA-BSW ConfGen tool generates BSW configuration information using data from the System Template 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. the

SWCs, their mapping to ECUs, network information including mapping data communicated by

SWCs to network signals) To make full use of this tool it is recommended that the complete

Virtual 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.

4.5.1

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

BSW.

Repeating Configuration Generation

If a BSW configuration already exists, then BSW Import ( button) deletes the following files before recreating 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

and

Can_EcucValues.arxml

files. As a result, the process will also delete any changes made by the user that are contained within these files.

The AUTOSAR splitable mechanism provides a means to ensure that additions to the default configurations are not lost when regenerating the configuration. To exploit the splitable mechanism, define additional Ecuc parameters and reference values in separate ARXML files using the same ARPackage and

EcucContainer 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



4.5.2

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

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 default value 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 configured 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 supported 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 commaseparated 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 reversed.



Can Controller Mailbox Assignment

The number of mailboxes assigned to a Can Controller may be configured in the algo.properties

file using the following rule:

NumberofMB_{SHORT NAME} = {max_mailboxes}

4.6

4.6.1

{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 be assigned to a controller.

One mailbox will be assigned for each frame if possible. Should there be more frames than the mailbox limit 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 combined into one Mailbox, all Tx messages with a period less than property PduTimingLimit will get a dedicated Mailbox.

2. If either the remaining number of Standard or Extended messages are smaller than half the remaining 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 the

Standard Mailboxes are packed into half the remaining Mailboxes and the Extended in the remaining half.

BSW Code Generation

The RTA-BSW Code Generation tool ‘CodeGen’ generates source code and header files ( .c/.h

) for the currently selected project. You can run the CodeGen tool either from within ISOLAR-AB, or outside the application using the Windows CLI (Command Line Interface).

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

If you do not specifically create a launch configuration, a default launch configuration will be created when the CodeGen process is started. In this case, module selection will be based on the BSW configuration you created with the ConfGen tool (see

BSW Configuration Generation ) and the version(s) of

RTA-BSW selected in the project. The output path will default to {ProjectPath}/src/BSW/Gen .

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 and then 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 is selected.

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

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

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

∙ Generate C/H Select this option to output the dynamically generated .c/.h

source files for the selected modules.

∙ Generate ARXML Select this option to output the dynamically generated *.arxml

configuration files for the selected modules.



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


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


∙ Delete Existing Output Folder Select this option to delete any previously generated code before generating 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.

4.6.2

Code generation will now take place, using either the launch configuration you specified previously, or the default launch configuration if you skipped steps 1 through 4. Note that the default launch configuration will 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 the

RTA-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 to another during code generation) are available in _fwd/ecuc_configuration_values_fwd.arxml

and should not be modified. These configuration values will be regenerated and used during code generation.

Running CodeGen from the Command Line

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

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

Note: Adding the ISOLAR-AB installation folder path to your Windows environmental variable

PATH 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 from

ISOLAR-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:Program

FilesETASISOLAR-ABx.x

).

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

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



4.7

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 specified in the launch configuration, or the default output path {ProjectPath}/src/BSW/Gen if no other path was specified.

Handling Validation Errors Thrown By CodeGen

If the Configuration of the BSW Project, used as the input to CodeGen, contains invalid configuration or mismatches to the AUTOSAR specification Validation Errors will be thrown. The first notification of an error 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 window. Each error displayed will contain a description about the issue and in many cases the name of the 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 problems log. However hovering over an error will bring up the tooltip which contains a complete description.

RTA-BSW v3.2.0 RTA-BSW User Guide

Fig. 4.4: Error Details Tooltip.

24


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 BSW installation manually, or by installing BSW manually into an incompatible version of ISOLAR (such as

ISOLAR-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.



˓ → 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 launch configuration for the project before running CodeGen.



˓ → 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 older version of BSW, or that one or more of the launch configuration parameters is invalid. This can be fixed by opening the launch configuration and checking that all the settings are current, and that the RTA-BSW field is set to the correct version.


5

ETAS

Limitations

Limitations

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

User cannot use algo.properties

file to configure the references.

Impact

Workaround Manually configure any required reference values after configuration generation completes.

Summary If the System Template is splitted across multiple arxml files, then the configuration generation script will not generate the necessary configurations for all required RTE callbacks.

Impact This can result in the generated code not functioning as expected. One common impact is 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 other projects 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 project is deleted from workspace or renamed.

Summary

Impact

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

User may not realise that their project contains invalid EcucValues that (correctly) result in 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 configured modules (Ex: BswM, EcuM, Crc,. . . ), which is not generated by Configuration

Generation, 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 for

Automatic configuration of BASIC mailboxes.

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

Workaround Configure the RX FIFOs manually.

Summary

Impact

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.

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

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


ETAS Limitations

Summary

Impact

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

Some EcucValues are created automatically during CodeGen. As a result, the Ecu configurations can appear to be incomplete according to ISOLAR-B despite being sufficient for RTA-BSW.

Workaround No workaround.

Summary

Impact

E2EXF Module is missing required dependencies

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

Workaround No workaround


6

ETAS

Integration Hints

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 selected in the Autosar Explorer view, otherwise they will be disabled.


7

ETAS Integration Advice

Integration Advice

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

7.1

7.2

7.3

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

SchM Enter and Exit API

Some RTA-BSW modules use the macro SCHM_ENTER_DEFAULT() and SCHM_EXIT_DEFAULT() in their source code to suspend and resume interrupts.

In the integration folder, RTA-BSW provides an integration file SchM_Default.h

.

This file should be used to provide the implementation of the

SCHM_ENTER_DEFAULT() and SCHM_EXIT_DEFAULT() macros using the interrupt functions provided by the OS.

By default with using RTA-OS:

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

Configuration MemMaps

Memory mapping is supported by RTA-BSW modules. However, for specific hardware and compilers the user may need to modify the file Bsw_MemMap.h

. For more details please refer to the Autosar

Specification for Memory Mapping.

Callback functions

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


8

8.1

8.2

ETAS Migration

Migration

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

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 EcucValues must be modified to conform to the new ParamDefs. In some cases this will involved such as renaming, restructuring or removing the parameters/containers.

∙ *_EcucValues.arxml

files that are generated by ConfGen or CodeGen should be deleted as these will be regenerated by the relevant tools.

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

∙ ConfGen_version.h

will be regenerated during ConfGen.

∙ Project_EcucValues.arxml

will be regenerated during ConfGen. If specific manual changes have been made to this file then backup the file and transfer the manual changes to the one generated by new version of RTA-BSW.

∙ CanEcucValues.arxml

will be regenerated during ConfGen. If specific manual changes have been made to this file then backup the file and transfer the manual changes to the one generated by new 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 be

checked for modifications to the keywords. If there are any changes, the algo.properties

must 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.

CodeGen

∙ Config/BSW/

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

CodeGen.

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

CodeGen.

∙ *_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 specific 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 src folder. This backup will be used to compare with the new integration files generated by rerunning

CodeGen.

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


ETAS Diagnostic Workflow

9

9.1

9.1.1

Diagnostic Workflow

Importing ODX Files as DEXT

The AUTOSAR DEXT (Diagnostic Extract Template) specification describes a protocol for configuring BSW modules for diagnostic operations. DEXT describes the format of the diagnostic data, and its origin in the 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 in combination with the ODX to DEXT add-on. The RTA-BSW ConfGen tool can generate configuration information for the Diagnostic Event Manager (Dem) and Diagnostic Communication Manager (Dcm) modules from a valid DEXT file. However, some manual configuration will be required to supply configuration parameter values that cannot be automatically generated.

Supported Services

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

Service Name

SessionControl

ReadDataByIdentifier

WriteDataByIdentifier

ID DEXT Service Instance

0x10 DiagnosticSessionControl

0x22 DiagnosticReadDataByIdentifier

0x2E DiagnosticWriteDataByIdentifier

0x2F DiagnosticIOControl InputOutputControl-

ByIdentifier

ClearDiagnosticInformation

ReadDTCInformation

0x14 DiagnosticClearDiagnosticInformation

0x19 DiagnosticReadDTCInformation

SecurityAccess 0x27 DiagnosticSecurityAccess

CommunicationControl 0x28 DiagnosticComControl

ReadDataByPeriodicIdentifier

DynamicallyDefine-

DataIdentifier

RoutineControl

0x2A DiagnosticReadDataByPeriodicID

0x2C DiagnosticDynamicallyDefine-

DataIdentifier

0x31 DiagnosticRoutineControl

DEXT Service Class

DiagnosticSessionControlClass

DiagnosticReadDataByIdentifier-

Class

DiagnosticWriteDataByIdentifier-

Class

DiagnosticIOControlClass

DiagnosticClearDiagnosticInformationClass

DiagnosticReadDTCInformation-

Class

DiagnosticSecurityAccessClass

DiagnosticComControlClass

DiagnosticReadDataByPeriodicID-

Class

DiagnosticDynamicallyDefine-

DataIdentifierClass

DiagnosticRoutineControlClass

9.1.2

9.1.3

Prerequisites

This procedure assumes that you are already running the RTA-BSW plugin in ISOLAR-AB and have loaded a project into the workspace which conforms to the RTA-BSW requirements described in the RTA-BSW

Getting Started Guide

[7]

.

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 file should 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 containing the communication matrix information into the System Template. IF you wish to configure a system manually, you can omit the remaining steps in this procedure.


ETAS

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

Diagnostic Workflow

5. In the ‘Select File’ dialog, click the Browse button (1) in the DBC pane and use the file selector to specify the name and location of the DBC file to import. The Network pane (2) will display the network 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 select the .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 Template and then click Next .

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



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

OK .

11. In ‘AR Explorer’, select the DiagnosticContributionSet element as shown below, and then use the delete 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 menu to 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 the pop-up menu.



9.2

9.2.1

This completes the import process. You may now run the Confgen tool (see see

BSW Configuration

Generation ), which will create a set of configuration parameters for the diagnostic modules based on the

imported 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 Configuration section below.

Additional Configuration

Default Configuration

The following parameters are assigned default values during the Confgen process. The assigned defaults can be modified by editing the project’s algo.properties

file. Note that some defaults depend on other configurations, and may need to be manually added if the dependent conditions are not present in the target project.

Parameter

Dem/DemGeneral/DemGeneralInterfaceSupport

Dem/DemGeneral/DemDataElementClass/DemExternalCS-

DataElementClass/DemDataElementUsePort

Default Value

FALSE

TRUE

Dem/DemConfigSet/DemEventParameter/DemEventAvailable TRUE

Dem/DemGeneral/DemRbGeneral/DemRbSupportSuspicious FALSE

Dem/DemGeneral/DemRbGeneral/DemRbDebugData

Dem/DemGeneral/DemRbGeneral/DemRbDebugDataBeforeInit

Dem/DemGeneral/DemAvailabilitySupport

OFF

FALSE

Dem/DemGeneral/DemClearDTCBehavior

Dem/DemGeneral/DemDevErrorDetect

DEM_NO_AVAILABILITY

DEM_CLRRESP_NONVOLATILE_FINISH

FALSE

Dem/DemGeneral/DemEventCombinationSupport

Dem/DemGeneral/DemMaxNumberEventEntryPermanent

DEM_EVCOMB_DISABLED

0

Continued on next page



Table 9.1 – continued from previous page

Parameter

Dem/DemGeneral/DemMaxNumberPrestoredFF

Default Value

5

Dem/DemGeneral/DemSuppressionSupport

Dem/DemGeneral/DemTaskTime

Dem/DemGeneral/DemTriggerDcmReports

Dem/DemGeneral/DemTriggerDltReports

DEM_NO_SUPRESSION

0.01

FALSE

FALSE

Dem/DemGeneral/DemTriggerFiMReports

Dem/DemGeneral/DemTriggerMonitorInitBeforeClearOk

Dem/DemGeneral/DemVersionInfoApi

Dcm/DcmConfigSet/DcmDsd/DcmDsdRequestManufacturerNotificationEnabled

Dcm/DcmConfigSet/DcmDsd/DcmDsdRequestSupplierNotificationEnabled

Dcm/DcmConfigSet/DcmDsl/DcmDslBuffer/DcmDslBufferSize

Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocol-

Row/DcmTimStrP2ServerAdjust


Row/DcmTimStrP2StarServerAdjust


Row/DcmDslProtocolPriority

FALSE

FALSE

FALSE

FALSE

FALSE

255

0.01

0.01

0


Row/DcmSendRespPendOnTransToBoot

Dcm/DcmConfigSet/DcmPageBufferCf/DcmPagedBufferEnabled

Dcm/DcmGeneral/DcmDevErrorDetect

Dcm/DcmGeneral/DcmTaskTime

Dcm/DcmGeneral/DcmVersionInfoApi

Dcm/DcmGeneral/DcmRbGeneral/DcmRbConfirmForDSDGeneratedNegRes

Dcm/DcmGeneral/DcmRbGeneral/DcmRbOSTimerUse

Dcm/DcmGeneral/DcmRbGeneral/DcmRbRTEsupport

Dcm/DcmConfigSet/DcmDsp/DcmDspData/DcmDspDataUse-

Port

TRUE

FALSE

FALSE

0.01

FALSE

FALSE

CyclicCount

TRUE

USE_DATA_SENDER_RECEIVER

(except when DcmDspDataType is UINT8_DYN then default is

USE_DATA_SYNCH_FNC)

DCM_CONTROLMASK_NO Dcm/DcmConfigSet/DcmDsp/DcmDspDidInfo/DcmDspDidControl/DcmDspDidControlMask

DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmDspSecurityDelayTimeOnBoot

DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmDspSecurityUsePort

Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmDspSecurityAttemptCounterEnabled

Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmDspSecurityRow/DcmRbDspSecurityNumAttLock

10

USE_ASYNCH_CLIENT_SERVER

FALSE

0

Continued on next page



Parameter

Dcm/DcmConfigSet/DcmDsp/DcmDspSecurity/DcmRbDspSecurityStoreSeed

Table 9.1 – continued from previous page

Default Value

FALSE

DcmDsp/DcmDspRoutine/DcmDspRoutineUsePort


Row/DcmDslProtocolMaximumResponseSize

DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslMainConnection/DcmDslProtocolRxTester-

SourceAddr

TRUE

255

0

DcmDsp/DcmRbDspSesSecUsedInProtocol

Dcm/DcmConfigSet/DcmDsp/DcmRbDspReadDTC/DcmRbDspReadDTCMaxNumDTCRead

Dcm/DcmConfigSet/DcmDsp/DcmRbDspReadDTC/DcmRbDspReadDTCMaxNumRecordRead

UDS

1

1

9.2.2

Manual Configuration

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

Confgen tool.

∙ Dem/DemGeneral/DemNvRamBlockId

∙ Dem/DemInternalDataElementClass/DemDataElementDataSize

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

Connection/DcmDslProtocolComMChannelRef


Connection/DcmDslProtocolRx


Connection/DcmDslProtocolTx

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslPeriodicTransmission

∙ Dcm/DcmConfigSet/DcmDsl/DcmDslProtocol/DcmDslProtocolRow/DcmDslConnection/DcmDslResponseOnEvent


ETAS

10 ETAS Contact Addresses

10.1

ETAS HQ

ETAS GmbH

Borsigstraße 24

70469 Stuttgart

Germany

Phone: +49 711 3423-0

Fax: +49 711 3423-2106

WWW: www.etas.com

ETAS Contact Addresses

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

ETAS technical support

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

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.


ETAS RTA-BSW User Guide

RTA-BSW User Guide

Status: Release

Copyright

1

1.1

1.2

Introduction

Applicable Versions

Safety Notice

1.3

Definitions and Abbreviations

1.4

1.5

Bibliography

Conventions

2

How to use this User Guide

3

3.1

3.2

AUTOSAR

Motivation

Architecture

3.3

Methodology

3.4

Interfaces

3.5

Multi-core

4

4.1

4.2

4.3

RTA-BSW Architecture and Workflow

Installation

Integration with ISOLAR-AB

Activities and Outputs

4.4

Creating a System Template and Software Component Template

4.5

BSW Configuration Generation

4.6

BSW Code Generation

4.7

Handling Validation Errors Thrown By CodeGen

5

Limitations

6

Integration Hints

7

Integration Advice

7.1

7.2

7.3

SchM Enter and Exit API

Configuration MemMaps

Callback functions

8

8.1

8.2

Migration

ConfGen

CodeGen

9

9.1

Diagnostic Workflow

Importing ODX Files as DEXT

9.2

Additional Configuration

10 ETAS Contact Addresses

10.1

ETAS HQ

10.2

ETAS Subsidiaries and Technical Support

Related manuals

ETAS

RTA-BSW

ETAS

RTA-RTE