We will now start with the AUTOSAR SW architecture at the ECU level. Going back to the example of house plan, most houses will be built on top of a land area, will have a foundation and all the rooms and useful stuff for us will be built on top of the foundation. Similarly, in the AUTOSAR architecture, the hardware is like the land area, there is nothing in the plan about it.
Next, to the foundation, it is the part that holds the entire house or in our case, the Base SW(drivers, services, OS,etc..) is the one holding the entire SW above it. From an end-customer perspective, the details of the foundation doesn't matter as he will not be living in it. But if it fails everything is gone.
Being the most important part, AUTOSAR has given very comprehensive architecture details and specifications on how Base SW should be built. When we come to the rooms on top of foundation, in our case the application SW, the architectural specifications are very less. Only on how different applications should communicate with BASE SW and each other. Similar to how in a house the user is more specific about the design of the rooms, the applications have very less restrictions from AUTOSAR and more customizable
Next, to the foundation, it is the part that holds the entire house or in our case, the Base SW(drivers, services, OS,etc..) is the one holding the entire SW above it. From an end-customer perspective, the details of the foundation doesn't matter as he will not be living in it. But if it fails everything is gone.
Being the most important part, AUTOSAR has given very comprehensive architecture details and specifications on how Base SW should be built. When we come to the rooms on top of foundation, in our case the application SW, the architectural specifications are very less. Only on how different applications should communicate with BASE SW and each other. Similar to how in a house the user is more specific about the design of the rooms, the applications have very less restrictions from AUTOSAR and more customizable
AUTOSAR BSW:
We will take a different example for explaining this. Let us say you are upgrading your PC from Windows XP to Windows 7 or 10 and the OS would not work because of the 512MB RAM, you don't need to throw away your old PC for this just an additional RAM in an empty slot or replacement of 512MB RAM to 2GB or higher is sufficient. This is an example for modularity, RAM is a separate module and can be plugged in or replaced. Similarly, all parts of basic software should be easily added, removed or replaced without much effort. For this Base, Sw should be properly divided and abstracted.
Abstraction here in this analogy would be that the RAM chip is independent of the motherboard or processor brand, it could be Intel or AMD or whatever but the RAM chip would still work because the interface is generic, open and independent of each other.AUTOSAR architecture achieves this by properly segregating the features and defines the mechanism of interfacing so that abstraction could be achieved. Let us take an actual example, if application gives a command nvm_write(data), it need not worry about whether it is written to EEPROM or Flash or any other NVM storage medium. For the application, it doesn't matter what lies below it only knows the data it needs to write and the NVM function, everything other than this is a dark zone for it. This easily enables us to change the SW with minimal changes, for eg. if switch from an EEPROM to flash in my project I just need to remove some drivers and add some drivers and no changes are needed at the application or the upper BSW layers which does the session management and request queuing.
Now since we are clear on this now. Let's jump into the real stuff
The entire BSW is split into below layers on a higher level
Microcontroller Abstraction layer:
The Microcontroller Abstraction Layer is the lowest software layer and contains drivers of the microcontroller and its internal components. This layer is unique for a controller or controller type and designed independently of μC so that if ony microcontroller is changed we could just exchange this layer and rest of the whole SW will remain same
ECU Abstraction layer:
It contains drivers for external microcontroller peripherals(outside the micro but still inside the ECU board) and also acts as the interface between MCAL and upper layers. It provides access to peripherals and devices regardless of their location (μC internal/external) and their connection to the μC (port pins, type of interface). They are independent of microcontroller but dependent on the ECU and its peripherals , so if we change the ECU components this layer has to be modified
Services layer:
The Services Layer is the highest layer of the Basic Software which also interacts with application, it has the below functionalities
This layer is independent of ECU as well as Micro-controller
complex drivers:
In spite of all the efforts put to the development of AUTOSAR, currently, there are some SW features which could not be modularised or abstracted due to multiple reasons. They are classified as complex drivers
We have not yet covered important concepts like RTE, VFB and AUTOSAR methodology. These topics will be discussed in upcoming articles
Abstraction here in this analogy would be that the RAM chip is independent of the motherboard or processor brand, it could be Intel or AMD or whatever but the RAM chip would still work because the interface is generic, open and independent of each other.AUTOSAR architecture achieves this by properly segregating the features and defines the mechanism of interfacing so that abstraction could be achieved. Let us take an actual example, if application gives a command nvm_write(data), it need not worry about whether it is written to EEPROM or Flash or any other NVM storage medium. For the application, it doesn't matter what lies below it only knows the data it needs to write and the NVM function, everything other than this is a dark zone for it. This easily enables us to change the SW with minimal changes, for eg. if switch from an EEPROM to flash in my project I just need to remove some drivers and add some drivers and no changes are needed at the application or the upper BSW layers which does the session management and request queuing.
Now since we are clear on this now. Let's jump into the real stuff
The entire BSW is split into below layers on a higher level
Microcontroller Abstraction layer:
The Microcontroller Abstraction Layer is the lowest software layer and contains drivers of the microcontroller and its internal components. This layer is unique for a controller or controller type and designed independently of μC so that if ony microcontroller is changed we could just exchange this layer and rest of the whole SW will remain same
ECU Abstraction layer:
It contains drivers for external microcontroller peripherals(outside the micro but still inside the ECU board) and also acts as the interface between MCAL and upper layers. It provides access to peripherals and devices regardless of their location (μC internal/external) and their connection to the μC (port pins, type of interface). They are independent of microcontroller but dependent on the ECU and its peripherals , so if we change the ECU components this layer has to be modified
Services layer:
The Services Layer is the highest layer of the Basic Software which also interacts with application, it has the below functionalities
- Operating system
- Vehicle networking
- Memory services
- Diagnostic
- ECU state and mode management
- Logical and temporal program flow monitoring
This layer is independent of ECU as well as Micro-controller
In spite of all the efforts put to the development of AUTOSAR, currently, there are some SW features which could not be modularised or abstracted due to multiple reasons. They are classified as complex drivers
Posts
No comments:
Post a Comment