AUTOSAR ARCHITECTURE

 Automotive Open Software Architecture (AUTOSAR) is a worldwide development partnership

of vehicle manufacturers, suppliers, service providers and companies of automotive, electronics,
semiconductor and software industries.
 It is a common features induced layered-architecture formed by major companies such as BMW,
Bosch, Continental. Siemens, Volkswagen etc.
 Formed with the objective to create and establish an open and standardized software architecture
for automotive electronic control units (ECUs).

 Why do we need AUTOSAR?

 The inclusion of electronics in vehicles have increased over time and have taken major
control over the various functionalities of vehicles. Due to this, it is necessary that all the
electronic components inside a vehicle work with proper co-ordination and
communication. This is where AUTOSAR comes in handy.
 Without AUTOSAR, it is evident that the application software becomes more dependent
on the base software, due to which any change in application software is not easy.
AUTOSAR separates hardware and software making it easy for application developers.
 AUTOSAR consists of abstraction layers that increase the flexibility of software
development.
 Increases the reuse of software modules across customers and feasible distribution of
development.

 Layered Architecture
 The major layers of AUTOSAR are:

Application software (ASW)

Runtime Environment (RTE)

Base software (BSW)

Microcontroller

1. Application layer: This layer supports the implementation of custom functionalities

and consists of specific software components and many applications. Example: GUI
(Graphical User Interface), Task manager etc.
 Base Software (BSW)
It consists of standardized and ECU specific components (components directly interfaced with
the microcontroller) and provides services to software components. It is classified as the
following:

Service layer

Complex
ECU Abstraction layer device
drivers
(CDD)
Microcontroller Abstraction layer
(MCAL)

These layers are further classified as the following:

System Memory Crypto Off-board Comm I/O

services services services communication services hardware
services abstraction
On-board Memory Crypto Wireless Comm CDD
device hardware hardware communication hardware
Abstractio abstraction abstraction hardware abstraction
n abstraction
MCU Memory Crypto Wireless Comm I/O driver
driver driver driver communication driver
driver

 Microcontroller Abstraction Layer (MCAL): This layer consists of the drivers that
have direct access to the microcontroller, internal peripherals and memory mapped
microcontroller external devices. This layer is hardware specific and roots access to
registers of the controller. It is further classified into I/O drivers, Communication
(Comm) drivers, Memory drivers, MCU drivers, Crypto drivers and Wireless
communication drivers.
 ECU Abstraction layer: This layer is a software interface to electrical values of specific
ECU to decouple higher level software from underlying hardware dependencies. It
provides interfaces to access all the features of an ECU like communication, memory, I/O
and so on. It is subdivided into I/O hardware abstraction, Comm hardware abstraction,
Wireless communication hardware abstraction, Crypto hardware abstraction, Memory
hardware abstraction and On-board Device Abstraction layer.
o Comm hardware abstraction layer: This layer provides equal mechanisms to
access a communication channel regardless of the location (on-chip or on-board).
o I/O hardware abstraction layer: This layer provides access to I/O drivers by
mapping I/O hardware abstraction ports to ECU signals.
 o Memory hardware abstraction layer: abstracts from the location of peripheral
memory devices. Memory drivers are accessed via memory specific interfaces. It
provides equal mechanisms to access internal, on-chip and external on-board
memory devices.
o On-board Device Abstraction layer: It contains drivers for ECU on-board devices
which are not present on the chip. This layer is ECU specific.
o Crypto hardware abstraction layer: This module abstracts the crypto functionality
by hiding the information of the Crypto used (internal, external device or
software based).
 Service layer: This layer provides independent interface of a MCU and ECU hardware to
application software. It is subdivided into:
o System services: This provides services related to Operation System (OS),
Interrupts, counters, safety control units, built-in self-test and so on. These
services are used by all layers but some services are microcontroller dependent.
o Memory services: These services are responsible for the management of non-
volatile read or write from different memory drivers. These provide non-volatile
data to the application software and also mechanisms for non-volatile data
management (saving, loading, checksum protection, etc.)
o Crypto services: These services play an important role in the security aspect and
prevent unauthorized access to the ECU data. It checks if data is from trusted
source or not and takes care of threats.
o Communication services: These services help establish communication
(application to application or system to system) and are responsible for vehicle
network management. Here, applications can be a part of other ECUs. It is
interfaced with communication drivers via the communication hardware
abstraction layer.
o Off board Communication Services: These services are responsible for vehicle to
outer client communication via a wireless network. It has three blocks used for
implementing different functionalities. This module provides a uniform interface
for Wireless Ethernet network by hiding protocol and message properties.
 Complex device drivers: This is a special layer that fulfils functions and timing
requirements for handling complex sensors and actuators. It is used to create drivers for
hardware that is not supported by AUTOSAR. It is a part of BSW because these drivers
must interact with other general features.

 AUTOSAR INTERFACES
1. AUTOSAR interface: It is a generic interface derived from configurations provided by the RTE
and serve as an interface between the various application software or application software and
base software. For example, application software can read or write data via these interfaces.
2. Standardized AUTOSAR interface: It is pre-defined by AUTOSAR standards used by application
software for access to AUTOSAR services provided by the BSW modules, like ECU state
manager etc.
3. Standardized interface: It is pre-defined by AUTOSAR standard as an API in C language. It is
utilized between BSW modules or between RTE and BSW modules.
 Software Component (SC)
SC is organized in self-contained units called Atomic Software Component Types (ASCT).
ASCT represents functional implementation of applications. These small components together
form the functional implementation of software. Software components are classified as:

1. Atomic Software Component Type (ASCT):

a. Application Software Component: This is the most pre-dominantly used atomic SCT in
an application. It is generic and holds different functionalities of software. For example,
calculations, functions, decision making. Functional implementations can be placed in
application software component.
b. NV Block Software Component: it is used whenever we run into a requirement to save
critical information in the hardware memory, that needs to be reused in the future. It acts
as a bridge for the application software to access the NVM manager of BSW. NVM
stands for Non-Volatile Memory that can save stored data even after power off and can
be restored during power on. NVM manager is responsible for storing data in NVM
memory during start-up.
c. CDD: This helps application access hardware in a faster way, mainly when we have time
critical features where the communication through different BSW layers takes time. It
also acts as a layer to access few standardized interfaces on the BSW that AUTOSAR has
not specified access from the application layer.
d. Service Software Component: It is used from BSW to provide services to application
layer. It takes few special roles that cannot be a part of the system configuration and is
bound to ECU level. It provides configuration services for particular control unit.
e. Service Proxy Software Component: It is used when a particular service is to be used
from a different control unit. AUTOSAR says that an application component can be
dynamically placed on different ECU during system configuration. In such cases, the
access to the BSW might be on a different ECU. In such a case, Service Proxy
Component can be used.
f. ECU Abstraction Software Component: It is part of BSW and acts as an interface
between MCAL and application layer. Also used to access external peripheral drivers.
g. Sensor Actuator Software Component: this is the opposite connecting end of the ECU
abstraction software component from the application side. It acts as the interface between
external sensor/actuator to the other application component. It takes care of the
conversion of the raw data from sensors. For actuators, it takes care of controlling and
sequence based on input.

2. Parameter Software Component Type (PSCT): it is used to provide calibrations for a

project via provider ports. These calibrations can be used in all other SWC but has no
functional contribution.

3. Composition Software Component Type (CSCT): It is a non-functional collection of

software components used to cluster components based on functionality. It contains important
set of component configurations, tools and communication between them. A composition can
also cluster other composition.

 EXAMPLE 1: Consider the following functional requirements:

 i. Get speed from speed sensor.
ii. If speed is more than a calibrated set point the cut-off injection immediately.
iii. Save the maximum speed recorded to the NVM memory.

Solution:

ASW
Sensor Application NV Block Parameter
Actuator SWC SWC SWC
SWC

RTE

ECU Diagnostic NVM CDD

Abstraction Manager Manager
SWC
BSW

Microcontroller

Speed sensor Flash Injector

connected to memory
microcontroller port

Speed input Max speed

Injection trigger Calibration

a. ECU Abstraction SWC: reads corresponding I/O pin and calculates the count information
of pulses that speed sensor provides.
b. Sensor/Actuator SWC: interacts with the ECU Abstraction layer and gets sensor pulses.
Calculates the speed based on sensor input. This component can be programmed to
calculate speed in different units (km, m), that can be further used by application SWC.
c. Application SWC: performs core logic of requirement that is to cut off engine when it
crosses a particular speed. It gets the calculated speed from sensor/actuator SWC and
does further processing.
 d. Parameter SWC: for core calculations, we need calibration parameter which is required
by the application side to decide high speed cut off value. This block provides the
calibration parameter to the application SWC.
e. CDD: since requirement mentions that the injection must be cut-off immediately, there
should be no delay in this operation. CDD takes the cut-off command from the
application SWC and sets the corresponding I/O pins of controller to cut-off injection
immediately.
f. Diagnostic manager: comes as part of BSW development. Application component will be
connected to this service component and in case an error occurs, application component
can pass on the information to the service component. This error entry is taken care by
the BSW diagnostic manager.
g. NV Block SWC: This application software calculates the maximum speed and stores in
NVM. A NV Block is created for this application and this gets data from application
SWC and passes on to the NVM Manager of BSW. To save data, ECU has external flash
IC which will be handled in the BSW layer like the memory abstraction layer. During
startup, NVM handles storing saved data from the external memory and passes it on to
ASW layer using NV block component.

 AUTOSAR PORTS AND PORT INTERFACES

Ports are the connecting points for communication as per AUTOSAR. It is responsible for
carrying information across the SW component. According to AUTOSAR, there are three types
of ports:
a. Provider port (P-port): used when information has to be sent from SW component.
b. Receiver port (R-port): used when information has to be received from other components.
c. Provider Receiver port (PR-port): used to send and receive the source information from a
component simultaneously.
Port interface decides the kind of information communication on the port. There are six types of
interfaces we can choose based on the information:
a. Sender Receiver Interface (SRI): used for communication of data between ports. Data can
be any information in terms of primitive and complex types such as int, float, array,
structures. To send data, components should have a provider port defined with the SRI. On
the receiving side, there must be a receiver port with the same SRI definition to receive data.

P-port R -port

b. Client server interface (CSI): used to communicate or access services from other
components. If a particular component has a function and this has to be called from other SW
component, then CSI can be used. The component that owns the function will be called the
server and this will have the provider port. The caller or user to the function on another
component will be the client and will have a receiver port.
 U
P-port R-port

c. NV Data Interface (NVDI): used by NV Block components to establish communication

between NVM Interfaces with other components. To write data to NVB, provider port is used
from Application SWC and a receiver port is used at the NV Block SW. When data is to be
restored from NV Block memory, the NV Block component will have a provider port with
NV interface and this will be received by other SWC with opposite receiver port on its end.
d. Parameter interface: used to exchange calibration parameter across components. It can also
be used for data interfaces which are constant (does not change during run time). A parameter
SWC is used to share calibration parameter to other component through this interface.
e. Mode switch interface: used when there are pre-defined system states for a functionality.
For example, consider the states of a vehicle headlight such as ON, OFF, ON with high beam,
ON with low beam. The provider port will calculate and decide which mode of light is to be
lit and the receiver port will take the action based on the decision taken by provider.
f. Trigger interface: used to trigger a functionality on another component when an event
occurs. The component that takes the trigger decision will be the provider port and the
component that triggers the functionality from outside will be the receiver port.

 Sender-Receiver Interface (SRI)

Model for asynchronous communication of data where a sender distributes information to one or
more receivers. The sender neither expects nor gets a response from the receiver. The sender
sends information and the receiver decides autonomously when and how to use the information. –
- RTE is the common infrastructure which is responsible to distribute information to the
receivers.
- When a SWC wants to send data, we create a provider port on that component and if a
component wants to receive, we create a receiver port and connect it to the provider.
- The communication can be one-on-one (one provider and one receiver) or one-on-many (one
provider and many receivers) or many-on-one (many providers and one receiver). Many-on-
many communication (multiple providers and receivers) is not possible.

SWC-1 SWC-2

SWC-4 SWC-3
a. From the configuration site, first create SRI and specify the data to be communicated in the
variable data prototype.
b. Additional properties like units, computational methods can be provided from the application
primitive or application record data type with SRI.
c. Multiple data can be sent on the same port. We can specify multiple variable prototype in the
same SRI.
d. Then create port on the component and link this created SRI to it. This completes the SR
configuration and port linking.

 Client Server Interface (CSI)

CSI is used for function calls or services across components. Service can be defined as a simple
function on a module meant to be called from other modules.
- Server is the provider and clients are the users of the service.
- Client initiates the communication request and the server performs the service while
transferring a parameter set, if necessary. The server waits for an incoming request from the
client and dispatches a response to the client’s request.
- A single component can be both client or server depending on the SW realization.
- There are two methods of client calling:
a. Synchronous call: here, the client is blocked until the results are returned from the
server. It is used when the client wants to use the server function and expects its
results immediately for further processing.
b. Asynchronous call: this is a non-blocking call. The client calls the server function
and does not stop until the function is executed. It triggers the function and proceeds
to the further part of the code. The results are read and processed later by the client.
- CSI allows only one-on-one and one-to-many communication.

SWC-1 U SWC-2

Server P-port Client R-port

void sum(x, y, s) Calls sum function
{ s*=x+y; }

- Configuring a CSI: a) Create a CSI and a CS operation inside the interface which creates a
server operation. The server operation must contain the arguments definition with the
direction of the argument like IN, OUT or INOUT.
- We can mention multiple CS operation with a CSI. This is similar to an SRI where data and
operation can be clubbed together to the same interface definition.
- Create a provider port for the server and a receiver port for the client and map the CSI to it.
This completes the CS configuration.
  EXAMPLE 1.a: Continuation of EXAMPLE 1 with respect to the AUTOSAR
interfaces.
a. ECU Abstraction SWC: Passes the data coming from the sensor to the application
SWC. For this we can use a SRI. The ECU Abstraction will have the provider port
and the Sensor/Actuator SWC will have the receiver port.
b. Sensor/Actuator SWC: this calculates the speed and sends it to other application
component through the same SRI, since it’s only data communication.
c. Application SWC: this receives the cut-off calibration from the parameter SWC to do
further calculations. We can sue a parameter interface to get the calibration
information. The maximum speed interface that the ASW component needs to write
to the NV Block component can take the NV interface type for this communication.
d. NV Block SWC: the communication between NV block and the BSW NVM manager
happens through CS communication because the BSW is usually a service.
e. Diagnostic manager: to log a diagnostic entry, we will use a CS communication since
this is also a BSW service that’s offered from diagnostic module.
f. CDD: to cut-off injector, we pass data command to the CDD. This command can be a
single data to communicate, so we can use SRI.

 Compositions and connectors

A SWC type that clusters or aggregates SWC or compositions.
- Connectors: completes the connection between port prototypes. Some types are:
a. Assembly connectors: used to connect two ports with in the same composition. It binds a
provider and receiver port in it but it is a must to have the same parent composition.
b. Delegation connectors: the inner ports of components are extended to the other
composition and connected to each other using these connectors. This creates a
connection between composition and ports. It connects the same port type, that is,
provider to provider or receiver to receiver.

Composition 2

U
SWC-3
U

SWC-1 SWC-2

Composition 1

Assembly connector Delegation connector

 Runnable or Runnable entities
- The smallest segments of code defined on a component or can be defined as individual
functions on a SWC.
- Each function on a C file will have to be defined as a runnable in AUTOSAR configuration
and it should also specify the interface access within it.
- The runnable entities together with events are scheduled by the operating system (OS).
- A composition SWC or parameter SWC cannot have a runnable, since they don’t have an
associated C file functionality with them.
- There are two ways to configure RTE to communicate with messages:
a. Explicit communication: the data passing over ports are sent and received as it is and
the RTE does not care about the message consistency.
b. Implicit communication: the RTE takes care of the message consistency across
receivers by creating dedicated message buffers for each receiver.

- Runnable properties:
a. If runnable is accessing any SR/NV interface, the below configurations are
applicable:

Data read access (implicit) R-port

Data write access (implicit) P-port
Data receive point by value R-port
Data receive point by argument R-port
Data send point P-port

b. Parameter accessed from runnable: parameter can only be read and not written,
hence:

Parameter access R-port

c. Mode switch interface: either set or access mode.

Mode access point R-port

Mode switch point P-port

d. Local interface: read local variable and write local variable have no port since they
are not going to be sent/receiver from external components. They will have interface
defined within the scope of the component.

e. CSI: client can call server synchronous or asynchronous.

Asynchronous server call result point R-port

Synchronous call point R-port

f. Triggers: external or internal trigger point is used.

- Note: runnable can be invoked concurrently, that takes true or false input that mentions if
runnable is to be called recursively or parallel on different tasks. This is important when OS
is scheduling runnable.
 Events
- Events are additional configurations to a runnable that specifies the OS on how to call or
schedule a runnable. Runnables are mapped to the RTE events and further the OS and RTE
layer together ensure that the runnable function is called in an expected manner.
- In case OS needs to start a runnable when the corresponding event occurs, the RTE event can
directly reference the runnable that needs to be started.
- When the SWC description uses this feature, it is responsible of the OS to start the runnable
when the event occurs.
- Consider the following categories of events:
a. Init event: specifies that the runnable is meant to be called only once and the runnable is
only for initializing the software during start up.
b. Timing event: used when the OS needs to call the runnable in a timing period. For
example, if we need to call a runnable every 100ms periodically then a timing event is
created and this runnable is mapped to it. OS calls this runnable based on the timing
period.
c. External trigger occurred event and internal trigger occurred event : here, the runnable is
called when a trigger event occurs. This is associated with the trigger interface type when
we expect triggers to occur.
d. Background event: used for runnable that need to be run in the background. The OS will
call the mapped runnable to a background event while the core is idle.
e. Operation invoked event: used on the server side of the Client-server communication. It
mentions the runnable to be called when a client requests a server execution through a
synchronous or asynchronous call.
f. The asynchronous server call result event: it is raised when an asynchronous server call is
finished. The associated runnable to this event is called when this event occurs.
g. Data write complete/data send complete event: this is associated with the provider port. It
mentions to call a runnable when data has been sent on a P-port.
h. Data receive event/ receiver error event: it is associated with R-port and triggered when
data is received on a port or when there is an error during reception. It is mainly used for
runtime optimization that a function is run only when needed and not always.
i. Mode switch event: it is used when there was a state change in a particular mode and to
trigger the associated runnable when it occurs.
j. Mode manager error event and Mode switch Ack event: it is used in case of error or when
mode switches are acknowledged.

 Application Software (ASW)

An application software component (ASWC) consists of two files:
a. C file: that comprises the functionality of the component.
b. Config file (ARXML): this will associate the functionality of the component. It consists of
the following:
o Ports: contains the list of ports applicable for the software component. Includes P-
port, R-port and PR-port. Each port is associated with one interface each. The
interface can be any type as discussed previously.
 o Internal behavior: represents the characteristics of the SWC. It mainly deals with the
RTE and includes events and runnables.
o Software component implementation: describes the properties of SW like the design
vendor, delivery information, resource consumption etc.

 Run Time Environment (RTE)

- All interfaces between ASW components or ASW and BSW have to go through RTE. It
accesses the system level communication center for inter and intra ECU information
exchange.
- It also takes care of the message consistency while passing interfaces across applications
irrespective of whichever core the belong to.
- It is responsible for scheduling runnable. Events configured on ASWC are handled from the
RTE and it checks if the runnable is called accordingly as mentioned in the event
configuration.

a. RTE APIs – Sender Receiver Interface

- P-port and R-ports are defined in configuration and are mapped to SRI. We need to call the
functions from configuration to the C file using the AUTOSAR standards as mentioned in the
“AUTOSAR_SWS_RTE.pdf” on the official website.

b. RTE APIs- Client Server Interface

- Refer to the CSI functions mentioned in the AUTOSAR document.

c. RTE Communication
- Consider the following block diagram:

ASWC 1 ASWC 2

(function call) (function call)

RTE (Function definition)

BSW

- Consider two SWC that need to communicate with each other via RTE.
- ASWC 1 has P-port to write data out and a function that writes data to RTE through
AUTOSAR Interface or RTE API. RTE defines the APIs mentioned in the component and
has the functional implementation for this. It defines an interface from its side and takes a
copy of this interface that ASWC 1 provides.
 - ASWC 2 has a runnable function to read the data from ASWC 1. It uses RTE to get the data
via interface. RTE implements the receiver API to copy its interface data to the pointer that
was passed to the application.

d. RTE Scheduling
- We know that every runnable has to be mapped to an event.
- Consider function 1 is mapped to a timing event and function 2 is mapped to a data receive
event where we run the function only when new data arrives.
- A separate RTE configuration is required for the scheduling activity which will be done at the
final stages of the development process in the system development. This is called event to
task mapping in RTE configuration.
- We map timing event from C1 to the function CalcTask and data receive event to ReadTask.
Based on this configuration, RTE will create task bodies for every individual task that is
configured.
- RTE will add a prefix Rte_Task to every task it creates and follows with the name of the task,
such as Rte_Tak_CalcTask(), which will then be added to the OS scheduler. This is how RTE
generates the task names by the definition from the configuration.
- The task definition will contain the mapped runnable.
Example: function 1
Rte_Tak_CalcTask()
{
function1();
}
- For receiver function, RTE will add a flagging mechanism to make sure that this function is
called only when data is received on this port.
Rte_Task_ReadTask()
{
if(DataReceiveFlag==1)
{
function2();
DataReceiveFlag=0;
}
}

DataReceiveFlag is mentioned in the RTE API write function. The flag is set whenever there
is new data.

e. RTE Generator
- RTE layer is mostly generated out of configurations and needs special generation tools that
follow AUTOSAR standards.
- The inputs for this generator are ARXML configurations which include:
o SWC description: configurations from SWC development.
o ECU extraction configuration: configurations relevant to a particular ECU
o RTE and ECU OS configuration: comprises of OS task containers and map event
to task for a particular SWC.
o ECU instance configuration: contains description of the corresponding controller
unit.
 o BSW configuration for BSW modules.
- These inputs are passed to RTE Generator that analyses the AUTOSAR configuration and
produces the RTE APIs and RTE layer.
- The outputs of the generator are:
o RTE layer .c files
o Application specific headers for each SWC.
o Additional configuration files:
 OS related arxml configuration: has scheduling information of the tasks
created by RTE. This is further processed by the OS tools to do scheduling.
 IOC related arxml configuration: IOC or Inter OS Communication is a
extraction that has communication passing over course or partitions. The OS
will use this information to transfer interfaces.
 McSupportData.arxml: has information of the measurements and calibration.
It is used for debugging purposes to view or modify interfaces during testing.
 BswMD.arxml: has the information of memory mapping for RTE generated
interfaces.

 AUTOSAR methodology

1. System level development: includes SWC, HW selection, ECU resources, overall system.
These SWC are interfaced via VFB or Virtual Function Bus. VFB is the sum of all
communication mechanisms and interfaces to the BSW provided by AUTOSAR on an
abstraction level. VFB allows a virtual integration in an early development phase. All the
development on the system level and HW ECU related configurations are to be developed for
the particular system. Then we map SWC that are already developed on the system level to
particular ECUs.
2. ECU Extraction: extracts only ECU specific information from the system and can be done for
only one ECU at a time. The output of this stage are 3 files:
a. Flatview.arxml: contains the flattened list of components from system and the
communication connectors between them.
b. Flatmap.arxml: contains the instances for all interfaces and components for that
particular ECU. It is used for calibration and measurement purposes.
c. ECUExtraction.arxml: contains the ECU signals, signal mapping, SWC
implementation and ECU mappings.
3. ECU Configuration: contains the ECU specific configurations. The event to task mapping
where we map events from developed SWC to the OS tasks are performed here. Assigns the
developed components to the particular course or partition on the same ECU.
4. Generate RTE layer for ECUs: firstly, pass all the developed configuration arxmls to the RTE
generation tool and this will create the complete RTE layer for each ECU. The
communication between the ECUs are managed by RTE through the configured
communication channels.

 Classic software (no AUTOSAR)

- ASW and HW are tightly coupled.
- Complete SW has to be changed for any HW changes.
 - Cost of SW development is too high.
- SW is not reusable with different HW.

 Practical use-case of AUTOSAR (Cooling fan)

- Requirements:
a. ASW: ASWC to control fan based on temperature. This component will make decisions
on when to switch ON fan based on the temperature read from sensor.
b. Drivers (I/O Abstraction): H-bridge driver and temperature sensor driver. Interacts with
ASW via I/O signal interface and RTE.
c. HW pins (I/O driver): 3 digital IO ports and an ADC port. Includes DIO, Port and ADC
drivers.
- MCAL layer:
1. Controller pin configuration: we need 1 ADC channel and 3 I/O Channels. For this we
configure the Port driver that follows AUTOSAR standards. Documentation available:
‘AUTOSAR_SWS_PortDriver.pdf’, ‘AUTOSAR_SWS_DIODriver.pdf’ and
‘AUTOSAR_SWS_ADCDriver.pdf’.
a. Port driver: contains DIO and ADC configuration.
b. DIO driver: write the driver function for basic I/O to read from and write to I/O pins.
The AUTOSAR standardized functions we will use here are:
Dio_ReadChannel() and Dio_WriteChannel().
c. ADC driver: uses functions that trigger ADC:
Adc_StartGroupConversion()-> triggers ADC conversion.
Adc_ReadGroup()-> reads back the converted data.
2. MCAL layers are tightly bound with HW and this will change every time there is a
change in HW. The other upper layers are not usually modified in this case.
- I/O Abstraction:
1. Temperature sensor: for this we introduce a temperature sensor abstraction component
that interacts with the lower ADC driver to co-ordinate the signal conversions and read
back the data. The data read back will be the raw value from the ADC and we can have
the offset adjustments, internal conversions related to temperature, signal conversion, etc.
Based on configuration, once conversion is completed the ADC driver can request a call
back to these layers to pass the data to this abstraction layer. The function to read
temperature is given by:
void ReadTemperature()
{
ADC_StartGroupConversion(1);
ADC_ReadGroup(1, &data);
Result = (*data x 0.5); //raw data to degree Celsius
}
2. H-Bridge Abstraction: we use I/O pins of controller to access H-bridge IC, so we interact
with the I/O drivers. DIO ports are directly written with high or low based H-bridge
configuration to switch ON/OFF the cooling fan. In H-bridge abstraction, we introduce
two functions to start or stop the fan:
a. StartMotor()
{
Dio_WriteChannel(Id, Std_HIGH);
 }
b. StopMotor()
{
Dio_WriteChannel(Id, Std_LOW); }

- I/O Configuration: here, we define the port and port interface required to pass the
information to the upper application layer through RTE.
a. From temperature abstraction function, the function triggers the ADC conversion and the
ADC result from the temperature sensor is placed in a variable called Result. To pass this
result to upper application layer, we require a SRI with a P-port to write this data to RTE.
b. On H-bridge abstraction side, we have two functions start and stop. Since these functions
must be called from the application, we use a CSI with a P-port. This abstraction layer
owns the function and this will be the server side.

Cooling fan SWC

RTE

P-port Server P-port Server P-port SRI

(StartMotor) (StopMotor) (Temperature)
I/O Signal Interface

void StartMotor() { … } void ReadTemperature()

void StopMotor() { … } {…}

DIO Driver Port Driver ADC Driver

Dio_ReadChannel(Id) { … } DIO configuration ADC_StartGroupConversion()

Dio_WriteChannel(Id, level) { … } ADC configuration ADC_ReadGroup()

Microcontroller

 ARXML
- ARXML stands for AutosaR eXtensible Markup Language. It is a configuration file used by
AUTOSAR.
 - In the ARXML file, all the configurations related to AUTOSAR should start with the tag
“AUTOSAR”.
- We can mention the attributes of the version of AUTOSAR that we use and also the
corresponding schema. These are constant for the entire project.
- All the configurations must be inside <AR-PACKAGES>. Packages can contain any number
of packages inside and we are free to club or categorize configurations based on our uses or
applications and we can place them on different AR packages.
- In order to name an AR-PACKAGE, we follow the format: <SHORT-NAME>NAME OF
THE PACKAGE</SHORT-NAME>
- All the configurations relevant to AR-PACKAGES are placed within <ELEMENTS>.
Elements usually include the reference to the location of the child (configurations).

 Working with XML Editor (XMLSpy)

- Firstly, finish the installation and include the license (free-trial available). Download the
AUTOSAR Standards version 4.4.0 from the link: https://www.autosar.org/standards/classic-
platform/classic-platform-440/
- Create a folder on your PC for the project. Create sub-folder for each layer such as MCAL,
Interfaces, ECU Abstraction, AUTOSAR Schema and ASW. These folders must
include .c, .xml and .h files (as per requirement).
- The AUTOSAR schema file is a .xsd file and is found in the AUTOSAR Standards .zip files
downloaded previously. Go to MethodologyAndTemplates >
AUTOSAR_MMOD_XMLSchema.zip folder and include this folder in the project folder on
your PC. The file “AUTOSAR_00046.xsd” contains the AUTOSAR Schema.
- Create a new project on XMLSpy. Right click on the project > select ‘Add External folder’>
select the project folder created on your PC. Move this project folder under the category
XML files.
- Start from the MCAL folder under the project and write the software for all the .c and .xml
files under all the layers’ folders.
- It is mandatory to integrate the AUTOSAR schema for each .xml file. To do so, select the
project and then navigate to DTD/Schema > Assign Schema > OK > Select .xsd file from
AUTOSAR_MMOD_XMLSchema file in local project folder > OK.
- A Composition.xml file must be included in the project folder, locally. Then right click on the
project name in XMLSpy and click on ‘Refresh’.
- The following lines must be common and present in all the .xml files in our project:
<AUTOSAR xmlns="http://autosar.org/schema/r4.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://autosar.org/schema/r4.0 file:///PATH">

NOTE: PATH = path to the “AUTOSAR_00046.xsd” file in your Local project folder.

- This completes the AUTOSAR architecture of all the layers for our use-case but the RTE
layer can only be generated using specialized software applications that are not easily
available and are expensive.