Unlocking Automotive Services: Exploring the AUTOSAR Service Layer | PART 1#AUTOSAR

After getting an understanding on the ECU Abstraction Layer. Lets now look into Service Layer of the Layered Software Architecture. But Before we dive in , Lets first understand what are handlers and managers ? A handler is a specific interface which controls the concurrent, multiple and asynchronous access of one or multiple clients to one or more drivers. I.e. it performs buffering, queuing, arbitration and multiplexing. The data content is not changed by handler.and the functionality is often

incorporated in the driver or interface (e.g. SPIHandlerDriver, ADC Driver). Checkout below videos to know more about driver and interface .... Now lets understand what are managers.. A manager offers specific services for multiple clients. It's needed in most cases where pure handler functionality might not be good enough to abstract from multiple clients. Besides handler functionality, a manager can evaluate and change or adapt the content of the data. In general, managers are located in the

Services Layer Example: The NVRAM manager manages the concurrent access to internal and/or external memory devices like flash and EEPROM memory. It also performs distributed and reliable data storage, data checking, provision of default values etc With this understanding , Lets get into our main topic on What are different groups of Software Services present in Service Layer? Following are the services provided by Service Layer. 1) Communication Services 2) Off-board Communication Services 3) Cr

ypto Service 4) Memory Service 5) System Service Firstly Communication Service: Communication Services are a group of modules built to interface with the communication drivers via the communication hardware abstraction for vehicle network communication such as CAN, LIN, FlexRay and Ethernet. Some of major tasks that they fullfil are Provide a uniform interface to the vehicle network for communication. Provide uniform services for network management Provide uniform interface to the vehicle networ

k for diagnostic communication Hide message properties and protocol from the application Lets go a bit deeper and see the specific modules present in , For example CAN Communication Service stack In CAN Communication Service stack, We have CAN NM ( Network Management) module , CAN State Manager , CAN Transport Protocol ( also called as CANTP) working at the interface of Communication Services to communicate with Hardware Abstraction. In general , these module help in smooth transfer( i.e manage

and syncronise the network) of messages from Application to HW Abstraction layer Then we have the intermediate PDU Router called as PDUR which routes different data to different message based on the message and signal configurations.It can also bypass the CANTp layer and access the CANIf layer of Communication Hardware Abstraction. On top of PDUR , we have AUTOSAR COM and Large Data COM which has the name imples are modules that handles the basic functionality to transmit COM data on PDUR Along

side , there are diagnostic modules such as Diagnostic Com Manager called as DCM and Diagnostic Log and Trace which helps in managing and logging error considering the diagnostic request and response sent and received by Application. Generic NM Interface would provide APIs to interface with NM module.It handles the task of changing network states from awake to sleep to save power.It convert generic function calls to bus specific calls and vice versa and also performs the role of Network Manageme

nt coordinator. Before we understand I-PDU Multiplexer , lets first understand what an I-PDU is , An I-PDU is Interaction Layer Protocol Data Unit. Basically Whenever the PDU( Protocol Data Unit) is in layers above Communication Hardware Abstraction layer then its called I-PDU. So , I-PDU Multiplexer Module is responsible to combine appropriate I-PDUs received from COM via IPDU-router to new, multiplexed I-PDUs sent back to the I-PDU Router on sender-side. On receiver-side it is responsible to i

nterpret the content of multiplexed I-PDUs and provide COM via IPDU-router with its appropriate separated I-PDUs by taking into account the value of the selector field. Lastly the Secure Onboard Communication or SecOC , SecOC was developed to provide authentication and integrity protection of sensitive data for correct and safe functionality of the vehicle systems – that is it ensures that received data comes from the right ECU and has the correct value.The SecOC module aims for resource-efficie

nt and practicable authentication mechanisms of sensitive data on the level of PDUs. SecOC module generally supports the use of symmetric and asymmetric methods for authenticity and integrity protection Upcomming video we will have a look into the details of other System Services. Thank You