RTA Knowledge Base

Skip to end of banner
Go to start of banner

Learning about com configuration in AUTOSAR BSW

Value Statement

Overview

This page is not strictly about the complete configuration of the AUTOSAR BSW communcation modules. The current page aims to improve the knowledge about:

  • How to define communication messages with a communication matrix;
  • How to configure the BSW communication modules, in order to send/Receive specific messages;
  • How mapping among frame, pdu and signal work;
  • How RTE is able to interface the Com and the A-SWC;
  • How an A-SWC can exchange messages with lower layers;

The selected communication protocol is the CAN. Therefore, all infromation in the current page will be compliant to AUTOSAR specification about CAN communication. 


Configuration generation

ISOLAR-AB allows the import of DBC files. DBC means DataBase CAN, i.e. a specific format that contains information about:

  1. Which are the communication nodes (ECUs) in a communication system;
  2. Messages source, destination(s) and which information it contains;
  3. Mapping between messages and signals;

DBC default message is considered as a CAN frame.

Once DBC is imported, it is possible to use the embedded confiGen tool to generate the BSW configuration.

The DBC file importer allows you to choose which communication node (i.e. ECU) and which related messages shall be imported in your ISOLAR project. If the importing process will be successful, in ISOLAR graphic view, under system , it will be possible to browse through messages, signals and ECUs.

The configuration generator or confiGen, it is represented by symbol E  in the command panel. It allows to choose the BSW generator to use and which ECU shall be generated. Several times, the generated configuration is not completed and it requires changes according to the specifi use case.

The next image represents the mapping between the communication entities.

The DBC files have an own syntax and semantic to store information. The keywords are reported in bold between parenthesis:

  1. Version ( VERSION )
  2. New Symbols (NS_): Define all symbols that are used in the file. Let's note: It is very important to define under NS, only the symbols that will be actually used in the next. If a symbol is defined but it won't be used, the DBC importer might show an error message as "DBC file not valid";
  3. Bit Timing (BS_): very rare. In our case, the symbol is just defined without parameter;
  4. Communication nodes (BU_): ECU in the communication;
  5. Messages (BO_): messages that builds the communication. The definition of a new message might require its definition in the MCAL: in this case, it is necessary to use the MCAL mailbox;
    1. Signals (SG_): each message shall contain at least one signal.
  6. Attributes, comments and types definition for signals;
  7. Generic/Globals Attributes, definitions, types, values and categories about signals and messages;


CAN message description

Basically a CAN message contains two parts:

  • CAN Identifier or CANId;
  • Payload;

There are actually two different versions about CAN. This impacts the decoding of the message. In particular, the impacting field is the CAN Identifier that can be on 11 bits, in the case of regular type, or 29 bits in case of extended type. Instead, The payload length is up to 64 bits. The maximum length of a CAN message is then 96 bits or 12 bytes.

The mandatory attributes of a CAN message are the following, plus the identifier:

  • message length (generally in Bytes);
  • The source of the message;
  • the destination of the message;

From CAN message to DBC file

Let's consider a message as follows (extended CAN):


0C F0 04 00 FF FF FF 68 13 22 FF FF


The CAN identifier is represented by 29 in the 32 most significant bits (less significant bits are on the right side). So a CAN identifier can be in range 0x0 and 0x1FFFFFFF (536'870'911).

The remaining part of the message contains the signals .

A signal description shall contain:

  1. Signal name;
  2. Signal starting bit (the zero point is the first bit on left of the payload)
  3. Signal encoding
    1. 0 for BIG ENDIAN (encoding starts from the most significant bits/byte with respect to the position order)
    2. 1 for LITTLE ENDIAN (encoding starts from the less significant bits/byte with respect to the position order)
  4. Data sign (signed or unsigned)
  5. Signal value computation (the most common is the LINEAR, 1 and 0 are provided for boolean)
  6. Signal Lower and Upper Boundary
  7. Measuring unit for value
  8. Destination Node for the signal

All detailed information about the description of the messages and related signals in a DBC file are at the following links:

Signal Management at Application and RTE Layer

Usually at application layer the communication happens thanks to the Virtual Functional Bus, by definition of ports, interfaces and data elements. when a real system is configured, if two application software components are mapped in different ECUs, the message sending will happen on the Bus System. The data contained in the message are still read or written by software component ports, but they will go through the entire AUTOSAR stack. Therefore, an Application Software component requires the following elements :

  1. Define a port with the related port-interface and data elements (it shall be compliant with the nature of the signal)
    1. There are no differences for Tx and Rx signal at this point, therefore components can contain definition for Tx and Rx ports;
  2. Define a runnable and a related function to use that port;
  3. Define an event to specify the runnable interaction with the RTE;




Going down in the layered architecture, the first signal transformation is in the interfacing between RTE and Com. To generate the RTE interfaces between BSW and ASW, it is necessary to extract from System description an ECU specific implementation one. This is the ECU Extract.

Mainly, the system description contains the Application Software Component Mapping in ECUs, and the System Data Mapping where the application software component port interfaces are associated to all signal info (as specified in the system view), PDU and frame that are defined for the original messages. Look the following images:



NOTE: COM module (BSW) actually defines the PDU and the Signals as configuration containers (objects). This means that all configurations and calibrations aspects about a single signals are unknown to the application layer. The main configuration containers in Com are: 1) Com/ConfigSet/comIPdus that contains a reference to the 2) Com/ConfigSet/ComSignal. This last still contains the reference to the signal mapping how it has been defined by the system template (EcuC module description).

Signal and Messages Management at BSW level

AUTOSAR BSW layer contains the Communication stack that spreads as a vertical slice among Service, ECU abstraction and Microcontroller abstraction sub-layers. Besides, there is a Communication manager module in System service. All these BSW modules shall be configured in order to allow the information exchanges on a bus system and, in order to forward information to the application layer. For ComM the configSet directly generates an Application Service Component.

In the communication services, the main modules that are directly "connected" to the RTE are the Com and the Dcm. Basic aspects are the dependencies among BSW modules themselves and their ones with their BSW Managers.

The communication Services can be strongly dependent from network management. For example, the management of Partial Networking will require the configuration of more modules than a classic communication. The same story is for the management of the LIN network. A quick view about referencing dependencies are in the next subsections.

Com Notes

The Com modules description appears as follows:

The description of a ComPdu appears in this way





  1. ComPduIdRef : reference to the structure definition of the Pdu in the EcuC (EcuC/ConfigSet/Pdu). This is like a global definition that can be inherited by all others modules in the Com stack to describe the Pdus.
  2. ComIPduGroupRef: reference to the IPduGroup. This is a container reference to Com/ConfigSet (look Com description image). The Pdus group are actually used for Partial Networking management and they are very useful at that scope.
  3. ComIPduSignalGroupRef : reference to Com/ConfigSet/ComSignalGroup. If a ComIPdu has this reference different from NULL, then it will have reference to ComIPduSignal to NULL. In this case the ComNotification will provide a notification for each Com configured I-PDu with reference set to the signal group.
  4. ComIPduSignalRef: reference to the signal in the current Pdu. Each PDU can contain more signals. The signal are described within Com/ConfigSet/ComSignal


The ComSignal configuration container is very interesting at the scope of information exchanges between Application layer and BSW. A signal description will appear very similar:

The parameter ComNotification can be set at the scope to generate a callback. The callback will provide information of communication status. The ComNotification can be configured for the following objects:

  • Tx side:
    • Signals;
    • Signals groups
    • I-PDUs
  • Rx side:
    • Signals;
    • Signals group;
    • I-PDUs

Callback at Tx side

  • DECLARATION: Com_Cbk.h
  • DEFINITION: User scope
  • CALL: void Com_Cfg::Com_TxNotify_<SignalName>(void)

Callback at Rx side

  • DECLARATION:
    • Com_Cbk.h: declaration of callback that is configured in ComNotification description;
    • Rte_Cbk.h:   declaration of callback with static name Rte_Cbk_<SignalName>
  • DEFINITION: done by RTA-RTE generator in Rte.c according to declaration in Rte_Cbk.h
  • CALL:
    • Within user function that implements the declaration of prototype configured in ComNotification (User scope - Useful when callback shall be called by an Application Software Component by-passing RTE)
      • If the callback name is the same of RTE generated one, the implementation is common
    • Static function pointer is automatically allocated by RTA-BSW generator in structure type Com_Prv_xTxSigCfg_tst (Com_Cfg.c resource)

ComM Notes

The Com Manager is a System Service module. It is basically responsible for the Mode Management at communication scope. It is the main module to address in the scope of the Partial Networking Management. In fact the Partial Networking support is addressed in ComM by configuration parameters. The container Pnc (Partial Networking Cluster - Don't make confusion with RTA-SUM_PNC = Partial Networking Coordinator!) describes all configuration aspects about the Partial Networking.

Let's note that the Partial Networking is purely "logical" at higher levels, including Service one. At service layers, the context of Partial Network is just an aggregation of:

  1. Ecu that communicates on a Channel;
  2. Pdus on that Channel;

In practise, the Partial Networks are maps between: 1) a CAN channel on which an ECU can communicate and 2) enabled/disabled PDU that can run on that specific channel, in a specific moment. Enable a Partial Networks, means to allow the Transmission/Reception of mapped PDU Groups on that Channel. This mapping is in each ECU of a communication system. The enabling and disabling modes require the Services of the Mode Managers as the ComM, BswM, EcuM, etc....

Then, the support of Partial Networking requires the configuration of the Partial Network Cluster and the configuration of the Network managements modules, otherwise no BSW code is going to be successfully generated. The following graph reports the main dependenices among the ComM and others BSW modes:

The Partial Network cluster works as a Finite State Machine, in order to manage the communication modes. Each Partial Network cluster is an independent Finite State Machine that works for specific ComMUser(s) . ComMUser is the communication object for tracking the communication in an ECU partition (not used in actual RIP but it can be used for Safety concepts). If the Partial Network Cluster is enable, the nodes in the system communication will use the NM frames to exchange information. The main ones are request and release. Each Partial Network Cluster will use a dedicated bit position in the NM for itself.

The context diagram for the Pnc is something as follows:


Notes on mailbox

The DBC just represents a system description for the communication. This description is enough only for the generation of configuration in Service Layer. Let's remember that a message is originally a physical information. To transform it in a logic information, the message shall be defined in the MCAL (Driver) and in the CanIf (Interfaces). The definition is possible thanks to the mailboxes. The mailboxes are defined for the MCAL and it shall be reported in the configuration of the CanIf within ISOLAR project.

The mailboxes are container and they are able to group several messages. The grouping happens thanks to the CAN message identifier: if the CAN message Identifier passes through a filtering value that is proper for the specific mailbox, then it will be grouped in the same mailbox. Of course, the definition of the filtering value shall match the type of the CAN: therefore it shall be on 29 bits for extended version and 11 for the normal one. Each mailbox can contain one or more message.

The mailbox can be done by tool TresOS 16. This tool allows the graphical definition of masks instead to work manually on them. Let's remember that mailbox are Hardware Objects, therefore they are limited to Hardware resources of the target system. Each information about these boundaries shall be derived from target systems user manuals. TresOS can require dedicated compiler for each kind of target on which it will be used.

What about ISOLAR: The configuration of the mailbox shall be reported in ISOLAR project too. This because there are several references that are used by other modules, for instance the Interfacing module in the EAL (ECU Abstraction Layer).  If you look in the configuration description of the Can in ISOLAR, you can note the following information:

The CanHardwareObject container makes reference to a mailbox. The sub-container CanHwFilter contains all information about the filtering mechanism for the mailbox. The two parameters are:

  1. CanHwFilterCode: Specifies the identifiers range that pass the hardware filter. The incoming messages shall match specific bit positions of this value;
  2. CanHwFilterMask: Defines mask for HW-based filtering of CAN identifiers. The mask addresses with a 1 the bit-positions of the incoming message that care, otherwise 0 for ones are don't care.

An example of filtering is in the following figure:

The mailbox as HW obects are referenced by the configuration set of the CanIf as follows:

That reference reports to the definition of the mailbox hardware objects where Filter code and Filter mask values are contained. Going deeper in the configuration strucuture, it is possible to find a list of all possible received messages according to the mailbox configuration:


  • No labels