To install StudyMoose App tap and then “Add to Home Screen”
Save to my list
Remove from my list
Growing complexity & the need for comfort in vehicles marks the need for standardized architecture for automotive ECU's. AUTOSAR (AUTomotive Open System Architecture). It is an architecture similar to OSI model. It has the following layers; Application layer, Basic software layer and Run Time Environment. This paper aims to explain the AUTOSAR architecture in detail. The AUTOSAR architecture is present in form of software specification documents which is helpful in implementation but difficult to understand. The motto of this project is to understand the AUTOSAR Requirement specification documents & present all the information in an understandable manner.
The paper also covers the AUTOSAR methodology and the various tools used for its development.
In current automotive era most of the newest features in vehicles are software based. With growing number of features in car, the software complexity is also increasing. In order to manage the increasing software complexity most of the OEM's, suppliers came up with AUTOSAR architecture as a solution.
Verified writer
Proficient in: Network
4.7 (235)
“ Amazing writer! I am really satisfied with her work. An excellent price as well. ”
The increase in electrical & electronic complexity, increase in the size of software, using of wide variety of available hardware platforms pose challenges to AUTOSAR development. The main motto of the AUTOSAR is to improve the efficiency & software quality there by making the reusability of function & Basic software across OEM's. AUTOSAR partnership today comprises of 200 members. AUTOSAR is still growing & is not complete. It is an evolving standard considering the latest improvements & enhancements in the technology.
AUTOSAR structures the software in a layered way to abstract from hardware.
This results in software independent from hardware. The Basic software comprises of numerous modules and is mainly divided into MCAL (microcontroller abstraction layer), ECU abstraction layer, Services layer & Complex Drivers. Microcontroller abstraction layer is the lowest layer which consists of low-level drivers like communication driver, I/O drivers, memory drivers etc. It abstracts the hardware & has direct access to microcontroller. The main task of MCAL is to make the upper software layers independent of microcontroller. ECU abstraction layer is the microcontroller independent layer but depends on hardware layout of ECU.As the name says it abstracts the ECU & mainly deals with interfacing the drivers of MCAL, Complex drivers comes into consideration when there is a need to
include standardized (non AUTOSAR) functionality along with Basic software. It has direct access to the hardware & RTE. Services layer is the topmost layer in the Basic software which offers communication services, memory services, OS functionality to the applications & Basic software modules. The next layer is the Run Time Environment which is between basic software & application layer. This is fully configurable and is generated depending on the configurations by the configuration tool.
It is a layered software which services the requests received from application software components. Memory services provided by NVM (nonvolatile memory modules, Flash drivers etc.), Communication services via CAN, LIN, FlexRay, Ethernet etc. System services (provided by operating system). To accomplish all these tasks there are various modules which are intended for a purpose & they interact with one another to achieve the functionality. There are many BSW modules, we look into few important & prominent ones in this paper. Let's begin with the lowest layer microcontroller abstraction layer. It comprises of microcontroller drivers like MCU driver, GPT, core test. Memory drivers like Flash driver, EEPROM driver. I/O drivers like PWM, DIO, Port driver. Communication drivers like CAN driver, LIN driver, FlexRay driver, Ethernet driver. So, this deals with underlying hardware. For our understanding let's consider CAN driver in detail. It abstracts the application from the basic software layer. We will consider the detailed architecture, module functionality & interaction between them in the upcoming sections. CAN Driver is a piece of software which is developed by the information from the CAN driver AUTOSAR specification.
The functionality, configuration details, requirements, dependencies to other modules, API's are provided by this specification. The only module which has access to this can module is CanIf (Can Interface) of the ECU abstraction layer. Every CAN hardware unit has a Can driver and may have a single or multiple can controllers. Every CAN controller serves one physical channel. The Can module is used when the can protocol is used for communication in applications. This functionality is implemented in C language and shall conform to MISRA rules. The L-PDU concept is followed here. During transmission the L-PDU is written on the buffer of the hardware unit & during reception can module provides the service of indicating CanIf via RX indication (a call back function). Along with transmission & reception, it also provides services to notify Bus off & wakeup events via call backs. The specification also provides the CAN driver state machine & the CAN controller state machine. For example, four basic CAN controller states are UNINIT, STOPPED, STARTED and SLEEP. The transition of these states takes place by the software i.e. CanIf module calls the function Can_SetControllerMode with the required state transition as a parameter. If the transition is successful, then can module notify CanIf via callback function CanIf_ControllerModeIndication. This is how the modules are designed to achieve the desired goal.
The I/O hardware, communication hardware, memory hardware & onboard device abstraction is covered by ECU abstraction layer. The I/O devices either on chip or external & are abstracted by this layer. It also hides the ECU hardware layout. Some of the modules in this layer include Can Interface (CanIf), Memory Interface (MemIf). For our understanding & to follow the module interaction let's consider CanIf module in this layer.
Can Interface deals with the control & dataflow The Can state manager (CanSM) handles the controller modes. The CAN drivers Can Transceiver drivers are managed by this interface. It serves as a link between upper service layers like PDUR, CanSM & the low-level drivers (MCAL). CAN controller modes transitions like CAN_CS_STARTED, CAN_CS_STOPPED, CAN_CS_SLEEP is controlled by this module. To know the current controller mode API CanIf_GetControllerMode () & to set the controller mode CanIf_GetControllerMode () are used. For data flow transmit requests, Tx Confirmations, Reception Indications are some of the notable services provided by this layer. It also interacts with the PduR which calls the CanIf via CanIf_Transmit () to transmit L-PDUs. The transmit function results in the Can Write where the L-PDU is written on the CAN hardware.
AUTOSAR architecture encloses the Service layer, which is divided into three sections called communication services, memory services & system services. Communication services deal with the signal flow. They basically serve to enable the communication on different buses like CAN, LIN, Ethernet. The message from the application is passed to the hardware using the communication services. AUTOSAR COM, Diagnostic communication manager, PDU Router, Bus specific state manager & Network manager, Bus specific transport protocol, IPDU Multiplexer are the modules which belong to Communication services.
PduR (Protocol Data unit routing) is responsible for routing of PDU's and consists of PduR routing paths & Router Engine. The routing paths for the PDUs is a configurable feature. Router engine routes the PDU's from source to destinations. The main task here is to forward the PDU's and not to modify them. From ECU's perspective PduR gets the data (PDU's) from the lower layers and forwards them to upper layers and the other way i.e. forwards the data (PDU's) from upper layers to the lower layers.
COM is also the part of communication layer and is in between RTE and PduR. COM is a big module fulfilling many functionalities. Some of them are packing and unpacking of signals, signal gateway, supporting varying lengths of datatypes, transmission control & support of two transmission modes per I-PDU. The endianness conversion, sign extension is supported by this module. Filtering mechanism is also a part of Com module. This interacts with RTE in the upper layer & PduR in the lower layer to transmit & receive the data in the form of I-PDU's.
Modules under System services include BswM (Basic software Mode Manger), WdgM (Watchdog Manager), FIM(Function Inhibition manager), Dem(Diagnostic event manager),ComM(Communication manager),EcuM(ECU State Manager),Dlt(Diagnostic Log and trace),Det(Development Error trace).
BswM (Basic software Mode Manager) as the name suggests, it services the requests from all the Bsw modules and the application software components. The BswM has two parts Mode arbitration & Mode Control. Mode arbitration is where it processes the requests from various BSW modules & SWC's. BswM Mode control performs actions from the action lists depending on the evaluation of the rules based on the logical expressions. BswM is totally a configurable module. We can decide its behavior by the configuration. BswM interacts with many Bsw modules and all these interactions are optional and user configurable.
ComM (communication manager) module handles all the communication related requests like bus communication access requests and coordinates them accordingly. It is recommended to have the hardware knowledge as communication manager switches the channel on/off depending on the configuration. It interacts and interfaces with all the Bus state managers. It also supports partial and pretended networking for the ECU's. The concepts of partial & pretended networking are used to save power on the ECU's.
EcuM (ECU State Manager) module is responsible for managing ECU states and is responsible for initialization & deinitialization of operating system, Schedule manager (SchM), BswM along with the some of the driver modules. The wakeup validation is also provided by EcuM to differentiate between real and unreal wakeup events. EcuM comes in two variants; EcuM fixed and EcuM Flexible.
Having discussed some of the modules, let us see the methodology in the coming sections. The software development for the ECU's was done by the AUTOSAR consortium and the details were covered in the AUTOSAR methodology.
While designing a system, the application architecture is developed. The application software components are defined and developed and are distributed to the ECU's. This will result in an arxml System description file, which has the overall system information. We can extract a specific ECU's information into a file called ECU description or ECU extract. This will be generated for every single ECU.SWC's are designed and developed during the ECU development stage. The Bsw and RTE are configured by the developer according to the needs of the specified project. The resulting file is called ECU configuration description file in XML format. All this software is implemented using C language. To generate the C files from the configurations scripting languages like perl is used for the generation.
The development life cycle includes all the phases from Requirements to Maintenance phase. The main deliverable of the AUTOSAR is the specifications of the modules. These specifications serve as the input to the requirements phase. The functional & nonfunctional requirements are extracted from the specification document. The next phase is design phase, the requirements document serves as an input to this phase where design decisions are taken. This serves as an input to the Coding phase where the functionality is implemented using C language. The next phase is called the Testing phase where the test applications are developed, and the functionality is tested. The last phase is the maintenance phase where the issues are addressed & fixed.
The important elements for a communication to happen in AUTOSAR are the signals, signal groups, PDU's including IPDU's, NPDU's and frames. These form the base for communication. Frames are part of the communication channels and have a data section called payload of certain bytes. PDU's form the part of the network layer. The I-PDU's are packed and unpacked in the COM module and passed to lower layers while NPDU's are a part of Tp modules (transport protocols). DCM (diagnostic communication manager) forwards the IPDU's via Transport protocol.
For the communication to begin there must be message or the information. This message or information is considered as a signal in AUTOSAR. The messages or signals that have to be transmitted at the same instance are usually grouped together to form signal group and the signal inside the signal group is referred as group signal. AUTOSAR COM is the one which does packing and unpacking of these signals and provides signal level information to the application layer & PDU level level access to the lower layers.
The communication begins with the request from the software component for FULL_COMMUNICATION to RTE via Rte_call API. This will be indicated to communication manager (ComM) requesting full communication. This in turn will request the Bus specific state managers for full communication mode, CanSM in case of CAN, LinSM for LIN, FrSM for Flexray, EthSM for Ethernet. The state managers will communication with their respective interface modules to set the mode to full communication via BusInterface_setcontroolermode().The Can Interface in case of CAN, LinIf in case of LIN, FrIf for flexray, EthIf for ethernet. This will be informed to the driver modules in the MCAL. After setting the mode this is indicated to the interface modules via BusInterface_controllermode indication indicating the change in the state of the communication mode. Similarly this indication is given to BusSM via BusSM_Controller ModeIndication() which indicates ComM. After achieving full communication ComM sends a network request to Network management module (Nm) which requests the BusNm for network request via BusNm_NetworkRequest() which makes the network frame transmission possible.
Now the setup is ready for communication after the network request & its indication. Transmission is initiated by the API Rte_Write from the software component. Rte triggers Com modules via Com_SendSigna(). Com module calls the PduR module via PduR_ComTransmit(). The transmit request is forwarded to the interface layer via BUsIf_Transmit request like CanIf_Transmit() in case of CAN bus which triggers the lower layer CAN driver Can_Write() which writes the data into the CAN Hardware. To know that the transmission was successful we require Confirmations which is carried by the series of Tx confirmation API's through all the modules till RTE.
In case of reception, the receive interrupt will be raised followed by the Rx_Indications to the upper layers. Rte_Read API, Com_Receive Signal will be used in this case. The above diagram represents the active full communication request steps. This is done via API's (Application Programmable interface). The Rte_Call API is used by the application software components to request full communication. For a complete stack to be functional & operational it has to be in full communication; Initially it will be in No communication. The full communication request passes from one layer to another layer and finally reaches the lowest layer which indicates the upper layer after going to full communication. Once the indication reaches the communication manager, the ComM requests the Network manager for network request which in turn requests the
bus specific network manager. The first frames which are transmitted are the NM frames (Network frames) followed by the CAN frames or bus specific frames.
AUTOSAR COM module comes into picture here. For a transmit request, The application software component calls the RTE via RTE_Write _ (). RTE calls the CoM module via Com_SendSignal () which in turn calls the PduR via PduR_ComTransmit(). PduR calls the bus specific interface CanIf_Transmit ()/ FrIf_Transmit()/LinIf_Transmit() etc The interface requests call their respective drivers like CAN driver, LIN driver etc. Can_write or respective Bus API copies the data to hardware and sends the Tx confirmation to the upper layers till RTE.
Like the steps in the transmission, Reception involves series of steps. It starts from the receive interrupt. On reception of the interrupt the lowest layer sends an indication to the upper layer for example CAN driver sends indication to CanIf via CanIf_RxIndication. CanIfor the bus interface in turn indicates the PduR via PduR_CanIfRxIndication. PDU Router indicates the AUTOSAR Com using Com_RxIndicationConclusion
This paper aims to summarize the classic AUTOSAR Architecture. Many aspects & concepts of AUTOSAR are covered. At the beginning the need for AUTOSAR has been covered, following that the architecture in detail is mentioned. Features & components involved are explained. How the dependency between hardware & software is overcome is included in this paper. The AUTOSAR methodology explanation and the Module interaction, PDU flow is described in detail.
The Transmission flow & the Reception flow of the Pdu's between the layers is described in detailed manner. With the invention of AUTOSAR Architecture the automotive industry is booming and developing with the scalable & reusable software.
AUTOSAR is a continuously growing software. The variant discussed here is the Classic Platform. The new evolving AUTOSAR is called Adaptive AUTOSAR which paves the way for autonomous driving
AUTOSAR Classic Platform. (2019, Dec 07). Retrieved from https://studymoose.com/autosar-classic-platform-essay
👋 Hi! I’m your smart assistant Amy!
Don’t know where to start? Type your requirements and I’ll connect you to an academic expert within 3 minutes.
get help with your assignment
