Hey guys, welcome back to another interesting chapter of Learn Autosar Basics. Today, we'll be learning about what is Autosar. Maybe before jumping to the specifications of Autosar, let's understand why did we need it at the first place.
Let's begin. In a generic car, we have about 100 electronic control units or ECUs. For example, we have airbag control unit, body control unit, door control unit, ABS and many more. These ECUs are made up of sensors, actuators and microcontrollers. In a complex system such as cars, we need to connect these ECUs via some communication link so that they can share the data they need.
Microcontrollers are the brain of any ECU. All the storage, computation and communication of data happens in the microcontroller. Controllers have specific set of internal registers, interrupts, memory and I-U interfaces which defines its architecture.
Once we have clear understanding of the system and requirements, next step is to write the software and flash it on the ECU. The software is written in any high-level language and then compiled and linked to a binary code, which in turn is flashed into the microcontroller using a programming device. Okay, now let's take an example of Automotive Company X. Company X is working on a body control unit project. Let's say they choose RL78 controller for this project. They write the software, flashes it and it works well.
This software was designed keeping RL78 controller architecture in mind. Let's say after some years, renaissance decides to increase the price of the rs-78 controller. This cost is too high for company x and hence they decide to shift to a new controller.
Now suppose they choose sd chorus in this case which has totally different architecture than the previous one. The previous software was so much dependent on the controller specifics that they cannot reuse it anymore. Hence, this time, Company X decides to write the software in two parts, BSW layer, which controls the hardware and provides system functionalities, and ASW layer, where the application for BCM is written. Okay, now when they test the software in a standalone mode, it works. But when they test the software with other modules in the car, it doesn't work anymore due to some compatibility issues.
So basically this shows how important a hardware and software portability is. A small change in architecture requires whole system to be redesigned. This rework and lack of coordination between tier 1 suppliers and OEMs in 2003 gave birth to a standard called Automotive Open System Architecture or very well known as AUTOSAR.
The motivation behind AUTOSAR was to increase the flexibility for product modification and to leverage the scalability of solutions across issues. It also motivated reliability and quality of the software and safety requirements. More details about AUTOSAR can be found on AUTOSAR.org website.
Here is a list of core partners in AUTOSAR consortium. We have BMW, Bosch, Continental, Daimler, Ford, General Motors, PSA Group, Toyota and Volkswagen. AUTOSAR follows a three layer architecture. We have Application Layer, Real Time Environment Layer or RTE in short, Basic Software Layer or BSW in short. Software which is a combination of these layers run over a microcontroller.
Now, let's try to understand these layers one by one. First, we have Application Layer. This layer includes various application specific components which are designed to execute specific set of tasks.
Software components are nothing but the simplest form of application. Application layer is made up of three parts. Application software components, ports of these components and port interfaces. Next layer is RTE. It is a middleware layer between application and basic software layer.
It provides communication channel between software components, and BSW using ports and port interfaces. These ports exchanges data using RTE buffers and invokes BSW functionalities. Another interesting fact about RTE is that the software architecture about RTE changes from layer to component style. Lowest software layer is BSW layer. It is a standardized software that can provide services to AutoSAR software components.
It is also used to run the functional part of the software. BSW includes standardized and ECU specific components. BSW layer provides the following services.
Input output, this provides access to sensors actuators and various peripherals. Then we have memory, this provides access to internal and external memory. Then we have crypto, this provides cryptographic primitives. Then we have communication, this provides various communication protocols for on-board and off-board communication. Then we have system.
This provides ECU specific services and library functions. BSW layer is further subdivided into three horizontal layers. We have service layer, ECU abstraction layer, microcontroller abstraction layer or mcal. Let's have a look at them one by one.
First is service layer. This is the topmost layer of PSW. It provides interfaces to the application which are independent of microcontroller and ECU hardware.
Then we have ECU abstraction layer. This layer offers uniform access to all the functionalities of ECU such as communication, memory or I.O. Regardless of whether these functionalities are part of controller or are implemented by peripheral components.
It also offers API to interface with the microcontroller device drivers. The lowest BSW layer is MCAL or Microcontroller Abstraction Layer. It is access route to communicate with the hardware.
It contains internal drivers which are software modules which have direct access to the microcontroller and internal peripherals. This layer provides microcontroller independent values for BSW components. At last we have complex device driver layer or CDD in BSW which is not in a horizontal space but rather in a vertical space.
This layer has special timing and functional requirements for dealing with complex sensors and actuators. CDD is used for handling complex functions that can't be found in any other BSW layer. It also has the ability to access the microcontroller directly.
Okay So now let's try to understand a simple working principle behind a turn indicator on and off mechanism using AUTOSAR compatible software. The first step is that a software component for turn indicator requests to turn on the bulb. This request is routed through RTE to BSW responsible layer.
In this case it is IEO hardware abstraction. This in turn switches on PWM signal on the output pin where the bulb is connected. Let's take another example. In this case, Door Control Unit wants to broadcast the status of Door via CAN to other ECUs in the car.
First, Door Status software component in the application requests RTE to send a CAN signal. This request is routed to Communication Layer of BSW. Communication Service Layer routes the frame through CANIF to CANDRIVER.
CANDRIVER helps writing the CAN frame into the hardware buffer which in turn converts the buffer to electrical signal which are then transmitted through the CAN bus to the other ECUs. I hope this video helped you to understand the basic principles behind AUTOSAR. If you like the video please don't forget to like, share and subscribe.
Please let me know what other topics should we cover on this channel. Thank you and see you in the next video.