What is AUTOSAR Communication Stack (ComStack)? Introduction to CAN Communication Stack
This blog is part of a series of articles that will help you understand AUTOSAR specifications better.
This is part of the sincere efforts of our AUTOSAR development team, based in Bangalore, India, to share knowledge with the community of AUTOSAR developers and automotive OEMS and Suppliers.
In this blog we will focus on what is AUTOSAR Communication Stack (COmStack). We will also share an introduction to specifications of CAN based communication stack.
Definition of AUTOSAR Communication Stack (ComStack):
As shown in the diagram below, AUTOSAR has a layered architecture. The AUTOSAR development process is implemented across the following software layers (bottom-to-top):
- MCAL (Microcontroller Abstraction Layer)
- Basic Software Layer (BSW)
- Run-Time Environment (RTE)
- Application Layer
In this AUTOSAR layered architecture, Communication Stack or ComStack facilitates communication. Hence ComStack can be defined as a software stack that provides communication services to the Basic Software Modules and Application Layer or Application Software.
(Source – RTC Magazine)
Learn more details about the AUTOSAR ComStack (Communication Stack)
Below is the depiction of a generic AUTOSAR Communication Stack
(Source – autosar.org )
Depending on the Bus Type of the in-vehicle network (such as CAN, LIN, Flex-Ray, MOST), implementation of the communication stack is executed. For example, if the underlying Bus type of the in-vehicle network is CAN, then CAN implementation of the communication stack is executed.
We will first focus on generic ComStack and then introduce you to the specification of CAN Communication Stack in AUTOSAR.
A generic Communication Stack in AUTOSAR layered architecture is a set of following software modules:
- AUTOSAR COM – part of the Services Layer
- Bus Specific Interface Modules – part of the ECU Abstraction Layer (For example -CanIf, LinIf, FrIf)
- External Bus Drivers – part of the ECU Abstraction Layer (For example – External drivers likeCanDrv, LinDrv, FlexrayDrv)
- Internal Bus Drivers – part of the AUTOSAR MCAL (For example – CanDrv, LinDrv, FrDrv)
Introduction to CAN Communication Stack in AUTOSAR :
The following diagram depicts the CAN based Communication Stack (ComStack):
List of different modules of the CAN Comunication Stack ComStack:
- COM(Services Layer)
- PDU Router(Services layer)
- CAN State Manager(Services Layer)
- CAN Network Manager(Services Layer)
- CAN Transport Protocol(Services Layer)
- CAN Interface(ECU Abstraction Layer)
- External CAN Driver(ECU Abstraction Layer)
- CAN Driver(MCAL Layer)
(Source – autosar.org)
Some of the modules of the Communication Stack perform functions related to vehicle diagnostics, PDU multiplexing and CAN Transceiver.
Learn more details about the CAN ComStack software modules:
CAN Stack BSW Modules:
- AUTOSAR COM: AUTOSAR COM is a module between the RTE and the PDU Router. It is responsible for providing Signal level access to the application layer and PDU level access to the lower layers independent of the protocol.
It packs the signals to a PDU at the transmitter and unpacks the received PDU to provide signal level access to the application at the receiver. At the PDU level, COM is responsible for grouping of the PDUs, starting and stopping of the PDU groups.
- PDU Router: PDU Router is a module responsible for routing the PDU to the respective Bus Specific Interface modules.
Above the PduR module all the PDUs are protocol independent, and below PduR all the PDUs are routed to the protocol specific modules. PduR is also responsible for PDU level gatewaying i.e. transmitting the received PDU from one Bus Specific Interface module to other Bus Specific Interface module.
Gatewaying can also be done when a PDU is to be routed from one controller to another over the same protocol.
- Can TP: The basic services offered by the Can TP module are segmentation of messages which have a payload of more than 8 bytes, transmission of the messages with flow control and reassembling the segmented messages at the receiver.
- Can Interface: CAN Interface(CanIf) is a module in the ECU Abstraction Layer which is responsible for services like Transmit Request, Transmit Confirmation, Reception Indication, Controller mode control and PDU mode control.
- Can State Manager (CanSM): This module shall implement the control flow for the respective bus. The CAN State Manager (CanSM) is a member of the Communication Service Layer.
- CanNm: The AUTOSAR CAN Network Management is a hardware independent protocol tools that can only be used on CAN network.
Its main purpose is to coordinate the transition between normal operation and bus-sleep mode of the network. The CAN Network Management (CanNm) function provides an adaptation between network Management Interface (NmIf) and CAN Interface (CanIf) module.
- Can Driver (CanDrv): This module is a part of the MCAL layer and provides hardware access to the upper layer services and a hardware-independent interface to the upper layers. CanIf is the only module that can access the CAN driver.
It interacts with the Communication Hardware Abstraction Layer and the System Service Layer.
Related posts on AUTOSAR software development
- AUTOSAR Microcontroller Abstraction Layer (MCAL): Learn about the fundamentals of the MCAL layer from our AUTOSAR team. Know more about the various device drivers and the layered architecture of the AUTOSAR MCAL. And get the details about how the Microcontroller Abstraction Layer (MCAL) works
- AUTOSAR Memory Stack (MemStack): Get introduced to the various software modules of AUTOSAR Memory Stack (MemStack) that provide basic memory management services to the upper layers. Our AUTOSAR development team shares the basics of AUTOSAR 3.0 and 4.0
- AUTOSAR Development partnership: Find out what is AUTOmotive Open System Architecture (AUTOSAR) development partnership and why OEMs, Tier-I suppliers, Semiconductor Vendors and Embedded hardware and software service providers collaborated to form this global partnership
What is AUTOSAR development partnership?
AUTOSAR, which stands for AUTomotive Open System Architecture, is a partnership at a global scale between Automotive OEMs, Tier-I suppliers, semiconductor vendors, embedded hardware design houses and embedded software engineering service providers
This worldwide strong partnership has its roots in one common belief – “Cooperate on standards, compete on implementation” as mentioned in the AUTOSAR charter
(Source – autosar.org)
Interested in learning the basics of AUTOSAR, read this blog about What is AUTOSAR MCAL (Microcontroller Abstraction Layer)
ASK OUR EXPERTS
Car HUD (Heads-up Display)
Go-to-market in 6 months with our automotive grade hardware and software design
Automotive Control Units
Electronic Control Units (ECU) development services for Body Control Modules (BCM), Powertrain, Chassis and Infotainment
AUTOSAR Software Services
AUTOSAR MCAL development, RTE and BSW integration, Application Layer development, Tools configuration and code generation
CUSTOMER SUCCESS STORIES
Find out how J1939 stack resolved on-chip memory issue for an Automotive Tier-I supplier
Modular architecture re-design across fleet management product lines - GPS fleet security, vehicle and trailer tracking
Design and development – Sensor Networks, Custom IoT gateway, Cloud and Mobile App