 Video – overview

o Full form -Automotive Open System Architecture

o -First release – 2003
o established by group of oems
o reusability of software components .
o provides software architecture and certain standards .
 .
 AUTOSAR was adopted by the OEMs to have the control in their hands
o -OEM can choose platforms have many choices

o -Architecture
o -Methodology
o -Application Interface

 KPIT solutions
o -R3.x and R4.0
o -KPIT Solution is evaluated by OEMs/Tier1s consortium

 Rebuilding Cost to update/add is eleminated

 Universal guidelines

 MCAL:
 lowest layer of the basic software
 hardware dependent layer
 works with internal drivers .
 acts as a bridge between hardware and upper layers
 . inputs needed for MCAL Software Specifications and datasheet of
microcontroller

 AUTOSAR architecture provides guidelines to map software architecture

 : 1. generic layered architecture: provides architecture a flexible and robust
architecture.
 It enables communication between two different systems even when core
architecture is different os and hardware
 . 2. software layers architecture: software layers consists of
  -RTE
 -Com stack
 -Guidelines for File
 -Functional Safety
 -Diagnostics
 -Application layer

 Bsw (basic software layer )-

 basic software layer contains
 microcontroller abstraction layer: lowest layer
o contains drivers and software modules having direct access.
o makes the above layers independent of the microcontroller.
 2.ECU abstraction layer: interfaces drivers of abstraction layer
 3. complex drivers: enable access to other devices and peripherals irrespective
of location.
 . 4. services layer: top layer of the basic software layer. Provides basic services
to others
 Except the MCAL(Micro-controller Abstraction Layer) layer of the software, the
software is independent of the hardware
 Ease of integerating products from different suppliers
 MCAL Layer enables to seperate the various layers
 Generic Layered Architecture
o -Hardware
o -OS/device drivers
o -Middleware
o -Application
 Two application software components communicate via RTE
 Software Layers
 top view:
o -Microcontroller
o -Basic Software
o -Runtime Environment
o -Application Software
 Bottom view
o -Microcontroller
o -MCAL
o -ECU Abstraction Layer
o -Service Layer
o -Runtime environment layer
o -Application layer
o -Complex Device drivers
 State Manager
 Diagnostic Event Manager
 LIN operates at the speed of 20kbps
 Memory Services-: Provide non volatile data to the
 application-NVRAM Manager
 System Services- group of modules
 and functions which can be used by modules
 of all layers
o -Provide basic services for application and
o basic software modules.
 ECU state manager-regulates all the events from the starting to shutting down of
the system
 Diagnostic event manager- COllects information regarding any faults or errors in
the system
 Function Inhibition Manager- It either enables or inhibits any functionality to
happen
 Crypto Service Manager- provides cryptographic services- used for providing
safety to the ECU
 Watchdog manager- Helps in resetting the software
 Comm. Manager
o -dependant on the protocol being used
o -decides when the ecu should transmit/recieve
 Autosar interfaces
o -Applications/functions where abstraction is implemented
 Standardized autosar interface
o -Number of arguemnets for function is fixed, it can't be changed
o -These functions will be interacting only with the service layer and the RTE
 PDU-Protocol Data Unit
 SDU-Service Data Unit-A data unit that requires some service
 PCI-Protocol Control Information-contains info on the type of data
 TP is required due to limitations of the communication protocol
 NPDU->Network PDU
 IPDU->Intermediate PDU

 VECTOR E_LEARNINg

o Requirements
 ->supporting driver assistance systems in critical driving manoeuver
 ->improving fuel economy
 ->conforming to environmental standards
 global development partnership of automotive OEMs,
automotive suppliers and other companies in the software,
 semiconductor and electronics industries
 advantages of AUTOSAR:
o ->Mastery over increasing product and process complexity
 o ->Ability to optimize the ECU network by flexible integration, relocation
and exchange of functions
o ->Maintainability over entire product life cycles
 Disadvantages:
o ->AUTOSAR does not offer any capability of describing the functional
behavior of a software component

 -Port Module
o ->Handles and intializes pins across the whole MCU
 -Inter-module dependencies
 -Intialization order
 MCU initialization
 Watchdog initialization
 port initialization
 Individual module initialization-ADC,PWM,ICU,DIO
 MCU Drivers
 -IoHwAb

 Basic diff. between MCAL and BSW

 -RTE Elements
 Variable Data Prototype (VDP)-used to configure what type of data we want to
exchange
 Mode declaration group-used to configure diff. states in which you want to
implement
 Client Server Operation-Argument Data Prototype-definition of diff arguments
 CalPrm Element-Defintion of calibration element

 Connectors:
 -Assembly(P2R)-If two components present in the same composition want to
connect with each other, they can use assembly connector
 -Delegation(P2P or R2R)-If two components of diff. compositions want to connect
with each other, delgation connector is used to delegate the ports, we further use
assembly to connect the delegated ports

 Internal structure:
o -Runnable Entity->Schedulable
 -Basic interaction between application and RTE takes place
through runnable entity
 o -RTE Events-> Used to access a runnable entity
o -Exclsive Areas-> critical sections of the code
 Intra ECU Comm.
 -communication between two components/modules of the same ECU
 -realised through RTE

 Inter ECU Comm.

 -communication between components/modules of diff. ECU

 Inter Partition Comm.

 -comm. between softwares across diff. partitions of a core
 -OS feature is used

 SENDER-REEIVER COMM:
 -multiple senders or multiple receivers
 -Implicit & Explicit comm.
 -unqueued and queued comm
 -all datatypes are supported
 -feature of providing initial value
 -alive time mode feature-if the comm is unable to transmit data in a given time
then it will notify the RTE

 CLIENT-SERVER COMM:
 -Basic elements:
o ->client-server operation-configuration of arguements
 ->datatype specification
 ->direction specification
o ->inout dir.->exchange of data between client and
server
o ->in dir.->client is giving data to server
o ->out dir.->server giving data to client
o ->return values-server returns some standard value
 -synchronous comm:
o -also called blocking comm.
o -RTE called doesn't return untill there is a response from the server
 -asynchronous comm
o -server request is sent after completing the RTE call
 -RTE Result
o ->application tries to get a response from the RTE
 Comm between two functions within the software comm:
o InterRunnableVariables are used for this purpose:
 explicit
 implicit

 Basic elements of mode switch comm:

 -mode declaration group
o ->diff states

 mode manager-to switch between diff. modes and mode user

 RTE Contract phase

 -used by application developer
 -software is given as input

 RTE Generation phase

 -software and system description
 -ECU configuration
 -generating source and header files

 files generated by RTE

 -Rte.c
 -Rte_Type.h
 -Rte Application header file
 -Rte_Hook.h
 -Rte_Cbk.h

 VFBB-debugging feature of RTE

 OSEK OS By Tracy Austina

 An interface between the user and the hardware
 GPOS-size in MBs

 for developing a software for MCU

 -the OS size needs to be in KBs
 -faster(real time)
 -time bound

 OSEK OS Specifications:
 European automotive consortium responsible for open standards for the
automotive industry
 -Reason
o ->increasing quantity and complexity of software content
o ->lack of qualified software engineers
o ->desire for high quality products
 -reusable code
 -3 standars-
o ->OS standard
o ->comm module
o ->OSEK NM standard

 OSEK-Open Systenms and corresponding interfaces for automotive electronics

 VDF-Consortium by France(vehicle distributive executive)
 BUS protocol X and Y
 OIL-OSEK Implementation Language
 3 processing levels(in the order of priority (0-255))
 -intra
 -scheduling
 -task

 OSEK is statically configured OS-no room for changing the configurations when
the code is running on the MCU

 OSEK offers 8 services

 Task Management
o -basic task
o -extended task
 Priority based event driven scheduler
 Interrupt Service Management
o Category 1-doesn’t allow you to have API
o Category 2-allows
 Resource management
o -OSEK priority sealing protocol
o -always makes sure one resource is not being used by multiple tasks at
the same time
 o -a task never enters wait mode for a resource
o -makes sure there is no priority inversion
 Timers and Counters-monitor for recurring events
 Events-OS objects that are used to synchronize diff tasks
 Error handling and hook routines- connects two diff things
 Scheduler can be used as a resource- to run a task exclusively
 System Configuration
 OIL objects have to be configured beforehand
 OIL grammar rules
 Application Development
 -User source code
 -OSEK builder tool-Linux/windows based-configuration OIL objects
 -System generator
 -OSEK OS Source code
 Conformance classes
 -BCC1-basic
 -ECC1-extended
 BT-basic Task
 ET-Extended task
o -task can enter into wait state
o -uses RAM
 Task Stacks-in case of preemptions, factors deciding size of a task:
o -scheduling policies
o -services being used
o -timer/counter specification
 Inter task comm-happens via messages
 Task management runtime services-
 Activate Task
 Terminate task
 Chain
 Schedule
 Get task ID
 Get task _
 Scheduling-Preemptive and non-preemptive
 Counter and alarms
 Counter counts the recurring events
 Alarm can repeat an ongoing task or start a new task
 Events-a method for synchronization for extended tasks
 Autosar OS:
 -GPOS-non-deterministic
 -RTOS-deterministic
 -Statically configured
 -Tasks
 -basic tasks
 -extended tasks
 -Scheduler
 -Preemption-process of
 -ISR-interrupt service routine
o -hardware and software
o -the task that is being interrupted is stored in a stack
 -resource-mechanism for mutual concurrent access exclusion
 -counter & alarm:processes recurring events according to the interrupt

 Protection features
 -timing protection-ensures that a task is releasing a particular resource within the
specified time
o Advantages
 -resets your MCU
 -predictive behaviour of OS incase f hardware

 Memory Protection-prevents memory corruption, restricts access

 Service Protection:prevents faulty behaviour in kernel
o Advantages
 -detects fault at early stage
 -less time to debug
 Tasks-
 Chain task-terminating the ongoing task and activating a new one
 Multiple activation-if a task which is already running and the same task is to be
activated

 Event:
 wait event:making a particular task to wait

 counters-hardware and software

 Scheduler:

 -start a schedule table

 -stop a schedule table
 -get value from a schedule table
 Statically and dynamically configured OS
 Multicore OS

 MODULE INTERACTION
 -Protocol Data Unit-Information flowing through the stack

 COM-communication manager
 -controls start and stop of I-PDU groups
 -Monitors and controls the the PDU groups

 CAnIf(Interface Module)
 provides an interface to manage diff. CAN hardware devices

 CANSM(State Manager)
 -responsible for the control flow abstraction of CAN networks

 CANNm
 -coordinates transition between normal mode and bus-sleep mode
 BswM-mode arbitration,mode control