RTA-BSW User Guide - etas.com · RTA-J1939 supports diagnostics using J1939 protocol ......

RTA-BSW v2.1.1

User Guide

2

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 docu-ment. 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 concur-rence with the specifications stipulated in the contract.

Under no circumstances may any part of this document be copied, reproduced, transmit-

ted, stored in a retrieval system or translated into another language without the express written permission of ETAS GmbH.

© Copyright 2018 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 V2.1.1 R01 EN – 01.2018

RTA-BSW v2.1.1 User Guide 3

Contents

Contents ........................................................................................................................................ 3

1 Introduction ............................................................................................................................ 4

1.1. Applicable Versions .......................................................................................................... 4

1.2. Safety Notice ................................................................................................................... 4

1.3. Definitions and Abbreviations ............................................................................................ 4

1.4. Bibliography ..................................................................................................................... 6

1.5. Conventions ..................................................................................................................... 7

2 How to use this User Guide ...................................................................................................... 8

3 AUTOSAR ............................................................................................................................... 9

3.1. Motivation........................................................................................................................ 9

3.2. Architecture ................................................................................................................... 10

3.3. Methodology .................................................................................................................. 15

3.4. Interfaces ...................................................................................................................... 18

3.5. Multi-core ...................................................................................................................... 20

4 RTA-BSW Architecture and Workflow ...................................................................................... 22

4.1. Installation .................................................................................................................... 22

4.2. Integration with ISOLAR-A .............................................................................................. 22

4.3. Activities and Outputs ..................................................................................................... 22

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

4.5. BSW Configuration Generation ........................................................................................ 24

4.6. BSW Code Generation .................................................................................................... 94

5 ETAS Contact Addresses ........................................................................................................ 96

5.1. ETAS HQ ....................................................................................................................... 96

5.2. ETAS Subsidiaries and Technical Support ......................................................................... 96

Index........................................................................................................................................... 97


1 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-MEM supports persistent data storage

RTA-DIAG supports ASW/BSW diagnostics and logging

RTA-J1939 supports diagnostics using J1939 protocol

RTA-SAFE supports functional safety including watchdog

RTA-CAN for CAN-based communication

RTA-XCP supports eXtended Calibration Protocol

RTA-LIN for LIN-based communication

RTA-HWD[CAN] supports CAN hardware access

RTA-OS – an SC1-4 AUTOSAR Operating System

RTA-RTE – AUTOSAR Run-time Environment generator

RTA-BSW is provided as a plug-in to ETAS’s AUTOSAR Authoring Tool, ISOLAR-A.

1.1. Applicable Versions

This document applies to RTA-BSW v2.1.1. This is compatible with:

ISOLAR-A v9.3

RTA-RTE v5.10

RTA-OS v5.5

As far as is 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.

1.2. Safety Notice

CAUTION!

Any configuration(s) this User Guide describes are an example only and users must be review and adapt them 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.


BSW

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

BSWMD

BSW Module Description – an ARXML file modelling a BSW module including the schedulable and callable entities and the triggering BSW events. BSWMD files are generated by the RTA-BSW Code Generation process for modules that present an AUTOSAR interface to the RTE.

BSW Stack

A slice through the AUTOSAR Layered SW Architecture that comprises functionally related BSW modules from the OS, RTE, 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 AUTOSAR 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.

Communication Cluster

A set of ECUs linked by a communication medium using one or more Physical Channels. The communication can have arbitrary topology (bus, star, ring, etc.). All nodes within the cluster use the same communication protocol.

Communication Controller

A dedicated hardware device, e.g. a CAN Controller, through which frames and send and received from a network.

DTC

Diagnostic Trouble Code.

ECU

Electronic Control Unit. In the context of AUTOSAR, an ECU comprises one micro-controller/peripherals and associated ASW and AUTOSAR configuration. In particular, AUTOSAR 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 or the microcontroller.

ODX

Open Diagnostic Data Exchange – non-AUTOSAR format for configuring diagnostic software.

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

Physical Channel

Communication medium, e.g. a CAN Bus, used to send and receive information between ECUs. A CAN or LIN Cluster consists of exactly one Physical Channel whereas a FlexRay cluster may have multiple Physical Channels to provide redundancy.

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 AUTOSAR supplied schema.

SPI

Serial Peripheral Interface – synchronous serial interface using a master-slave architecture and widely used in automotive embedded systems.

SWC

AUTOSAR Software Component – A functional unit within ASW. An AUTOSAR application consists of multiple SWCs.

TP

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

UDS

Unified Diagnostic Services – A 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.

1.4. Bibliography

[1] AUTOSAR Motivation and Goals, AUTOSAR http:/www.autosar.org/about/basics/motivation-goals/

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


[2] RTA-RTE User Guide, v5.11, ETAS GmbH

[3] RTA-OS User Guide, v5.5, ETAS GmbH

[4] RTA-BSW Installation and Getting Started Guide, v2.1.1, ETAS GmbH

[5] ISOLAR-A V9.3 Getting Started Guide, ETAS GmbH

[6] RTA-OS Getting Started, v5.5, ETAS GmbH

[7] RTA-RTE Getting Started Guide, v5.11, ETAS GmbH

1.5. Conventions

The following typographical conventions are used in this document:

Mod AUTOSAR BSW Module

OCI_CANTxMessage msg0 = Code snippets are presented on a gray background and in the Courier font.

Meaning and usage of each command are explained by means of comments. The comments are enclosed by the

usual syntax for comments.

Choose File Open. Menu commands are shown in boldface with connecting arrow showing sub-menu / commands.

Click [OK]. GUI Buttons, e.g. those on dialog boxes, are shown in boldface with square brackets.

Press <ENTER>. Keyboard commands are shown 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 Text in drop-down lists on the screen, program code, as well as path- and file names are shown in the Courier font.

A distribution is always a one-dimensional table of sample

points.

General emphasis and new terms are set in boldface.


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

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

Architecture, Methodology and Interfaces. Readers already familiar with AUTOSAR development can skip this section.

Section 4 describes how to use RTA-BSW based on an exemplar workflow and how the

ConfGen and CodeGen elements of RTA-BSW derive the BSW configuration from the System Description and generate the BSW source core.


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

Figure 1: AUTOSAR Key Concepts

•SW Layers

•Services

•ECU Abstraction

•MCAL

Architecture

•How supplier and OEM interact

•Common configuration language

Methodology•Syntax and semantics

•System Description

•SWC Description

Interfaces


3.2. 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 – Automotive application SW 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.

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

Application Software

AUTOSAR Run-time Environment (RTE)

Microcontroller Hardware

Complex Drivers

ECU Abstraction Layer

Microcontroller Abstraction Layer (MCAL)

Service Layer

Figure 2: Layers within the AUTOSAR SW Architecture

Figure 2 shows the layers within the AUTOSAR Layered SW Architecture. Each layer encapsulates and abstracts the functionality and behavior 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) – provides communication and

scheduling services to application software. The Rte module’s purpose is to make application software independent of a mapping to a specific ECU and thus permits

SWCs reuse or relocation between ECUs in the vehicle.

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

modules. a

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

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 contains interface modules that provides an

abstraction of the MCAL to the Service Layer than encapsulates information on MCU

hardware layout, e.g. number and type of CAN controllers, by providing an AUTOSAR defined device abstraction. The abstraction provided ensures that the

service layer can provide its abstraction without regard to the particular characteristics of 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 to the ECU Abstraction Layer an AUTOSAR defined interface that

makes it independent of the MCU hardware.

3.2.2 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 – A 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 – A 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 and, as it is a form of

Interface, does not change data. AUTOSAR includes few specific Handler modules since the functionality is usually combined within an Interface or Driver module.

Manager – A 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 – A 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) – A 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 reentrant (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.

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 Figure 3. The functional blocks form the basis for the BSW stacks that collectively comprise RTA-BSW.





Memory Services

Comm. Services

IO HW Abstraction

Complex Drivers

Memory HW Abstraction

Memory DriveRs

Onboard Device

Abstraction

Micro-controller

Drivers

Comm. HW Abstraction

Comm Drivers

IO Drivers

System Services

Key

Service Layer

ECU Abstraction

Layer

MCAL

Figure 3: AUTOSAR Layered SW Architecture – High Level Structure.

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.

3.2.4 BSW Interactions

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

interact.




Memory Services

Comm. Services

IO HW Abstraction

Complex Drivers


Memory DriveRs

Onboard Device

Abstraction

Micro-controller

Drivers


Comm Drivers

IO Drivers

System Services

Key

Permitted

Forbidden

Discouraged

Figure 4: 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, AUTOSAR 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.


Figure 5 shows the AUTOSAR defined permitted interaction matrix for modules within the BSW. The figure is intended to be read row-wise and “” indicates access via a call-back

only.

Figure 5: AUTOSAR Layered SW Architecture Interaction Matrix

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:

When accessed by a BSW module the module must offer a configurable interface

that can adapt to the requirements of the CDD.

When accessing a BSW module not only must the BSW’s interface be configurable

(e.g. names of call-back routines) but the interface must be re-entrant as parallel access from upper-layers and the CDD may occur. In addition no manager BSW

module must exist since otherwise incoherent changes in the module’s state by the manager and the CDD might occur.

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

Uses Syst

em

Serv

ices

Mem

ory

Serv

ices

Com

m. Serv

ices

Com

ple

x D

rivers

I/O

HW

Abst

ract

ion

Onboard

Devic

e A

bst

ract

ion

Mem

ory

HW

Abst

ract

ion

Com

m. H

W A

bst

ract

ion

Mic

roco

ntr

olle

r D

rivers

Mem

ory

Drivers

Com

m. D

rivers

I/O

Drivers

SWC/RTE

System Services

Memory Services

Communication Services

Complex Driver Restricted Access

I/O HW Abstraction

On-board Device Abstraction



Microcontroller Drivers

Memory Drivers

Comm. Drivers

I/O Drivers


development from the creation of a system-level description through to generation of each

ECU’s executable.

RTA-BSW (inc. OS/RTE)Source files(.c/.h)

System Configuration

(ARXML)

ECU Extract(ARXML)

ECU Value Collection

(ARXML)

System Configuration

Input

SWC 1

SWC 2

Bus

ECU 1

SWC 1

SWC 2

ECU 2

SWC 1

SWC 1 SWC 2

RTE

BSW

Microcontroller

System Design

RTA-BSW, OS and RTE Generation

ECU Configuration

Figure 6: AUTOSAR Methodology

The AUTOSAR methodology works in conjunction with the AUTOSAR Interfaces that

standardize the data exchange formats used within the development process.


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

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. In addition as it contains all information about the vehicle – some of which will be proprietary and therefore not distributable from OEM to

supplier.

The AUTOSAR methodology defines a sub-process within System Design to derive either a System Extract (information pertaining to one functional sub-system) or an ECU Extract

(information for a single ECU) from the complete system description.

Figure 7 shows the hierarchy formed from System Description, System Extract and ECU extract.

System Description

System ExtractSystem Extract

ECU Extract ECU Extract ECU Extract

Communication Bus

ECU 1

Swc A Swc B

RTE

BSW

ECU 2

Swc C

RTE

BSW

Swc D

ECU 3

Swc E

RTE

BSW

Swc F

Figure 7: AUTOSAR System Description, System Extract and ECU Extract hierarchy

3.3.2 ECU Configuration

The ECU Extract contains sufficient information for configuration/generation of the BSW

modules and the RTE for a single ECU. For example, the 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 on other ECUs – this process is automated by ISOLAR-A.


3.3.3 BSW and RTE Generation

RTA-BSW ConfGen processes the system description to derive a default ECU

Configuration Description. The integrator then applies any desired manual updates to the default ECU Configuration (using ISOLAR-A) before the RTA-BSW CodeGen process

generates the BSW.

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

3.4. Interfaces

The AUTOSAR Interfaces defines when and how participants within the AUTOSAR

Methodology, such as OEM and supplier, exchange information.

3.4.1 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 AUTOSAR-supplied 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 AUTOSAR 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 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 functions.

Figure 8 shows the interface forms used within the AUTOSAR Architecture.

Com

Container

ComSignal

Parameters

ComIPdu

Parameters

ComSignalGroup

Parameters

ComGroupSignal

Parameters

ComGroupSignal

Parameters

ComGeneral

Parameters


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.

ASW

RTE

BSWMicrocontroller Hardware

Operating System

Standardized Interface

Stand

ardize

d

Interfa

ce

StandardizedAUTOSAR Interface


AUTOSARInterface

AUTOSARInterface

Services CommunicationECU

Abstraction

Complex Device Driver


Microcontroller Abstraction

AUTOSARInterface

Application SWC

AUTOSARInterface

ActuatorSWC

AUTOSARInterface

SensorSWC

AUTOSARInterface

ApplicationSWC

Figure 8: Interfaces in the AUTOSAR Layered SW Architecture

3.5. Multi-core

RTA-BSW supports AUTOSAR R4.0 and therefore does not, in general, support the

distribution of BSW across multiple ECU Partitions (microcontroller cores). The following constraints therefore 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 Ecuc-

PartitionBswModuleExecution to true.

No other ECU partition must also set the ECUC parameter EcucPartitionBswModule-Execution to true.

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 ECU partition.


All ASW that need to access BSW must be mapped to the same ECU partition as the BSW. For example, ASW access to NvM for non-volatile memory use or Com for inter-ECU communication.

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.

Figure 9 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.

Asw/Bsw Partition 1 Asw Partition 2

SwcB

SwcC

Proxy

BSW

Asw Partition 3

SwcD

SwcE

SwcAInter-

PartitionComms.

Intra-PartitionComms.

Key

Figure 9: Multi-core access to BSW using proxy SWC


4 RTA-BSW Architecture and Workflow

RTA-BSW is an implementation of the AUTOSAR BSW and includes multiple module bundles that aggregate AUTOSAR functionality into coherent packages:

RTA-BASE – ECU and BSW mode management

RTA-COM – network-independent communication components

RTA-MEM – persistent/non-volatile data storage for ASW and BSW

RTA-DIAG – ASW/BSW diagnostics and logging

RTA-SAFE – components for safety management

RTA-CAN – CAN-specific network components

RTA-XCP – supports XCP protocol

RTA-LIN – LIN-specific network components

RTA-J1939 – supports diagnostics using J1939 protocol (with ISOBUS extensions)

RTA-HWD[CAN] – support for external CAN transceivers

RTA-OS – real-time operating system

RTA-RTE – RTE generator

4.1. Installation

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

Installation and Getting Started Guide [4] for detailed installation instructions.

RTA-OS and RTA-RTE both use a different installation approach to the other RTA-BSW stacks. Refer to RTA-OS Getting Started [6] and RTE Getting Started Guide [7]

respectively for installation instructions for these.

4.2. Integration with ISOLAR-A

RTA-BSW is a plug-in for the ISOLAR-A 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 create an equivalent configuration in

EcucValueDescription format, which allows specific parameterization 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 generator.

See below for the use of ConfGen and CodeGen in a typical workflow.

The following sections provide information on using these two tools focusing on the different options that they present.

4.3. Activities and Outputs

Figure 10 illustrates the activities and generated outputs present in the intended workflow for the RTA-BSW plug-in.


The workflow shown in Figure 10 contains some key steps:

The AUTOSAR System Description ARXML file(s) are created entirely using an

AUTOSAR Authoring Tool, such as ISOLAR-A, or by importing information from legacy

files, such as DBC, LDF or ODX.

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.

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

default BSW Configuration using ECUC Value Collection ARXML.

If required, the default BSW Configuration can be adaption to a specific user-case prior

to final BSW generation.

RTA-BSW CodeGen creates 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.

Import Existing Information (Optional)

ISOLAR-A Import

DBC / LDF / etc.

ConfGen CodeGen

RTA-BSW Implementation

ASW Configuration EcucValue Adaption for specific use-case

ASWDescription

(ARXML)

Software Component

Template

System Description

(ARXML)

SystemTemplate

BSW Configuration

(ARXML)

ECUC Value Collection

Figure 10: 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 Component Templates to generate the BSW Configuration. The ISOLAR-A v9.3 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.

4.4.1 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:

File format Modules configured automatically

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

IpduM, Nm, PduR)


ODX (must feature both UDS and J1939 configuration)

RTA-DIAG (Dcm, Dem), RTA-J1939 (J1939Tp, J1939Dcm, J1939Rm, J1939Rm)

LDF RTA-LIN (LinIf, LinSM)

Using ISOLAR-A to import legacy file formats is described in Section 5.3 (“Creating an

AUTOSAR System Template in ISOLAR-A”) of the ISOLAR-A v9.3 Getting Started Guide [5].

4.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, click on the toolbar icon with the “ ” symbol (Screenshot 1) with an AUTOSAR System Template project selected.

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). and, to make full use of this tool it is recommended that the

complete Virtual Functional Bus (VFB) configuration is present.

Screenshot 1: RTA-BSW Toolbar

The first step is to select the RTA-BSW version to run (Screenshot 2):

Screenshot 2: RTA-BSW Version Selection Dialog


Next, select the ECU Instance for which you wish to generate the EcucValueDescription

values (Screenshot 3):

Screenshot 3: RTA-BSW ECU Instance Selection Dialog

After clicking [OK] the ConfGen process will begin, reporting results to the console (Screenshot 4):

Screenshot 4: RTA-BSW Import result log (example)

After completion of ConfGen the project will contain EcucValueDescription ARXML files

and Parameter definitions which will allow you to customize and generate AUTOSAR BSW.


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.

Repeating RTA-BSW configuration generation deletes and then recreates the Project_EcucValues.arxml and

Can_EcucValues.arxml files. Hence, the process will also delete any changes made by the user that are contained in the 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.

ISOLAR-A presents split items as a

single entity when viewing using ARExplorer and “Show Abstraction

Groups” is selected. Alternatively, the ISOLAR-A Splitable Explorer presents

a combined view of all split items and

can be used to create new split items.

The RTA-BSW generation tools –

RTA-OS, RTA-RTE and RTA-BSW – will then ensure that the split items

in different Ecuc containers are

“combined” to form a single item.

root

pkgA

El1 El2 El1 El2 El3 El4

pkgB pkgC

El1 El2

root

pkgA

El1 El2

pkgB

El1 El2

root

pkgB

El3 El4

pkgC

El1 El2

merge merge

4.5.2 ConfgGen Parameters

It is possible to change the default value used by ConfGen for the parameters.

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.

If the system template can configure the value then it is not possible to change the default

in the “algo.properties” file.

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

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

module

o The name of the module that contains the parameter.

specifier

o ALL to apply to all instances of the module.


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

parameter

o The name parameter to set.

o If there is a naming collision in the module, it is necessary to use the full

path of the parameter.

default_value

o The new default value to use.

CanConfigSet

CanConfigSet//CanController//CanBusoffProcessing

This parameter is a Default value.

The default value is POLLING.

The “algo.properties” file can override this default.

CanConfigSet//CanController//CanControllerActivation


The default value is TRUE. The “algo.properties” file can override this default.

CanConfigSet//CanController//CanControllerBaseAddress


The default value is 0. The “algo.properties” file can override this default.

CanConfigSet//CanController//CanControllerBaudrateConfig//CanContr

ollerBaudRate

The System Template derives this parameter.

The default value/s are ['500']. The “algo.properties” file can override this default.


ollerPropSeg



ollerSeg1



ollerSeg2



ollerSyncJumpWidth


CanConfigSet//CanController//CanControllerId


CanConfigSet//CanController//CanFilterMask//CanFilterMaskValue


CanConfigSet//CanController//CanRxProcessing



CanConfigSet//CanController//CanRxProcessing


The default value is POLLING. The “algo.properties” file can override this default.

CanConfigSet//CanController//CanTxProcessing

This parameter is a Default value. The default value is POLLING.


CanConfigSet//CanController//CanWakeupProcessing

This parameter is a Default value. The default value is POLLING.


CanConfigSet//CanHardwareObject


CanConfigSet//CanHardwareObject//CanHandleType


CanConfigSet//CanHardwareObject//CanIdType


CanConfigSet//CanHardwareObject//CanObjectId


CanConfigSet//CanHardwareObject//CanObjectType


CanConfigSet//CanHardwareObject//CanTTHardwareObjectTrigger//CanTT

HardwareObjectBaseCycle




HardwareObjectCycleRepetition


The default value is 1.



HardwareObjectTimeMark

This parameter is a Default value. The default value is 0.



HardwareObjectTriggerId




CanGeneral

CanGeneral//CanCpuType


The default value is OTHERS. The “algo.properties” file can override this default.

CanGeneral//CanDevErrorDetection



CanGeneral//CanHardwareCancellation

This parameter is a Default value. The default value is FALSE.


CanGeneral//CanIdenticalIdCancellation



CanGeneral//CanIndex



CanGeneral//CanMultiplexedTransmission


The default value is FALSE.


CanGeneral//CanVersionInfoApi


The default value is FALSE. The “algo.properties” file can override this default.


CanIf

CanIf//CanIfCtrlDrvCfg//CanIfCtrlCfg//CanIfCtrlId


CanIf//CanIfCtrlDrvCfg//CanIfCtrlDrvRxIndication

This parameter is a Default value. The default value is TRUE.


CanIf//CanIfCtrlDrvCfg//CanIfCtrlDrvTxCancellation



CanIf//CanIfDispatchCfg//CanIfDispatchUserCtrlBusOffUL

This parameter is a Default value. The default value is CAN_SM.


CanIf//CanIfDispatchCfg//CanIfDispatchUserCtrlModeIndicationUL


The default value is CAN_SM.


CanIf//CanIfInitCfg//CanIfInitCfgSet


The default value is 0. This default cannot be overridden.

CanIf//CanIfInitCfg//CanIfInitHohCfg//CanIfHrhCfg//CanIfHrhListCfg

//CanIfHrhListCanId


CanIf//CanIfInitCfg//CanIfInitHohCfg//CanIfHrhCfg//CanIfHrhRangeCf

g//CanIfHrhRangeBaseId



g//CanIfHrhRangeMask



g//CanIfHrhRangeRxPduLowerCanId


This default cannot be overridden.


g//CanIfHrhRangeRxPduRangeCanIdType



g//CanIfHrhRangeRxPduUpperCanId


CanIf//CanIfInitCfg//CanIfInitHohCfg//CanIfHrhCfg//CanIfHrhSoftwar

eFilter



CanIf//CanIfInitCfg//CanIfInitHohCfg//CanIfHthCfg


The default value is TRUE. This default cannot be overridden.

CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduCanId


CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduCanIdMask


CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduCanIdRange//CanIfRxP

duCanIdRangeLowerCanId


CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduCanIdRange//CanIfRxP

duCanIdRangeUpperCanId


CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduCanIdType


CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduDlc



CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduId


CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduReadData




CanIf//CanIfInitCfg//CanIfRxPduCfg//CanIfRxPduUserRxIndicationName


CanIf//CanIfInitCfg//CanIfTxPduCfg//CanIfTxPduCanId


CanIf//CanIfInitCfg//CanIfTxPduCfg//CanIfTxPduCanIdMask



CanIf//CanIfInitCfg//CanIfTxPduCfg//CanIfTxPduCanIdType


CanIf//CanIfInitCfg//CanIfTxPduCfg//CanIfTxPduDlc


CanIf//CanIfInitCfg//CanIfTxPduCfg//CanIfTxPduId


CanIf//CanIfInitCfg//CanIfTxPduCfg//CanIfTxPduReadNotifyStatus




CanIf//CanIfPublicCfg//CanIfAddressTranslationTableSupport



CanIf//CanIfPublicCfg//CanIfMetaDataSupport


CanIf//CanIfPublicCfg//CanIfPublicCancelTransmitSupport



CanIf//CanIfPublicCfg//CanIfPublicChangeBaudrateSupport




CanIf//CanIfPublicCfg//CanIfPublicDevErrorDetect



CanIf//CanIfPublicCfg//CanIfPublicMultipleDrvSupport



CanIf//CanIfPublicCfg//CanIfPublicNumberOfCanHwUnits



CanIf//CanIfPublicCfg//CanIfPublicReadRxPduDataApi



CanIf//CanIfPublicCfg//CanIfPublicReadRxPduNotifyStatusApi



CanIf//CanIfPublicCfg//CanIfPublicReadTxPduNotifyStatusApi


The default value is TRUE.


CanIf//CanIfPublicCfg//CanIfPublicSetDynamicTxIdApi



CanIf//CanIfPublicCfg//CanIfPublicTxBuffering



CanIf//CanIfPublicCfg//CanIfPublicTxConfirmPollingSupport




CanIf//CanIfPublicCfg//CanIfPublicVersionInfoApi



CanIf//CanIfPublicCfg//CanIfPublicWakeupCheckValidApi




CanNm

CanNm//CanNmGlobalConfig


CanNm//CanNmGlobalConfig//CanNmBusLoadReductionEnabled


CanNm//CanNmGlobalConfig//CanNmBusSynchronizationEnabled


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmBusLoadReductio

nActive


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmComMNetworkHand

leRef


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmImmediateNmCycl

eTime


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmImmediateNmTran

smissions


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmMsgCycleOffset


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmMsgCycleTime


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmMsgReducedTime


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmMsgTimeoutTime


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmNodeId


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmPduCbvPosition


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmPduNidPosition


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmRemoteSleepIndT

ime


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmRepeatMessageTi

me


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmTimeoutTime


CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmUserDataLength



CanNm//CanNmGlobalConfig//CanNmChannelConfig//CanNmWaitBusSleepTim

e


CanNm//CanNmGlobalConfig//CanNmComControlEnabled


CanNm//CanNmGlobalConfig//CanNmComUserDataSupport



CanNm//CanNmGlobalConfig//CanNmDevErrorDetect



CanNm//CanNmGlobalConfig//CanNmImmediateRestartEnabled




CanNm//CanNmGlobalConfig//CanNmImmediateTxconfEnabled



CanNm//CanNmGlobalConfig//CanNmMainFunctionPeriod


CanNm//CanNmGlobalConfig//CanNmNodeDetectionEnabled


CanNm//CanNmGlobalConfig//CanNmNumberOfChannels


CanNm//CanNmGlobalConfig//CanNmPassiveModeEnabled


CanNm//CanNmGlobalConfig//CanNmPduRxIndicationEnabled


CanNm//CanNmGlobalConfig//CanNmRemoteSleepIndEnabled


CanNm//CanNmGlobalConfig//CanNmRepeatMsgIndEnabled


CanNm//CanNmGlobalConfig//CanNmStateChangeIndEnabled


CanNm//CanNmGlobalConfig//CanNmUserDataEnabled




CanSM

CanSM//CanSMConfiguration//CanSMManagerNetwork//CanSMBorCounterL1T

oL2



CanSM//CanSMConfiguration//CanSMManagerNetwork//CanSMBorTxConfirma

tionPolling



CanSM//CanSMConfiguration//CanSMManagerNetwork//CanSMComMNetworkHa

ndleRef


CanSM//CanSMConfiguration//CanSMManagerNetwork//CanSMNetworkIndex


CanSM//CanSMConfiguration//CanSMModeRequestRepetitionMax




CanSM//CanSMGeneral//CanSMDevErrorDetect



CanSM//CanSMGeneral//CanSMVersionInfoApi




CanTp

CanTp//CanTpConfig//CanTpChannel//CanTpChannelMode


The default value is CANTP_MODE_HALF_DUPLEX. The “algo.properties” file can override this default.

CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpBs


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNAe


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNAe//CanTpNAe


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNSa


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNSa//CanTpNSa


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNTa


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNTa//CanTpNTa


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNar


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNbr


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpNcr


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpRxAddressingFo

rmat


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpRxNPdu//CanTpR

xNPduId


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpRxNSduFCActiva

tion


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpRxPaddingActiv

ation


CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpRxPaddingValue



CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpRxTaType



CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpTxFcNPdu//CanT

pTxFcNPduConfirmationPduId




CanTp//CanTpConfig//CanTpChannel//CanTpRxNSdu//CanTpTxFcNPdu//CanT

pTxFcNPduRef


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNAe


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNAe//CanTpNAe


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNSa


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNSa//CanTpNSa


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNTa


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNTa//CanTpNTa


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNas


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNbs


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpNcs


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpRxFcNPdu//CanT

pRxFcNPduRef


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTc


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxAddressingFo

rmat


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxNPdu//CanTpT

xNPduConfirmationPduId


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxNPdu//CanTpT

xNPduRef


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxNSduFCActiva

tion


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxNSduId



CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxPaddingActiv

ation


CanTp//CanTpConfig//CanTpChannel//CanTpTxNSdu//CanTpTxTaType


CanTp//CanTpConfig//CanTpGeneral//CanTpChangeParameterRequestApi



CanTp//CanTpConfig//CanTpGeneral//CanTpChannelMode

This parameter is a Default value. The default value is CANTP_MODE_HALF_DUPLEX.


CanTp//CanTpConfig//CanTpGeneral//CanTpDevErrorDetect




CanTp//CanTpConfig//CanTpGeneral//CanTpFCHandling


The default value is CANTP_FC_ADAPTABLE. The “algo.properties” file can override this default.

CanTp//CanTpConfig//CanTpGeneral//CanTpMainFunctionPeriod


CanTp//CanTpConfig//CanTpGeneral//CanTpStrictDlcCheck



CanTp//CanTpConfig//CanTpGeneral//CanTpTransmitFromRxind


The default value is CANTP_OFF.


CanTp//CanTpConfig//CanTpGeneral//CanTpTxBurstMode


The default value is CANTP_OFF. The “algo.properties” file can override this default.

CanTp//CanTpConfig//CanTpGeneral//CanTpUnexptdPduHandling


The default value is CANTP_IGNORE. The “algo.properties” file can override this default.

CanTp//CanTpConfig//CanTpGeneral//CanTpVersionInfoApi




Com

Com//ComConfig//ComConfigurationId



Com//ComConfig//ComGwMapping//ComGwDestination//ComGwDestinationDe

scription//ComBitPosition



scription//ComFilter//ComFilterAlgorithm



scription//ComFilter//ComFilterMask



scription//ComFilter//ComFilterMax



scription//ComFilter//ComFilterMin



scription//ComFilter//ComFilterOffset



scription//ComFilter//ComFilterPeriod



scription//ComFilter//ComFilterX



scription//ComSignalEndianness



scription//ComTransferProperty



scription//ComUpdateBitPosition


Com//ComConfig//ComGwMapping//ComGwSource//ComGwSourceDescription/

/ComBitPosition



/ComBitSize



/ComSignalEndianness




/ComSignalLength



/ComSignalType



/ComUpdateBitPosition


Com//ComConfig//ComIPdu//ComIPduDirection


Com//ComConfig//ComIPdu//ComIPduHandleId


Com//ComConfig//ComIPdu//ComIPduType


Com//ComConfig//ComIPdu//ComTimeout


Com//ComConfig//ComIPdu//ComTxIPdu//ComMetaDataDefault


Com//ComConfig//ComIPdu//ComTxIPdu//ComMetaDataDefault


Com//ComConfig//ComIPdu//ComTxIPdu//ComMinimumDelayTime


Com//ComConfig//ComIPdu//ComTxIPdu//ComTxIPduUnusedAreasDefault


Com//ComConfig//ComIPdu//ComTxIPdu//ComTxModeFalse//ComTxMode//Com

TxModeMode



TxModeNumberOfRepetitions



TxModeRepetitionPeriod



TxModeTimeOffset



TxModeTimePeriod



Com//ComConfig//ComIPdu//ComTxIPdu//ComTxModeTrue//ComTxMode//ComT

xModeMode




xModeNumberOfRepetitions



xModeRepetitionPeriod



xModeTimeOffset



xModeTimePeriod



Com//ComConfig//ComIPduGroup//ComIPduGroupHandleId


Com//ComConfig//ComSignal//ComBitPosition


Com//ComConfig//ComSignal//ComBitSize


Com//ComConfig//ComSignal//ComFilter//ComFilterAlgorithm


Com//ComConfig//ComSignal//ComFilter//ComFilterMask


Com//ComConfig//ComSignal//ComFilter//ComFilterMax


Com//ComConfig//ComSignal//ComFilter//ComFilterMin


Com//ComConfig//ComSignal//ComFilter//ComFilterOffset


Com//ComConfig//ComSignal//ComFilter//ComFilterPeriod


Com//ComConfig//ComSignal//ComFilter//ComFilterX


Com//ComConfig//ComSignal//ComHandleId


Com//ComConfig//ComSignal//ComNotification


Com//ComConfig//ComSignal//ComSignalDataInvalidValue


Com//ComConfig//ComSignal//ComSignalEndianness



Com//ComConfig//ComSignal//ComSignalLength


Com//ComConfig//ComSignal//ComSignalType


Com//ComConfig//ComSignal//ComTimeout


Com//ComConfig//ComSignal//ComTimeoutNotification


Com//ComConfig//ComSignal//ComTransferProperty


Com//ComConfig//ComSignal//ComUpdateBitPosition


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComBitPosition


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComBitSize


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComFilter//ComFilt

erAlgorithm



erMask



erMax



erMin



erOffset



erPeriod



erX


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComHandleId


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComSignalDataInval

idValue


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComSignalEndiannes

s



Com//ComConfig//ComSignalGroup//ComGroupSignal//ComSignalLength


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComSignalType


Com//ComConfig//ComSignalGroup//ComGroupSignal//ComTransferPropert

y


Com//ComConfig//ComSignalGroup//ComHandleId


Com//ComConfig//ComSignalGroup//ComNotification


Com//ComConfig//ComSignalGroup//ComTimeout


Com//ComConfig//ComSignalGroup//ComTimeoutNotification


Com//ComConfig//ComSignalGroup//ComTransferProperty


Com//ComConfig//ComSignalGroup//ComUpdateBitPosition


Com//ComConfig//ComTimeBase//ComGwTimeBase



Com//ComConfig//ComTimeBase//ComRxTimeBase


The default value is 0.01. This default cannot be overridden.

Com//ComConfig//ComTimeBase//ComTxTimeBase


The default value is 0.01. This default cannot be overridden.

Com//ComGeneral//ComConfigurationUseDet



Com//ComGeneral//ComMetaDataSupport



ComM

ComM//ComMChannel//ComMBusType


The default value/s are ['COMM_BUS_TYPE_INTERNAL']. The “algo.properties” file can override this default.

ComM//ComMChannel//ComMChannelId


ComM//ComMChannel//ComMFullCommRequestNotificationEnabled



ComM//ComMChannel//ComMNetworkManagement//ComMNmLightTimeout



ComM//ComMChannel//ComMNetworkManagement//ComMNmVariant


The default value/s are ['NONE'].


ComM//ComMChannel//ComMNoCom



ComM//ComMChannel//ComMUserPerChannel//ComMUserChannel


ComM//ComMGeneral//ComMDevErrorDetect



ComM//ComMGeneral//ComMEcuGroupClassification




ComM//ComMGeneral//ComMModeLimitationEnabled



ComM//ComMGeneral//ComMPncGatewayEnabled



ComM//ComMGeneral//ComMPncSupport



ComM//ComMGeneral//ComMSynchronousWakeUp





ComM//ComMGeneral//ComMVersionInfoApi



ComM//ComMGeneral//ComMWakeupInhibitionEnabled



ComM//ComMUser//ComMUserIdentifier



Dcm

Dcm//DcmConfigSet//DcmDsd//DcmDsdServiceTable//DcmDsdService


Dcm//DcmConfigSet//DcmDsd//DcmDsdServiceTable//DcmDsdService//DcmD

sdSidTabFnc



sdSidTabFnc



sdSidTabScheduler



sdSidTabScheduler



sdSidTabServiceId




sdSidTabServiceId



sdSidTabSessionLevelRef



sdSidTabSidInitFunction



sdSidTabSidInitFunction



sdSidTabSubfuncAvail



sdSidTabSubfuncAvail



sdSubService



sdSubService//DcmDsdSubServiceId



sdSubService//DcmDsdSubServiceSecurityLevelRef




sdSubService//DcmDsdSubServiceSessionLevelRef


Dcm//DcmConfigSet//DcmDsd//DcmDsdServiceTable//DcmDsdSidTabId


Dcm//DcmConfigSet//DcmDsd//DcmDsdServiceTable//DcmDsdSidTabId


Dcm//DcmConfigSet//DcmDsd//DcmDsdServiceTable//NRCForService


Dcm//DcmConfigSet//DcmDsd//DcmDsdServiceTable//NRCForService


Dcm//DcmConfigSet//DcmDsl//DcmDslBuffer//DcmDslBufferSize


Dcm//DcmConfigSet//DcmDsl//DcmDslDiagResp//DcmDslDiagRespMaxNumRes

pPend


Dcm//DcmConfigSet//DcmDsl//DcmDslProtocol//DcmDslProtocolRow//DcmD

slConnection//DcmDslMainConnection//DcmDslPeriodicTranmissionConRe

f



slConnection//DcmDslMainConnection//DcmDslProtocolRx//DcmDslProtoc

olRxAddrType




olRxAddrType




olRxPduId




olRxPduId




olRxPduRef




olRxTesterSourceAddr




slConnection//DcmDslMainConnection//DcmDslProtocolRxTesterSourceAd

dr



slConnection//DcmDslMainConnection//DcmDslProtocolTx//DcmDslProtoc

olTxPduRef



slConnection//DcmDslMainConnection//DcmDslProtocolTx//DcmDslTxConf

irmationPduId



slConnection//DcmDslPeriodicTransmission//DcmDslPeriodicConnection

//DcmDslPeriodicTxPduRef



slProtocolID



slProtocolIsParallelExecutab



slProtocolNRC21OnPriorityAssessmentReject



slProtocolPriority



slProtocolSIDTable



slProtocolSIDTable



slProtocolTransType


Dcm//DcmConfigSet//DcmDsl//DcmDslProtocol//DcmDslProtocolRow//DcmS

endRespPendOnTransToBoot


Dcm//DcmConfigSet//DcmDsl//DcmDslProtocol//DcmDslProtocolRow//DcmT

imStrP2ServerAdjust


Dcm//DcmConfigSet//DcmDsl//DcmDslProtocol//DcmDslProtocolRow//DcmT

imStrP2StarServerAdjust



Dcm//DcmConfigSet//DcmDsp//DcmDspComControl//DcmDspComControlAllCh

annel//DcmDspAllComMChannelRef


Dcm//DcmConfigSet//DcmDsp//DcmDspControlDTCSetting//DcmDspControlD

TCSettingReEnableModeRuleRef


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataFreezeCurrentStat

eFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataInfoRef


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataReadFnc

This parameter is a Default value. The default value is A_UINT32.


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataResetToDefaultFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataReturnControlToEc

uFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataShortTermAdjustme

ntFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataSize


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataType


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataUsePort


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDataWriteFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDiagnosisScaling


Dcm//DcmConfigSet//DcmDsp//DcmDspData//DcmDspDiagnosisScaling//Dcm

DspAlternativeDataProps//DcmDspLinearScale//DcmDspDiagnosisReprese

ntationDataLowerRange




ntationDataOffset




ntationDataResolution





ntationDataUpperRange


Dcm//DcmConfigSet//DcmDsp//DcmDspDataInfo//DcmDspDataFixedLength



Dcm//DcmConfigSet//DcmDsp//DcmDspDid//DcmDspDidIdentifier


Dcm//DcmConfigSet//DcmDsp//DcmDspDid//DcmDspDidInfoRef


Dcm//DcmConfigSet//DcmDsp//DcmDspDid//DcmDspDidMaxNumberOfRecords/

/DcmDspDidMaxNumRecords


Dcm//DcmConfigSet//DcmDsp//DcmDspDid//DcmDspDidSignal//DcmDspDidDa

taPos


Dcm//DcmConfigSet//DcmDsp//DcmDspDid//DcmDspDidSignal//DcmDspDidDa

taRef


Dcm//DcmConfigSet//DcmDsp//DcmDspDid//DcmDspDidUsed


Dcm//DcmConfigSet//DcmDsp//DcmDspDidInfo//DcmDspDidAccess//DcmDspD

idControl//DcmDspDidControlSecurityLevelRef



idControl//DcmDspDidFreezeCurrentState



idControl//DcmDspDidResetToDefault



idControl//DcmDspDidReturnControlToEcu



idControl//DcmDspDidShortTermAdjustment



idRead



idRead//DcmDspDidReadSecurityLevelRef



idRead//DcmDspDidReadSessionRef




idWrite



idWrite//DcmDspDidWriteSecurityLevelRef



idWrite//DcmDspDidWriteSessionRef


Dcm//DcmConfigSet//DcmDsp//DcmDspDidInfo//DcmDspDidDynamicallyDefi

ned



Dcm//DcmConfigSet//DcmDsp//DcmDspMaxDidToRead


Dcm//DcmConfigSet//DcmDsp//DcmDspMaxPeriodicDidToRead


Dcm//DcmConfigSet//DcmDsp//DcmDspMemory//DcmDspMemoryIdInfo//DcmDs

pMemoryIdValue



pReadMemoryRangeInfo//DcmDspReadMemoryRangeHigh



pReadMemoryRangeInfo//DcmDspReadMemoryRangeHighRB



pReadMemoryRangeInfo//DcmDspReadMemoryRangeLow



pReadMemoryRangeInfo//DcmDspReadMemoryRangeLowRB


Dcm//DcmConfigSet//DcmDsp//DcmDspMemory//DcmDspUseMemoryId


Dcm//DcmConfigSet//DcmDsp//DcmDspPeriodicDidTransmission//DcmDspMa

xPeriodicDidScheduler


Dcm//DcmConfigSet//DcmDsp//DcmDspPeriodicTransmission//DcmDspPerio

dicTransmissionFastRate



dicTransmissionMediumRate




dicTransmissionSlowRate


Dcm//DcmConfigSet//DcmDsp//DcmDspReadDTC//DcmDspReadDTCRow//DcmDsp

DTCInfoSubFuncLevel


Dcm//DcmConfigSet//DcmDsp//DcmDspReadDTC//DcmDspReadDTCRow//DcmDsp

DTCSubFuncServHandler


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspRequestResultsRout

ineFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspRequestResultsRout

ineSupported


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspRoutineFixedLength


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspRoutineIdentifier


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspRoutineInfoRef


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspRoutineUsePort


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspStartRoutineFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspStopRoutineFnc


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutine//DcmDspStopRoutineSupport

ed


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutineInfo//DcmDspRoutineAuthori

zation//DcmDspRoutineSecurityLevelRef


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutineInfo//DcmDspRoutineRequest

ResIn//DcmDspRoutineRequestResInSignal//DcmDspRoutineSignalLength



ResIn//DcmDspRoutineRequestResInSignal//DcmDspRoutineSignalPos



ResIn//DcmDspRoutineRequestResInSignal//DcmDspRoutineSignalType



ResOut//DcmDspRoutineRequestResOutSignal//DcmDspRoutineSignalLengt

h




ResOut//DcmDspRoutineRequestResOutSignal//DcmDspRoutineSignalPos



ResOut//DcmDspRoutineRequestResOutSignal//DcmDspRoutineSignalType


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutineInfo//DcmDspRoutineStopIn/

/DcmDspRoutineStopInSignal//DcmDspRoutineSignalLength



/DcmDspRoutineStopInSignal//DcmDspRoutineSignalPos



/DcmDspRoutineStopInSignal//DcmDspRoutineSignalType


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutineInfo//DcmDspRoutineStopOut

//DcmDspRoutineStopOutSignal//DcmDspRoutineSignalLength



//DcmDspRoutineStopOutSignal//DcmDspRoutineSignalPos



//DcmDspRoutineStopOutSignal//DcmDspRoutineSignalType


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutineInfo//DcmDspStartRoutineIn

//DcmDspStartRoutineInSignal//DcmDspRoutineSignalLength



//DcmDspStartRoutineInSignal//DcmDspRoutineSignalPos



//DcmDspStartRoutineInSignal//DcmDspRoutineSignalType


Dcm//DcmConfigSet//DcmDsp//DcmDspRoutineInfo//DcmDspStartRoutineOu

t//DcmDspStartRoutineOutSignal//DcmDspRoutineSignalLength



t//DcmDspStartRoutineOutSignal//DcmDspRoutineSignalPos



t//DcmDspStartRoutineOutSignal//DcmDspRoutineSignalType


Dcm//DcmConfigSet//DcmDsp//DcmDspSecurity//DcmDspSecurityDelayTime

rMonitor



Dcm//DcmConfigSet//DcmDsp//DcmDspSecurity//DcmDspSecurityNRCExceed

NoOfAttempt


Dcm//DcmConfigSet//DcmDsp//DcmDspSecurity//DcmDspSecurityRow


Dcm//DcmConfigSet//DcmDsp//DcmDspSecurity//DcmDspSecurityRow//DcmD

spSecurityCompareKeyFnc



spSecurityDelayTime



spSecurityDelayTimeOnBoot



spSecurityGetSeedFnc



spSecurityKeySize





spSecurityKeySize



spSecurityLevel




spSecurityLevel



spSecurityNumAttDelay




spSecurityNumAttDelay



spSecurityNumAttLock





spSecurityNumAttLock



spSecuritySeedSize




spSecuritySeedSize



spSecuritySessionRef



spSecurityUsePort


Dcm//DcmConfigSet//DcmDsp//DcmDspSecurity//DcmDspSecurityStoreSeed


Dcm//DcmConfigSet//DcmDsp//DcmDspSesSecUsedInProtocol


Dcm//DcmConfigSet//DcmDsp//DcmDspSession//DcmDspSessionRow//DcmDsp

SessionForBoot



SessionLevel




SessionLevel



SessionP2ServerMax



SessionP2ServerMax



SessionP2StarServerMax



SessionP2StarServerMax




Dcm//DcmConfigSet//DcmGeneral//DcmDevErrorDetect


Dcm//DcmConfigSet//DcmGeneral//DcmDslP2maxthresholdtime


Dcm//DcmConfigSet//DcmGeneral//DcmDspDataDefaultEndianness


Dcm//DcmConfigSet//DcmGeneral//DcmOSCounterMacro


Dcm//DcmConfigSet//DcmGeneral//DcmOSTimerUse


Dcm//DcmConfigSet//DcmGeneral//DcmOSTimerUse


Dcm//DcmConfigSet//DcmGeneral//DcmRTEInterface


Dcm//DcmConfigSet//DcmGeneral//DcmRTEsupport


Dcm//DcmConfigSet//DcmGeneral//DcmRequestManufacturerNotificationE

nabled


Dcm//DcmConfigSet//DcmGeneral//DcmRequestSupplierNotificationEnabl

ed


Dcm//DcmConfigSet//DcmGeneral//DcmRespondAllRequest


Dcm//DcmConfigSet//DcmGeneral//DcmTaskTime



Dcm//DcmConfigSet//DcmGeneral//DcmTaskTime


Dcm//DcmConfigSet//DcmGeneral//DcmVersionInfoApi


Dcm//DcmConfigSet//DcmPageBufferCfg//DcmPagedBufferEnabled


Dcm//DcmConfigSet//DcmPageBufferCfg//DcmPagedBufferEnabled


Dcm//DcmConfigSet//DcmProcessingConditions//DcmModeCondition//DcmC

onditionType



Dem

Dem//DemGeneral//DemDataElementClass//DemExternalCSDataElementClas

s//DemDataElementDataSize



s//DemDataElementReadFnc



s//DemDataElementUsePort


Dem//DemGeneral//DemDataElementClass//DemExternalSRDataElementClas

s//DemDataElementDataSize


Dem//DemGeneral//DemDataElementClass//DemInternalDataElementClass/

/DemDataElementDataSize



EcuC

EcuC//EcucPduCollection//Pdu//MetaDataLength



EcuC//EcucPduCollection//Pdu//PduLength



Fee

Fee//FeeBlockConfiguration//FeeBlockNumber


Fee//FeeBlockConfiguration//FeeBlockSize


Fee//FeeBlockConfiguration//FeeDeviceIndex


Fee//FeeBlockConfiguration//FeeImmediateData


Fee//FeeBlockConfiguration//FeeNumberOfWriteCycles



Fee//FeeGeneral//FeeDevErrorDetect



Fee//FeeGeneral//FeeIndex



Fee//FeeGeneral//FeePollingMode



Fee//FeeGeneral//FeeSetModeSupported



Fee//FeeGeneral//FeeVersionInfoApi



Fee//FeePublishedInformation//FeeBlockOverhead



Fee//FeePublishedInformation//FeeMaximumBlockingTime



Fee//FeePublishedInformation//FeePageOverhead





Fls

Fls//FlsGeneral//FlsAcLoadOnJobStart



Fls//FlsGeneral//FlsBaseAddress



Fls//FlsGeneral//FlsCancelApi



Fls//FlsGeneral//FlsCompareApi



Fls//FlsGeneral//FlsDevErrorDetect



Fls//FlsGeneral//FlsDriverIndex




Fls//FlsGeneral//FlsGetJobResultApi



Fls//FlsGeneral//FlsGetStatusApi



Fls//FlsGeneral//FlsSetModeApi



Fls//FlsGeneral//FlsTotalSize




IpduM

IpduM//IpduMConfig//IpduMRxPathway//IpduMRxIndication//IpduMByteOr

der


IpduM//IpduMConfig//IpduMRxPathway//IpduMRxIndication//IpduMRxDyna

micPart//IpduMOutgoingDynamicPduRef



micPart//IpduMRxSelectorValue



micPart//IpduMSegment//IpduMSegmentLength



micPart//IpduMSegment//IpduMSegmentPosition


IpduM//IpduMConfig//IpduMRxPathway//IpduMRxIndication//IpduMRxHand

leId


IpduM//IpduMConfig//IpduMRxPathway//IpduMRxIndication//IpduMRxIndi

cationPduRef


IpduM//IpduMConfig//IpduMRxPathway//IpduMRxIndication//IpduMRxStat

icPart//IpduMOutgoingStaticPduRef



icPart//IpduMSegment//IpduMSegmentLength



icPart//IpduMSegment//IpduMSegmentPosition


IpduM//IpduMConfig//IpduMRxPathway//IpduMRxIndication//IpduMSelect

orFieldPosition



orFieldPosition//IpduMSelectorFieldLength



orFieldPosition//IpduMSelectorFieldPosition


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMByteOrder


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMIPduUnuse

dAreasDefault



IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMInitialDy

namicPart


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMOutgoingP

duRef


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMSelectorF

ieldPosition



ieldPosition//IpduMSelectorFieldLength



ieldPosition//IpduMSelectorFieldPosition


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMSize


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMTxConfirm

ationPduId


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMTxConfirm

ationTimeout




IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMTxDynamic

Part//IpduMJitUpdate



Part//IpduMSegment//IpduMSegmentLength



Part//IpduMSegment//IpduMSegmentPosition



Part//IpduMTxDynamicConfirmation




Part//IpduMTxDynamicHandleId



Part//IpduMTxDynamicPduRef



IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMTxStaticP

art//IpduMJitUpdate



art//IpduMSegment//IpduMSegmentLength



art//IpduMSegment//IpduMSegmentPosition



art//IpduMTxStaticConfirmation




art//IpduMTxStaticHandleId



art//IpduMTxStaticPduRef


IpduM//IpduMConfig//IpduMTxPathway//IpduMTxRequest//IpduMTxTrigger

Mode


IpduM//IpduMGeneral//IpduMDevErrorDetect



IpduM//IpduMGeneral//IpduMStaticPartExists




IpduM//IpduMGeneral//IpduMTimerConfig//IpduMOsTimerUse


The default value is CyclicCount. This default cannot be overridden.

IpduM//IpduMPublishedInformation//IpduMRxDirectComInvocation


The default value is FALSE. This default cannot be overridden.


J1939Dcm

J1939Dcm//J1939DcmConfigSet//J1939DcmChannel//J1939DcmBusType


J1939Dcm//J1939DcmConfigSet//J1939DcmChannel//J1939DcmBusType

This parameter is a Default value. The default value is J1939DCM_J1939_NETWORK_1.


J1939Dcm//J1939DcmConfigSet//J1939DcmChannel//J1939DcmComMChannelR

ef


J1939Dcm//J1939DcmConfigSet//J1939DcmNode//J1939DcmDiagnosticMessa

geSupport//J1939DcmDiagnosticMessageSupportChannelRef



geSupport//J1939DcmDmxSupport



geSupport//J1939DcmDmxSupport


The default value is "J1939DCM_+name+""_SUPPORT""". This default cannot be overridden.


geSupport//J1939DcmRxPdu//J1939DcmRxPduId




geSupport//J1939DcmRxPdu//J1939DcmRxPduId




geSupport//J1939DcmTxPdu//J1939DcmTxPduId




geSupport//J1939DcmTxPdu//J1939DcmTxPduId



geSupport//J1939DcmTxPdu//J1939DcmTxPduRef


J1939Dcm//J1939DcmConfigSet//J1939DcmNode//J1939DcmNmNodeRef


J1939Dcm//J1939DcmConfigSet//J1939DcmNode//J1939DcmNodeRmUserRef



J1939Dcm//J1939DcmGeneral//J1939DcmCommonBufferSize



The maximum value for this parameter is 1785.

J1939/21_201603 - Section 5.10.1.1 - “Individual message packets are assigned a

sequence number of 1 to 255. This yields a maximum message size of (255 packets * 7 bytes/packet =) 1785 bytes.”

J1939Dcm//J1939DcmGeneral//J1939DcmDM1BufferSize



J1939Dcm//J1939DcmGeneral//J1939DcmDM1MaxDTCs



J1939Dcm//J1939DcmGeneral//J1939DcmDevErrorDetect



J1939Dcm//J1939DcmGeneral//J1939DcmMaxDTCsPerMainFunction




J1939Dcm//J1939DcmGeneral//J1939DcmMaxFreezeFramesPerMainFunction




J1939Nm

J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmCAMRxPdu//J1939N

mCAMRxPduId



J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmCAMTxPdu//J1939N

mCAMTxPduId



J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmComMNetworkHandl

eRef


J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmNMRxPdu//J1939Nm

NMRxPduId



J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmNMTxPdu//J1939Nm

NMTxPduId




J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmRxPdu//J1939NmRx

PduId



J1939Nm//J1939NmConfigSet//J1939NmChannel//J1939NmTxPdu//J1939NmTx

PduId



J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagemenManufa

cturerCodeAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementECUIn

sAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementFunct

ionAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementFunct

ionInsAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementIdent

ityNumberAllow



J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementIndus

tryGroupAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementSelfC

onfigAddrAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementVehic

leSystemAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNameManagementVehic

leSystemInsAllow


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeAddressChangeAl

low


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeId


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeId


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeIsExternal


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeIsExternal


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameArbitraryAd

dressCapable


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameECUInstance


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameFunction


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameFunctionIns

tance


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameIdentityNum

ber


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameIndustryGro

up


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameManufacture

rCode


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameVehicleSyst

em



J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeNameVehicleSyst

emInstance


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodePreferredAddres

s


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeStartUpDelay


J1939Nm//J1939NmConfigSet//J1939NmNode//J1939NmNodeVirtualAddress


J1939Nm//J1939NmGeneral//J1939NmCAMSupport


J1939Nm//J1939NmGeneral//J1939NmClaimedAddressStoringNvMSupport


J1939Nm//J1939NmGeneral//J1939NmDevErrorDetect



J1939Nm//J1939NmGeneral//J1939NmGeneralNumberofUnknownNameNodes



J1939Nm//J1939NmGeneral//J1939NmNameManagementSupport



J1939Rm

J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmAckQueueSize


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmAckmRxPdu//J1939

RmAckmRxPduId




RmAckmRxPduId




RmAckmRxPduRef


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmAckmTxPdu//J1939

RmAckmTxPduId


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmAckmTxPdu//J1939

RmAckmTxPduRef


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmComMNetworkHandl

eRef


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmRequestQueueSize


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmRequestTimeoutMo

nitors


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmRqstRxPdu//J1939

RmRqstRxPduId


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmRqstRxPdu//J1939

RmRqstRxPduRef


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmRqstTxPdu//J1939

RmRqstTxPduId


J1939Rm//J1939RmConfigSet//J1939RmChannel//J1939RmRqstTxPdu//J1939

RmRqstTxPduRef


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmNmNodeRef


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmNodeChannelRef



J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmComIPd

u//J1939RmComIPduPGN


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserAc

kIndication



kIndication



kPGN


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserId


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserId


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserPG

N


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserRe

questIndication


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserRe

questIndication


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserSe

ndAck



ndAck



ndRequest



ndRequest


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserTi

meoutSupervision


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserTi

meoutSupervision


J1939Rm//J1939RmConfigSet//J1939RmNode//J1939RmUser//J1939RmUserTy

pe



J1939Rm//J1939RmGeneral


J1939Rm//J1939RmGeneral//J1939RmSupportAckIndication


J1939Rm//J1939RmGeneral//J1939RmSupportAckTransmission


J1939Rm//J1939RmGeneral//J1939RmSupportRequestIndication


J1939Rm//J1939RmGeneral//J1939RmSupportRequestTransmission


J1939Rm//J1939RmGeneral//J1939RmSupportTimeoutSupervision




J1939Rm//J1939RmGeneral//J1939RmVersionInfoApi




J1939Tp

J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpETPRxCmNPd

u//J1939TpETPRxCmNPduId



J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpETPRxDtNPd

u//J1939TpETPRxDtNPduId



J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpETPTxFcNPd

u//J1939TpETPTxFcNPduTxConfId



J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxCmNPdu//

J1939TpRxCmNPduId


J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxCmNPdu//

J1939TpRxCmNPduRef


J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxDtNPdu//

J1939TpRxDtNPduId


J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxDtNPdu//

J1939TpRxDtNPduRef


J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxPg//J193

9TpRxDirectNPdu//J1939TpRxDirectNPduId




9TpRxDirectNPdu//J1939TpRxDirectNPduRef



9TpRxNSdu//J1939TpRxNSduRef



9TpRxPgDynLength



9TpRxPgPGN


J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxProtocol

Type



J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpRxSa



J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpTxFcNPdu//

J1939TpTxFcNPduRef


J1939Tp//J1939TpConfiguration//J1939TpRxChannel//J1939TpTxFcNPdu//

J1939TpTxFcNPduTxConfId


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpETPRxFcNPd

u//J1939TpETPRxFcNPduId



J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpETPRxFcNPd

u//J1939TpETPRxFcNPduId


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpETPTxCmNPd

u//J1939TpETPTxCmNPduTxConfId



J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpETPTxCmNPd

u//J1939TpETPTxCmNPduTxConfId


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpETPTxDtNPd

u//J1939TpETPTxDtNPduTxConfId



J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpRxFcNPdu//

J1939TpRxFcNPduId


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpRxFcNPdu//

J1939TpRxFcNPduRef


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxCmNPdu//

J1939TpTxCmNPduTxConfId


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxDa



J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxDtNPdu//

J1939TpTxDtNPduRef



J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxDtNPdu//

J1939TpTxDtNPduTxConfId


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxPg//J193

9TpTxDirectNPdu//J1939TpTxDirectNPduRef



9TpTxDirectNPdu//J1939TpTxDirectNPduTxConfId



9TpTxNSdu//J1939TpTxNSduId




9TpTxNSdu//J1939TpTxNSduRef



9TpTxPgDynLength



9TpTxPgPGN


J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxProtocol

Type


The default value is "". This default cannot be overridden.

J1939Tp//J1939TpConfiguration//J1939TpTxChannel//J1939TpTxSa



J1939Tp//J1939TpGeneral//J1939TpDevErrorDetect



J1939Tp//J1939TpGeneral//J1939TpETPSupport


J1939Tp//J1939TpGeneral//J1939TpMaxPacketsPerBlock


J1939Tp//J1939TpGeneral//J1939TpPacketsPerBlock



Lin

Lin//LinGeneral//LinDevErrorDetect



Lin//LinGeneral//LinIndex



Lin//LinGeneral//LinVersionInfoApi



Lin//LinGlobalConfig//LinChannel//LinChannelBaudRate


Lin//LinGlobalConfig//LinChannel//LinChannelId


Lin//LinGlobalConfig//LinChannel//LinChannelWakeupSupport



LinIf

LinIf//LinIfGeneral//LinIfCancelTransmitSupported



LinIf//LinIfGeneral//LinIfDevErrorDetect


LinIf//LinIfGeneral//LinIfMultipleDriversSupported


LinIf//LinIfGeneral//LinIfMultipleTrcvDriverSupported


LinIf//LinIfGeneral//LinIfNcOptionalRequestSupported



LinIf//LinIfGeneral//LinIfTpSupported



LinIf//LinIfGeneral//LinIfTrcvDriverSupported



LinIf//LinIfGeneral//LinIfVersionInfoApi




LinIf//LinIfGlobalConfig//LinIfChannel//LinIfChannelId


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfFrame//LinIfChecksumT

ype


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfFrame//LinIfFrameType


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfFrame//LinIfLength


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfFrame//LinIfPduDirect

ion//LinIfRxPdu//LinIfUserRxIndicationUL



ion//LinIfTxPdu//LinIfTxPduId



ion//LinIfTxPdu//LinIfUserTxUL



LinIf//LinIfGlobalConfig//LinIfChannel//LinIfFrame//LinIfPid


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfGotoSleepConfirmation

UL


The default value is LIN_SM. This default cannot be overridden.

LinIf//LinIfGlobalConfig//LinIfChannel//LinIfMaster//LinIfClusterT

imeBase


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfMaster//LinIfJitter


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfScheduleRequestConfir

mationUL



LinIf//LinIfGlobalConfig//LinIfChannel//LinIfScheduleTable//LinIfE

ntry//LinIfDelay


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfScheduleTable//LinIfE

ntry//LinIfEntryIndex


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfScheduleTable//LinIfR

esumePosition


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfScheduleTable//LinIfR

unMode


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfScheduleTable//LinIfS

cheduleTableIndex


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfSlave//LinIfConfigure

dNad


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfSlave//LinIfFunctionI

d


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfSlave//LinIfProtocolV

ersion


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfSlave//LinIfSupplierI

d


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfSlave//LinIfVariant



LinIf//LinIfGlobalConfig//LinIfChannel//LinIfStartupState


The default value is NORMAL. This default cannot be overridden.

LinIf//LinIfGlobalConfig//LinIfChannel//LinIfTransceiverDrvConfig/

/LinIfTrcvWakeupNotification


LinIf//LinIfGlobalConfig//LinIfChannel//LinIfWakeupConfirmationUL



LinIf//LinIfGlobalConfig//LinIfChannel//LinSleepFrameDelay

This parameter is a Default value. The default value is 0.01.


LinIf//LinIfGlobalConfig//LinIfChannel//LinTpScheduleChangeDiag




LinSM

LinSM//LinSMChannel//LinSMSchedule//LinSMScheduleIndex


LinSM//LinSMChannel//LinSMSleepSupport



LinSM//LinSMChannel//LinSMTransceiverPassiveMode



LinSM//LinSMChannel//LinSmNetworkIndex



LinSM//LinSMGeneral//LinSMDevErrorDetect




LinSM//LinSMGeneral//LinSMVersionInfoApi




MemIf

MemIf//MemIfGeneral//MemIfDevErrorDetect



MemIf//MemIfGeneral//MemIfNumberOfDevices



MemIf//MemIfGeneral//MemIfRbFeeUsed




Nm

Nm//NmChannelConfig


The default value is PASSIVE. This default cannot be overridden.

Nm//NmChannelConfig//NmBusType//NmStandardBusNmConfig//NmStandardB

usType


Nm//NmChannelConfig//NmChannelId


Nm//NmChannelConfig//NmChannelSleepMaster


Nm//NmChannelConfig//NmComMChannelRef


Nm//NmChannelConfig//NmShutdownDelayTimer



Nm//NmChannelConfig//NmStateReportEnabled


Nm//NmChannelConfig//NmSynchronizingNetwork


Nm//NmGlobalConfig//NmGlobalConstants//NmMultipleChannelsEnabled


Nm//NmGlobalConfig//NmGlobalConstants//NmNumberOfChannels


Nm//NmGlobalConfig//NmGlobalConstants//NmRemoteSleepCancelCallback


Nm//NmGlobalConfig//NmGlobalConstants//NmRemoteSleepIndCallback


Nm//NmGlobalConfig//NmGlobalConstants//NmRxCallbackHeader

This parameter is a Default value. The default value is "".


Nm//NmGlobalConfig//NmGlobalConstants//NmRxIndicationCallback

This parameter is a Default value. The default value is "".


Nm//NmGlobalConfig//NmGlobalConstants//NmStateChangeIndCallback


The default value is "".


Nm//NmGlobalConfig//NmGlobalFeatures//NmBusSynchronizationEnabled



Nm//NmGlobalConfig//NmGlobalFeatures//NmComControlEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmComUserDataSupport


Nm//NmGlobalConfig//NmGlobalFeatures//NmCoordinatorSupportEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmNodeDetectionEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmNodeIdEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmPassiveModeEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmPduRxIndicationEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmRemoteSleepIndEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmRepeatMsgIndEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmStateChangeIndEnabled


Nm//NmGlobalConfig//NmGlobalFeatures//NmUserDataEnabled


Nm//NmGlobalConfig//NmGlobalProperties//NmCycletimeMainFunction


Nm//NmGlobalConfig//NmGlobalProperties//NmDevErrorDetect




NvM

NvM//NvMBlockDescriptor//NvMBlockCrcType


The default value is NVM_CRC16. The “algo.properties” file can override this default.

NvM//NvMBlockDescriptor//NvMBlockJobPriority








NvM//NvMBlockDescriptor//NvMBlockManagementType


The default value is NVM_BLOCK_NATIVE.


NvM//NvMBlockDescriptor//NvMBlockUseCrc



NvM//NvMBlockDescriptor//NvMBlockUseSyncMechanism



NvM//NvMBlockDescriptor//NvMBlockWriteProt


NvM//NvMBlockDescriptor//NvMBlockWriteProt




NvM//NvMBlockDescriptor//NvMCalcRamBlockCrc



NvM//NvMBlockDescriptor//NvMInitBlockCallback


The default value is NULL_PTR. The “algo.properties” file can override this default.

NvM//NvMBlockDescriptor//NvMMaxNumOfReadRetries



NvM//NvMBlockDescriptor//NvMMaxNumOfWriteRetries





NvM//NvMBlockDescriptor//NvMNvBlockLength


NvM//NvMBlockDescriptor//NvMNvBlockLength



NvM//NvMBlockDescriptor//NvMNvBlockNum



NvM//NvMBlockDescriptor//NvMNvramDeviceId




NvM//NvMBlockDescriptor//NvMRamBlockDataAddress


NvM//NvMBlockDescriptor//NvMRamBlockDataAddress


The default value is null. The “algo.properties” file can override this default.

NvM//NvMBlockDescriptor//NvMRbBlockPersistentId

This parameter is a Default value. The default value is null.


NvM//NvMBlockDescriptor//NvMRbGenRteAdminPort



NvM//NvMBlockDescriptor//NvMRbGenRteServicePort


The default value is null.


NvM//NvMBlockDescriptor//NvMRbResistantToLayoutRemoval



NvM//NvMBlockDescriptor//NvMReadRamBlockFromNvCallback



NvM//NvMBlockDescriptor//NvMResistantToChangedSw





The default value is null.





NvM//NvMBlockDescriptor//NvMRomBlockDataAddress



NvM//NvMBlockDescriptor//NvMRomBlockNum



NvM//NvMBlockDescriptor//NvMSelectBlockForReadAll


NvM//NvMBlockDescriptor//NvMSelectBlockForReadAll



NvM//NvMBlockDescriptor//NvMSelectBlockForWriteAll


NvM//NvMBlockDescriptor//NvMSelectBlockForWriteAll



NvM//NvMBlockDescriptor//NvMSingleBlockCallback



NvM//NvMBlockDescriptor//NvMStaticBlockIDCheck




NvM//NvMBlockDescriptor//NvMWriteBlockOnce


NvM//NvMBlockDescriptor//NvMWriteBlockOnce



NvM//NvMBlockDescriptor//NvMWriteVerification


NvM//NvMBlockDescriptor//NvMWriteVerification





NvM//NvMBlockDescriptor//NvMWriteVerificationDataSize



NvM//NvMCommon//NvMApiConfigClass


The default value is NVM_API_CONFIG_CLASS_3. The “algo.properties” file can override this default.

NvM//NvMCommon//NvMBswMMultiBlockJobStatusInformation



NvM//NvMCommon//NvMCompiledConfigId



NvM//NvMCommon//NvMCrcNumOfBytes




NvM//NvMCommon//NvMDevErrorDetect



NvM//NvMCommon//NvMDrvModeSwitch



NvM//NvMCommon//NvMDynamicConfiguration



NvM//NvMCommon//NvMJobPrioritization



NvM//NvMCommon//NvMMultiBlockCallback

This parameter is a Default value. The default value is NULL_PTR.


NvM//NvMCommon//NvMPollingMode


The default value is TRUE.



NvM//NvMCommon//NvMSetRamBlockStatusApi



NvM//NvMCommon//NvMSizeStandardJobQueue




Options

Options//CanIfFormat



PduR

PduR//PduRBswModules//PduRBswModuleRef


PduR//PduRBswModules//PduRCancelReceive


PduR//PduRBswModules//PduRCancelTransmit


PduR//PduRBswModules//PduRChangeParameterRequestApi


PduR//PduRBswModules//PduRCommunicationInterface


PduR//PduRBswModules//PduRLowerModule


PduR//PduRBswModules//PduRRetransmission


PduR//PduRBswModules//PduRTransportProtocol


PduR//PduRBswModules//PduRTriggertransmit


PduR//PduRBswModules//PduRTxConfirmation


PduR//PduRBswModules//PduRUpperModule


PduR//PduRBswModules//PduRUseTag


PduR//PduRGeneral//PduRCanTpChangeParameterRequestApi



PduR//PduRGeneral//PduRDevErrorDetect



PduR//PduRGeneral//PduRFifoTxBufferSupport



PduR//PduRGeneral//PduRIFGatewayOperation



PduR//PduRGeneral//PduRMemorySize





PduR//PduRGeneral//PduRMinimumRoutingLoRxPduId



PduR//PduRGeneral//PduRMinimumRoutingLoTxPduId



PduR//PduRGeneral//PduRMinimumRoutingUpRxPduId



PduR//PduRGeneral//PduRMinimumRoutingUpTxPduId



PduR//PduRGeneral//PduRMulticastFromIfSupport




PduR//PduRGeneral//PduRMulticastToIfSupport



PduR//PduRGeneral//PduRMulticastToTpSupport



PduR//PduRGeneral//PduRSbTxBufferSupport



PduR//PduRGeneral//PduRTPGatewayOperation



PduR//PduRGeneral//PduRVersionInfoApi



PduR//PduRGeneral//PduRZeroCostOperation





PduR//PduRRoutingTables//PduRConfigurationId



PduR//PduRRoutingTables//PduRRoutingTable//PduRRoutingPath//PduRDe

stPdu//PduRDefaultValue



stPdu//PduRDestPduHandleId



stPdu//PduRDestTxBufferRef



stPdu//PduRTransmissionConfirmation


PduR//PduRRoutingTables//PduRRoutingTable//PduRRoutingPath//PduRSr

cPdu//PduRSourcePduHandleId



4.5.3 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 specified the mailboxes will be ordered alphabetically according to the following rule with

a comma-separated list of sorting criteria:

MbSortingPref=criteria1, criteria2,…

The criteria can be one of:

canHandleType

canAddressingMode

direction

controllerName

mask

The ordering for a criteria will be reversed by appending the optional “~rev” the desired

criteria.

For example:

MbSortingPref=direction,controllerName~rev,canHandleType

Note: if a criteria is specified to be sorted both forwards and reversed then the behavior is

undefined.

4.5.4 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}

Where SHORT-NAME is the short name of the Can Controller being configured.

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.

o 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

o If either the remaining number of Standard or Extended messages are smaller than ½

the remaining mailboxes then these are assigned one Mailbox each and the other

messages packed.

o If there are more Standard and Extended messages than ½ of the remaining

Mailboxes then the Standard Mailboxes are packed into ½ the remaining Mailboxes

and the Extended in the remaining half.


4.6. BSW Code Generation

CodeGen, the RTA-BSW Code Generation tool takes a BSW configuration and generates

source code from it.

There are two ways to activate CodeGen:

Clicking the toolbar icon, , which will run an existing configuration, or create a

default if one cannot be found.

Creating a new “run configuration” (see Screenshot 5). This gives you the ability to

configure the code generation process.

In the second case, click the arrow next to the “play” button and select “RUN

CONFIGURATIONS…”

Screenshot 5: RTA-BSW Run Configuration menu

This will open the run configuration menu (Screenshot 6), the sections of this GUI are as

follows (numbers marked in red on Screenshot 6):

1. List of run configuration instances: each item listed here is a configuration; you could have a run configuration per project, or create custom configurations for

different use cases. (e.g. Validate only and only run the Com module)

2. Select RTA-BSW: presents a list of installed RTA-BSW versions and prompts for a selection, this will control the available modules (5) as long as a valid project is

selected.

3. Select Project: prompts for a selection of a workspace project. If this is a valid AUTOSAR project and an RTA-BSW version has been selected, then the list of

modules (5) will be populated with available modules.

4. Select Output Path: by default the path will be set to

“{ProjectPath}/src/BSW/Gen”, but can be set to any directory, the process will

then organise the generated files by module in the selected directory

5. Module List: this contains the list of available modules for generation/validation. This is populated by seeing which modules have been configured in the selected

project and comparing that to the available modules in the selected RTA-BSW. You

can then turn a module or stack on/off by clicking the check button. Note: unlicensed stacks will be greyed out.

6. Miscellaneous Options: contains other options for controlling the process such as

turning code generation off (validate only) or instruct the process to not produce SWCD ARXML (to avoid overwriting manual configuration)


Screenshot 6: Run Configuration options

As CodeGen runs, it places the source code (.c/.h) implementation of the AUTOSAR BSW

system configured by the above process into the specified output directory.


5 ETAS Contact Addresses

5.1. ETAS HQ

ETAS GmbH

Borsigstraße 14 Phone: +49 711 3423-0

70469 Stuttgart Fax: +49 711 3423-2106

Germany WWW: www.etas.com

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

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

The command line that results in an error message.

The version of the ETAS tools you are using.

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

http://www.etas.com/en/hotlines.php

mailto:[email protected]

ETAS Index


Index

A

Architecture, 9, 10

AUTOSAR Architecture, 9, 10

Interfaces, 9, 18

Methodology, 9, 15 Motivation, 9

AUTOSAR Interface, 19

B

BSW Interactions, 13 BSW Module Description, 5, 18, 23

BSW Module Type Complex Device Driver, 12, 15

Driver, 12

Handler, 12 Interface, 11

Library, 12 Manager, 12

BSW Stack, 12

C

Communication Cluster, 5

Controller, 5

Complex Device Driver (BSW Module Type), 12

D

DBC

Import, 23

Driver (BSW Module Type), 12

E

ECU Abstraction Layer, 11

ECU Configuration Description, 18

ECU Configuration Parameter Definition, 19 ECU Extract, 18

H

Handler (BSW Module Type), 12

Hardware Layer, 11

I

Interactions

BSW, 13 Interface (BSW Module Type), 11

Interfaces, 9, 18

ISOLAR-A Import, 23

L

Layered SW Architecture, 5, 10, 12

Library (BSW Module Type), 12

M

Manager (BSW Module Type), 12

MCAL, 11

Methodology, 9, 15 Microcontroller Abstraction Layer, 11

Multi-core, 20

P

Proxy SWC, 21, 26

R

RTA-BSW

Configuration (ConfGen), 23, 24

Generation (CodeGen), 23, 94 SW Versions, 4

S

Safety Notice, 4

Service Layer, 11 Stack (BSW), 5, 12

Standardized AUTOSAR Interface, 19 Standardized Interface, 19

SWC Description, 18

System Description, 17, 18, 23 DBC Import, 23

ETAS Index


W

Workflow, 22

ETAS


RTA-BSW User Guide - etas.com · RTA-J1939 supports diagnostics using J1939 protocol ......

Documents

Transcript of RTA-BSW User Guide - etas.com · RTA-J1939 supports diagnostics using J1939 protocol ......