so what is layered software architecture
it's a hierarchical structuring of autosar software with the basic software
module mapped to different software [Music] layers after looking into all the project
objectives of osar let's now look a bit deeper into layered software architecture of
autosar before we dive in let's first try to address the question on what type of eus were
considered for developing osar specification aasar is dedicated for automotive isus such
eus have the following pro
perties they have strong interaction with Hardware basically
sensors and actuators they're connected to vehicle Networks like can Lin flexray or ethernet
they have microcontrollers typically of 16 or 32 bit with limited resource of computing power and
memory compared to Enterprise solutions they are realtime systems and program execution happens
from internal or external flash memory so one ECU that is one microcontroller with peripherals
and according software configuration shall have one
autosar ECU instance which implies
there are two or more microcontrollers in an ECU each microcontroller requires its own
description of an autosar ECU instance with this understanding let's get into our main topic
so what is layered software architecture it's a hierarchical structuring of autosar software
with the basic software module map to different software layers which will help in understanding
the relationship between different modules at high abstraction autosar architecture contai
ns three
software layers application runtime environment RTE and basic software BSW the autosar basic
software is further divided into service layer ECU abstraction layer microcontroller
abstraction layer and complex driver layer starting with microcontroller abstraction layer
microcontroller abstraction layer which is the lowest software layer of basic software module
contains internal drivers which are software modules with direct access to microcontroller and
internal peripherals object
ive of microcontroller abstraction layer is to make higher software
layers independent of microcontroller implementation of microcontroller abstraction
layer layer shall be microcontroller dependent the layer shall provide standardized interfaces
to higher layer which are independent of microcontroller next we have EC abstraction layer
which interfaces the drivers of microcontroller abstraction layer it also contains drivers for
external devices it offers an API for access to peripherals an
d devices regardless of their
location either they could be microcontroller internal or external and their connection to the
microcontroller through ports pins or any type of interfaces objective of ECU abstraction layer is
to make higher software layer independent of ACU Hardware layout implementation of ACU abstraction
layer shall be microcontroller independent but ECU Hardware dependent e abstraction layer shall
provide sise interface to higher layers which are independent of microcontro
ller and ECU Hardware
layout next let's have a look at complex driver layer this layer spans from Hardware to RT complex
driver layer provides the possibility to integrate special purpose functionalities such as drivers
for devices which are not specified within autosur or drivers which have very high time constr TRS
Etc implementation of complex driver layer might be application microcontroller or ESU Hardware
dependent complex driver layer shall provide standardized interface to higher la
yer which
might be application microcontroller and ECU Hardware dependent lastly we have service
layer which is the highest layer of basic software the service layer has its relevance for
for application software accessing the io signals covered by EO abstraction layer the service
layer offers operating system functionality vehicle network communication and Management
Services memory Services diagnostic services including UDS communication error memory and
fault treatment ECU State Managem
ent and mode management logical and temporal program flow
monitoring Etc objective of service layer is to provide basic services for application RTE
and basic software modules implementation of service layer mostly are microcontroller and ECU
Hardware independent service layer shall provide standardized interface to higher layer which are
independent of microcontroller and ECU Hardware layout coming to RTE the RTE is a layer providing
communication services to the application software could
be autoart software components or autoart
sensor or autosar actuator components above the RT the software architecture style changes from layer
to component style architecture hence individual or independent autosar software components can be
integrated above RTE the autosa software component communicate with other components enter or Inu
or through service via RT objective of RT is to make autosar software component independent
of mapping to a specific ECU implementation of RT is ECU or a
pplication specific generated
individually for each ECU RT layer will provide standardized interface to higher layer which
are completely e independent let's now look into the type of services provided by basic software
modules firstly the input output Services basic software module provides standardized access to
sensors actuators and ECU onboard peripherals next memory service basic software module provides
standardized access to internal or external memory non volatile memory crypto Serv
ices basic
software modules again provides standardized access to cryptographic Primitives including
internal or external hardware accelerators Communication Service basic software module
provides standardized access to vehicle Network systems Eco onboard communication systems and E
internal software offboard Communication Service basic software modu provides standardized access
to vehicle to external Communication in vehicle wireless network systems e offboard communication
systems and la
stly system Services basic software module provides provision of standardizable
service such as operating system timers error memory and ECU specific services such as ECU
State management wasto manager and Library functions after getting an understanding on the
layer software architecture let's now look a bit deeper into microcontroller abstraction layer of
layered software architecture but before we dive in let's first understand what are drivers
a driver is a software which contains the f
unctionality to control and access an
internal or external device so what are internal devices devices which are located inside
the microcontroller such as internal eare prom internal can controller internal ADC Etc are
internal devices so a driver for an internal device is called internal driver and these drivers
are present in microcontroller abstraction layer similarly devices which are located outside
the microcontroller such as external eare prom external watch doog external flash Etc
are
called external devices and drivers controlling them are called external drivers these drivers
are present in ECU abstraction layer and not in microcontroller abstraction layer external
drivers in E abstraction layer use internal drivers of microcontroller abstraction layer to
access the external device for example an external eare prom driver shall access the external eare
prom through the SPI Handler driver present in microcontroller abstraction layer there do exist
exceptions for me
mory maap external devices where the drivers have to access the microcontroller
memory directly to control or access the external device in such cases the external drivers are
present in microcontroller abstraction layer with this understanding let's get into our main topic
what are different software blogs or components present in microcontroller abstraction layer
microcontroller abstraction layer majorly contains drivers used to access internal devices of the
microcontroller these drivers
can be categorized into following groups firstly microcontroller
drivers microcontroller drivers contain drivers for internal peripherals such as internal Watch
Dog general purpose timer Etc the general purpose timer driver provides services for starting and
stopping timer channels these are logical timer instances assigned to the timer Hardware which are
individually handled for each Channel by calling respective apis the Watchdog driver is used to
initialize Hardware Watchdog trigger The
Watch Dog and to change the mode of the Watch Dog
into slow fast or off slow mode implies that the watch doog timeout is high for example 1,000
milliseconds which is generally configured during system startup fast mode implies the watch
do timeout is low for example 100 millisecond which is generally configured during runtime off
mode implies that the watch doog functionality is off the MCU driver provides services for
basic microcontroller initialization it also provides powered on functi
onality a reset and
microcontroller specific functionality required by other mcal software modules the microcontroller
drivers also contains functionalities which have direct access to microcontroller like the
core test module the core test is focused on testing the core which includes the CPU
central processing unit and locally coupled unit like mmu the memory management unit mpu the
memory protection unit and interupt controller communication driver communication drivers contain
drivers
for ISU onboard communication like SPI and vehicle communication such as scan Lin Etc the spa
Handler driver allows concurrent access of several clients to one or more SPI bus the Handler
performs buffering queuing arbitration and multiplexing Lin can flexray ethernet driver
provide interaction with the transceiver for reception and transmission of respective protocols
memory driver memory driver contains driver for on chip memory device such as internal flash
internal eare prom memory mapp
ed external device such as external flash Etc it also contains
modules which test the functionality of these memory devices such as flash test ROM test Etc IO
drivers IO drivers contain drivers for analog and digital input output such as ADC analog to digital
converter pwm pulse with modulation Dio digital input output Port driver module shall complete
the overall configuration and initialization of Port structure which is used by the Dio driver
module therefore the Dio driver works on pin
and ports which are configured by the port
driver ICU driver which is the input capture unit driver shall perform demodulation of the pwm
signal also counts pulses measures the frequency of duty cycle and generates simple interrupt and
wakeup interrupts output compare unit Oco driver provides functions for initialization and control
of microcontroller internal ooco functionalities the ooco driver allows comparing and acting
automatically when value of the counter matches a defined threshold
crypto drivers crypto
drivers contain contain drivers for crypto devices such as shei secure Hardware extension
or HSM Hardware security module lastly Wireless communication drivers Wireless communication
drivers contain drivers for wireless network systems which could either be in vehicle or
offboard communication such as Wireless ethernet connection after getting an understanding on
the microcontroller abstraction layer let's now look into the E abstraction layer of the
layered software
architecture but before we dive in let's first understand what are interface
modules an interface module is a software module which contains the functionality to abstract
from the architecturally placed modules below them for example an interface module that
abstracts the hardware realization of a specific device so in general the interface
module would provide a generic API to access a specific type of device irrespective of the
number of existing devices of that type and also irrespectiv
e of the hardware realization
of the different device accessed by the API the rule of thumb is that the interface module
shall not manipulate the data content received from below modules with this understanding
let's get into our main topic on what are different groups of software blocks present
in EO abstraction layer EO abstraction layer majorly contains interface modules which
abstracts the details of microcontroller abstraction layer the abstraction can be
categorized into following gr
oups firstly input output hardware abstraction the input output
hardware abstraction is a group of modules which abstracts the upper layer from the location
of peripheral input output devices either it could be on chip or on board and the ECU
Hardware layout example microcontroller pin connections and Signal level inversions
the input output hardware abstraction does not abstract the existing sensors or actuators
but instead only abstracts the working of the functionality different input ou
tput devices
shall be accessed via input output signal interfaces next we have communication Hardware
abstraction the communication Hardware abstraction is a group of modules abstracts the upper
layers from the location of communication controllers and the EO Hardware layout for all
communication systems a specific communication Hardware abstraction is required be it Lin can
flexray or any other protocol for example an ECU has a microcontroller with two internal can
Channel and an addition
al onboard essc with four can controllers the can essc is connected
to the microcontroller via SPI the communication drivers are accessed via the bus specific
interface for example can interface next we have wiress communication Hardware abstraction
the wireless communication Hardware abstraction is again a group of modules which abstracts
the upper layer from the location of vehicle onboard or offboard communication such as
Wireless ethernet connection the abstraction layer provides API si
milar to communication
Hardware abstraction send data on these wireless connections crypto Hardware abstraction
crypto Hardware abstraction is again a group of modules which abstracts the upper
layer from the location of cryptographic Primitives either it could be internal
or external hardware or even software based for example the AES primitive
is realized in shei or provided as part of the software Library which is access
through apis provided by the cryptographic interface then we have
memory Hardware
abstraction as the name implies memory Hardware abstraction is a group of module which
abstracts the upper layer from the location of the peripheral memory device on chip or onboard
and the ECU Hardware layout as well for example the onchip eare prom and external eare prom
device are accessed via the same mechanism the memory drivers are accessed via memory
specific abstraction or emulation modules for example the eprom abstraction by emulating an
esqu prom abstraction on t
op of the flash Hardware unit a common access via memory abstraction
interface to both the types of Hardware is enabled lastly we have onboard
device abstraction the onboard device abstraction contains drivers for
ESU onboard devices for example internal or external Watch Dogs which cannot
be seen as sensors or actuators those drivers access the ECU onboard devices
via the microcontroller abstraction layer after getting an understanding on E
abstraction layer let's now look into to service
layer of the layer software architecture
but before we dive in let's first understand what are handlers and managers a Handler is a specific
interface which controls the concurrent multiple and asynchronous access of one or more
clients to one or more drivers that is it performs buffering queuing arbitration
and multiplexing the data content is not changed by Handler and the functionality is often
Incorporated in driver or interface for example the SPI Handler driver ADC driver Etc do chec
k
out below videos to know more about driver and interface now let's understand what are managers
a manager offers specific services for multiple clients it's needed in most cases where pure
Handler function fun ality might not be good enough to abstract from multiple clients
compared to Handler functionality a manager can evaluate change or adapt the content of the
data in general managers are located in service layer let's consider an example the EnV RAM Manager manages the
concurrent ac
cess to internal or external man memory device like flash eare prom Etc
it also performs distribution and reliable data storage data checking provision of default
values Etc with this understanding let's get into our main topic what are different groups
of software Services present in service layer following are the list of services
provided by service layer firstly we have we have Communication Service offboard Communication
Service crypto service memory service and system service firstly
let's look into the Communication
Service communication services are a group of modules built to interface with communication
driver via the communication Hardware abstraction for vehicle network communication such as scan Lin
flexray and ethernet some of the major tasks that they fulfill are they provide a uniform interface
to vehicle Network for communication they provide uniform services for Network management they also
provide uniform interface to vehicle Network for Diagnostic communic
ation and they hide the message
properties and protocol from the application layer let's go a bit deeper and see the specific modules
present in for example can Communication Service tack in can Communication service tag we have can
NM also called as can Network management module then we have can State manager can transport
protocol also called as can TP which are working at the interface of the Communication Service to
communicate with Hardware abstraction layer in general these module hel
p in smooth transfer that
is manage and synchronize the network of messages from application to Hardware abstraction layer
then we have the intermediate pdu router also called as PDR which routes different datas to
different messages based on the message and Signal configurations it can also bypass the
CP layer and access the can if layer of the communication Hardware abstraction on top of PD
we have autosar com and large data com which has the name implies are modules that handles the
bas
ic functionality to transfer Com data on PD alongside there are diagnostic modules such as
diagnostic com manager also called as DCM and diagnostic log entries which helps in managing
and logging errors considering the diagnostic r request and response sent and received by
the application looking into the generic NM interface the module provides apis to interface
with the NM module handles the task of changing Network States from awake to sleep to save
power it converts the generic function
calls to bust specific calls and vice versa and also
performs the role of network management call coordinator now before we understand ipdu
multiplexer let's first understand what are ipdu an ipdu is a interactive layer protocol data
unit basically whenever the pdu protocol data unit is in the layer above the communication Hardware
abstraction layer it's called ipdu so with this understanding the ipdu multiplexor model module is
responsible to combine appropriate ipdu received from Comm vi
a ipdu router to new multiplexed ipdu
to send back to the ipdu router on the sender side while on the receiver side is responsible to
interpret the content of multiplexed ipdu and provide com via ipdu router with this appropriate
separated ipdu by tracking into account the value of the selector field and lastly we have secure
onboard communication also called as seos the seos was developed to provide authentication
and integrity protection of sensitive data for correct and safe functionalit
y of vehicle
system that is ensures that the received data comes from the right euu and has the correct
value psychos module aims for resource efficient and practicable authentication mechanism of
sensitive data on the level of pdus seosi module generally supports the use of symmetric and
asymmetric method for authentication and integrity protection after getting an understanding on
the Communication Service of service layer in this video let's have a look into the flexray Lin
and ethernet
Communication Service of of service layer before we go into other sections of service
layer just to recap 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 the major task that they fulfill are they
provide uniform interface to the vehicle Network for communication they provide Uniform service
for Network management they also
provide uniform interface to vehicle Network for Diagnostic
communication and they hide message properties and protocol from the application let's go a bit
deeper and see the specific modules present in firstly the flexray Communication Service in
comparison to can communication stack which we have seen in the last video flexray communication
stack is similar to can with a few changes in basic modules such as flexray NM flexray State
manager and flexray transport protocol the goal of these
modules will remain the same as in can
that is to enable smooth transfer that is to manage and synchronize the network of messages
from application to Hardware abstraction these modules will be protocol dependent to Define the
ipdu that gets transmitted from the Communication Service stack the PDR router ipdu multiplexer
and secure onboard communication will also incur some changes in the configuration to accommodate
flexray protocol interactions in comparison to can rest of the higher lay
er modules such as
diagnostic log entries diagnostic com manager autosar com large data com and generic NM
interface shall not see the impact of the protocol change as these are abstracted from the
underlying communication now let's have a look into the link Communication Service in comparison
to can communication link communication is less costly and less faster than can and the number
of modules and functionalities offered by Lin Communication Service in service layer is also
less compar
ed to can Lin State manager would comprise of all minimum functionalities required
to handle the module such as generic NM interface video router diagnostic com manager and autosar
C the P router will also incurs changes in the configuration to accommodate Lin protocol
interaction in comparison to can this was a brief on Lin so by understanding the changes
to flexray and Lin Communication Service in comparison to can let's Now understand the
change observed in Ethernet Communication Service
the ethernet service contains basic
modules such as ethernet State manager UDP NM socket adapter and tcip Communication Service
different from can communication the ethernet State manager shall provide a abstract interface
to protar communication manager to start up or shut down the communication on ethernet cluster
ethernet State manager interacts with the internet interface which redirects the request to
appropriate driver module coming to UDP NM that's autosar UDP Network management is
a hardware
independent protocol that is used on TCP IP based systems its main purpose is to coordinate
the transition between normal operation and bus sleep mode of the network in addition the feature
also contains services to detect all present nodes or to detect if all nodes are ready to sleep
the UDP Network management function provides a adaptation between Network management interface
and TCP IP stack coming to the socket adapter main purpose of the socket adapter module is to
create i
nterface between autosar Communication Service module using PD router and a socket
based TCP IP stack the module will also map ipd IDs to socket connection and vice versa the
autosar TCP IP module offers functionality to send and receive Internet Protocol data the
TCP IP stag is located between socket adap adapter and ethernet interface modules remaining
modules such as PDO router ipdo multiplexer and secure onboard communication will also incur
changes in the configuration similar to flexr
ay communication to accommodate IP interactions rest
of the higher layer modules such as diagnostic log and Trace diagnostic com manager autosar
com large data com and generic enm interface shall not see the impact of the protocol change
and these are abstracted from the underlying communication after getting an understanding on
the Communication Service of service layer now let's have a look into offboard Communication
Service of service layer offboard Communication Service provides the se
rvices necessary for
the interaction of the vehicle with the outside environment the communication is predominantly
Wireless hence underlining Hardware abstraction is also Wireless and in turn the wireless
communication layer of Hardware abstraction should either be ethernet communication
or cellular communication or both offboard Communication Service architecture can broadly be
classified into two categories European Vehicle to X that's vehicle to everything Communication
Service and Chi
nese vehicle to X Communication service now let's go a bit deeper and see the
specific modules present in European Vehicle tox Communication Service in general European
Vehicle tox Communication Service are a group of modules interacting with ad hoc wireless network
for vehicle tox communication European Vehicle tox Communication Service consists of following
modules vehicle tox Geo networking vehicle tox basic transport protocol vehicle tox facilities
vehicle tox data manager and lastly ve
hicle tox management let's briefly have a look into
each one of them firstly vehicle 2x Geo Network vehicle 2x GE networking Maps the
address pring of the messages based on the geographic area since the respective ethernet
frames have their own ethernet type coming to vehicle 2x basic transport protocol this module
defines the session and transport layer handling required to maintain the communication
with the interacting nodes vehicle 2x facilities vehicle 2x facility implements the
funct
ionality required required for reception and transmission of standardized vehicle 2x
messages it also supports the interaction with vehicle specific software components through
defined interfaces in addition vehicle tox data manager helps in managing the received
messages and transformation of vehicle tox messages it also facilitates interaction with data
transmission through RTE to the software component and finally the vehicle tox management manages
the cross layer functionalities such as
Dynamic congestion control security Etc now with that
we have covered a brief on European Vehicle tox communication let's have a look into Chinese
vehicle tox Communication Service Chinese vehicle 2x Communication Service similar to European
Vehicle 2x Communication Service is a group of of modules based on cellular based vehicle 2x
technology following Chinese vehicle 2x standards Chinese vehicle 2x Communication Service consist
of following modules firstly Chinese vehicle 2x Network and
Chinese vehicle 2x message Chinese
vehicle 2x data manager Chinese vehicle 2x security and lastly Chinese vehicle 2x management
firstly let's have a look into Chinese vehicle 2x Network Chinese vehicle 2x Network facilitates the
message transmission and reception and supports in the activity such as layer to ID setting
Etc coming to vehicle 2x message this module implements the functionality for reception and
transmission of standardized vehicle 2x messages provides the interface for vehicl
e specific
software components and also also implements management of functionalities related to vehicle
message layers such as sending frequency position and time message identifiers Etc then we have
Chinese vehicle 2x data manager like European Vehicle 2x data manager helps in managing the
received messages and transformation of vehicle 2x messages also facilitates the interaction and
data transmission between RTE and the software component for security we have Chinese vehicle 2x
securit
y module which implements the functionality of message encapsulation decapsulation and ponum
management ponum management helps in maintaining the privacy of the vehicle and the user and
lastly the Chinese vehicle 2x management module manages the cross layer functionality such
as dedicated service advertisement Etc this was a brief on Chinese vehicle 2x Communication
Service and with this we have covered a brief on the offboard Communication Service after getting
an understanding on offboard
Communication Service of service layer now let's have a look into memory
service of service layer memory service provides nonvolatile data to application in an uniform
way service provides abstraction from memory location and properties memory service consist
of only one module that's NV RAM Manager the nvram manager is responsible for management of
nonvolatile data provides mechanism to read or write data to or from different memory drivers
also provides mechanism to calculate and evaluat
e checksums ensures reliability of storage
Etc services in memory service are highly configurable and provides independence from
microcontroller and ESU Hardware so that was a brief on memory Services let's now look into
the last service of service layer that system Services System services are a group of modules
and functions which can be used by modules of all layers for example realtime operating system which
includes timer services and error manager Etc the services in system service co
mprise of following
categories firstly they could be microcontroller dependent services such as OS timer service Etc
they could also be partly ESU Hardware dependent such as ESU State manager and lastly they they
could also be both hardware and microcontroller independent such as diagnostic event manager
following are some of the modules present in system Services firstly the basic software mode
manager bswm the basic software mode manager performs two main functionalities that's mode
cont
rol and mode arbitration while performing the mode control the basic software mode manager
performs mode switches by execution of action list containing mode switch operation of other
BSW modules while performing mode arbitration the basic software mode manager initiates mode
switches resulting from rule-based arbitration of mode requests and mode indications received
from software components or other software modules let's look into the next service which is
communication manager service a
osr communication manager service provides services for network
and protocol independent communication between applications the communication manager in
general provides services to communication between applications communication between
classic and adaptive platform and lastly configuration of mbar for communication aspects
such as the register Services Etc then we have the watch talk manager service at a high level the
watch do manager performs supervision of software modules or supervis
ed entities the supervised
entities are supervised by supervision functions which can be categorized as alive supervision
deadline supervision logical supervision Alli supervision is a category of function that
performs supervision of timing of periodic software whereas the deadline supervision is a
category of function that perform supervision of timing of non-periodic software and lastly
The Logical supervision provide supervision of correctness of the execution sequence so
let's look in
to the next service which is the time service this module provides services
for time based functionalities the use case are time measurement time based State machine timeout
supervision busy waiting period tracker Etc next we have synchronized timebase manager purpose of
the synchronized time base manager is to provide synchronized time base to its customers that is
time bases which are synchronized with the time bases on other node of the distributed system two
main use cases are firstly t
he synchronization of enable entities that is to ensure that all the
runable entities connected with the system are executed synchronously secondly provisioning of
absolute and relative time value which implies that the application and other BSW modules shall
provide a central module that is responsible for the provisioning of information about the
absolute time time and passage of time then we have default error Tracer also called as D the
default error Tracer provides functionality to sup
port error detection and tracing of Errors
during development and runtime of software components and other basic software modules for
this purpose the default error Tracer receives and evaluates error messages from these components
and modules next we have functional inhibition manager the functional inhibition manager allows
wearing the permission or inhibition status of software components and functionality therein
in the fim context and FID which is functional identifier identifies an ap
plication functionality
along with the inhibition conditions from that particular identifier the functionality Poll for
permission state of their fids before execution if an inhibition condition applies for a particular
identifier the corresponding functionality is not allowed to be executed anymore by means
of fim that's functional inhibition manager the inhibition of these functionalities
can be configured and even Modified by calibration then we have diagnostic event manager
the diagnos
tic event manager also called as Dem handles and stores the events detected by
diagnostic monitors in both software components and basic software modules the stored event
information is available via an interface to other BSW modules or software components then
we have EO State manager the EO State manager module is a basic software module that manages
common aspect of ECU States specifically the ECU manager module initializes and de initializes
the OS schedule manager and the basic softwar
e module as well as some basic software driver
modules it also configures the ECU for sleep and shutdown when requested and lastly it manages
all the wakeup events on the is and lastly we have the autosar OS the core functionality of autosar
os shall be based on the osc OS the osac OS is an event triggered operating system this provides
High flexibility in the design and maintenance of autosar based systems the event triggered gives
freedom for selection of event to drive scheduling at run
time for example angular rotation local
time source Global time Source error occurrence Etc with this we have covered a brief on memory
service and system service of service layer thank you
Comments