AUTOSAR: Signal Communication — Part 1
1. Goals of the series
The goal of this article series is to explain the underlying concepts of Signal-Based Communication in the AUTOSAR world, but without going deep into AUTOSAR itself. When I worked on a Signal Based Communication project for a tier 2 automotive supplier, I realized that my knowledge of AUTOSAR did not help me much to have a smooth start in the project. Rather all along it was a rough journey where I learned the details of vehicle communication by wading through a mess of documents both from within the organization and outside it.
Most of the time I had scattered pieces of information that I had to work with without any knowledge of how it was related to another piece of information and how it could affect something else as the information traverses through the layers of AUTOSAR software components. With the series of articles, I attempt to bring the very low-level information related to the vehicle’s signal-based communication concept.
The target audience for this article series is Automotive software developers who have to work with vehicle communication within the Classic AUTOSAR Framework and are required to model or work with software components that need to parse the signal data and communicate it to say an application software. I wish the readers a happy reading time.
2. Introduction
AUTOSAR (Automotive Open System Architecture) is a standardization initiative of leading automotive manufacturers and suppliers that was founded in the autumn of 2003. The goal is the development of a reference architecture for ECU software that can manage the growing complexity of ECUs in modern vehicles.
Basic elements of the AUTOSAR architecture are, among others, formally defined software components (SWC) with clearly specified interfaces to the basic software (BSW) that in turn provide fundamental standard services, such as bus communication, memory management, IO-access, system, and diagnostic services. Another basic element is the runtime environment RTE that connects the SWCs with the BSW. The most high-level layered architectural diagram that one may have come across is the one below.
Through such a standard, the intention is that the developers in the Automotive software community compete on the application layer while standardizing the hardware and the interfaces to it thereby eliminating huge costs to develop hardware (ECUs for e.g) and later an application software that can function on top of the new hardware. From the perspective of a vehicle owner, she/he can choose to replace the ECU from a vendor of her/his choice and not be restricted to the vendor specified by the vehicle company.
The BSW layer in green color is further subdivided into 4 important layered components, viz Service Layer, ECU Abstraction Layer (ECUAL), Microcontroller Abstraction Layer (MCAL), and Complex Drivers layer
Each layer within the BSW further contains standardized software components which serve critical functionalities for the safe operation of the vehicle. Such components, starting from the topmost layer interact with the hardware either directly or through the channels provided by layers below it.
3. Communication Architecture within BSW
The focus of my article is Signal Based Communication in AUTOSAR whose related components of the BSW layer are highlighted in the black box in the image above. A closer look at this layer can be seen in the image below.
Thus from the communication point of view, the drivers and interfaces associated with several communication mechanisms ( or bus systems in automotive lingo) in AUTOSAR, viz Ethernet, FlexRay, CAN, and LIN can be seen in the image above. All of these pass data (signals here) to the Basic Software Component called PDU Router and from here the signal is again is passed through the AUTOSAR COM and finally to the RTE from where the signals are sent to the concerned application software within the application layer.
4. Bus Systems in Automotive
Without going into historical details of how the communication protocols in vehicles evolved over the decades, I’d like to highlight important bus systems that are widely used in vehicle communication and are supported by AUTOSAR Standard.
- CAN or Controller Area Network: This busy system developed by the Robert Bosch GmbH in the early eighties and was internationally standardized (ISO 11898) in 1994. CAN Bus system supports a data rate of up to 1 Mbit/s.
- CAN FD or Controller Area Network Flexible Data Rate: This is a further development of the CAN bus system. It supports higher data rates (max. 8 Mbit/s) and up to 64 data bytes.
- LIN or Local Interconnect Network: has been developed especially for the cost-efficient communication of intelligent sensors and actuators in automobiles. LIN bus system characteristics: master/slave architecture (Single master and up to 16 slaves), Guaranteed latency times, Variable length of the data frame, Configuration flexibility, and many more.
- FlexRay: This bus system has been designed as a bus system for all security-relevant applications as well as for transmission of a large amount of data in automobiles. FlexRay bus system characteristics include data transmission up to 10 Mbit/s, redundant implementation of all networks, deterministic transmission behavior.
- Ethernet: This is a term we all know and has been time-proof and due to the inherent nature of its architecture, it has been easily adapted to meet the needs of vehicle communication. For Automotive applications, the specific standard of Ethernet, IEEE802.3 is used. Their advantages lie in their large bandwidth, scalability of networks, and the use of proven communication protocols.
Conclusion
I hope the readers enjoyed the articles. In the next article in the series, I’ll go high-level details of how communication is organized between different ECUs and how they relate to the AUTOSAR world by means of AUTOSAR System Description which can be thought of as a system model, the information in a model that pertains to vehicle communication. Stay tuned!
