Application Software Component

Validation R 3.x ASAM HIS-MISRA

Migration COM
Standardization
Microlayerdrivers
VCI R4.x
Migration R 3.x ARTOP RTE generation CAN Customizable
MBD Consulting Testing CoE HIS-MISRA
eNOSPartner Testing MCAL
ECU R 3.x In-vehiclenetwork BSW stack Configuration OSEK R 3.x

R 4.x
Validation Tool chain Gateway
drivers R 3.x Partial OSEK
Mode Migration Training
ISO 14229 MCD3 API
Standardization
MBD Management MBD
Network VCI
Network
Management

OTX OSEK
Networking ASAM CT-Spec Network
Consulting

AUTOSAR
CT Specs Management
Hazard Analysis MCD3 API Gateway
ASAM Tool chain Training Hardware Management MBD
ECU eNOS AUTOSAR MBD Tool qualification ASAM Training VCI MBD ASAM Optimization
FUNCTIONAL SAFETY

drivers ECU CT Specs MCAL Tool qualification MBD HardwareASAMValidation

Network

In-vehicle network ASIL A, B, C, D Management

ECU
Migration Validation Partial ISO 15765 MBD Management
Mode ECU
MBD
esting Validation Adaptation CAE RiskAssessment Validation Scalablility MBD
Specifications T
Complex
Drivers

CT Specs eNOS R 4.x In-vehicle CT BSW Stack OSEK hardware MCAL Networking MCD3 API
Partial Networking
Testing Optimization
ECU network R 3.x ODX BSW stack ECU ISO 26262 ASAM ISO 14229
DIAGNOSTICS
Production Ready MBD
Testing
Frugal drivers R 4.x drivers
MBD
PDU RouterASAM

Engineering eNOS AUTOSAR ECU Migration MCD3API Bootloader Production Ready

ODX
Gateway
CT Specs
porting Validation VCI LIN
ECU Specifications eNOS AUTOSAR OSEK hardware Tool chain Mode Management Training ISO 26262 NETWORK Migration
Migration OSEK
Validation
Legacy to MBD BSW Stack Validation Hardware ASAM Portability
ISO 15765 Training Configuration

Microlayer ECU hardware hardware ISO26262 HIS-MISRA Hardware Diagnostics MBD ASAM Validation
Legacy to MBD CT-Spec MBD
Mode Management Testing CoE MANAGEMENT
ECU
Testing Diagnostics Board Support
eNOS Network Management

ReNOS
4.x Efficient

FUNCTIONAL SAFETY
C AN Complex
OTX ODX Complex Drivers
Production Package Drivers
Tool chain Ready
ODX
CT-Spec
Customizable HIS-MISRA
Consulting
Scalablility LIN Gateway VCI DoIP
ECU Risk Assessment Optimization
drivers Gateway
Network Management
Training
HazardAnalysis
Gateway
Validation
Scalablility
CT Consulting
Diagnostics&
PC ToolsTraining Remote Diagnostic ECU
Consulting
SCALABLILITY
Validation
C onsulting

Toolchain
DoIP ASIL Decomposition
MBD R3.x
HIS-MISRA CT-Spec
AUTOSARCT-Spec BSW stack
ODX ISO 14229
Validation MCD3 API
TestingCoE
MBD ASAM ISO 26262 OSEK Partial

Hardware
ISO 15765
porting TestingCoE
Migration OTX Risk Assessment Mode Management BSW Stack Complex Drivers COM
Optimization
Networking

VCI MBD
Partial Networking
ASAM ARTOP Training ECU eNOS Bootloader [Link] Networking
Aftertreatment
porting ASAM MBD
Gateway
Microlayer FUNCTIONAL SAFETY Tool Optimization
Consulting
Scalablility

VCI ASIL Decomposition Efficient ECU

Qualification
DoIP ASILA, B, C, D
CT-Spec
BSW Stack
ToolQualification ARTOP DIAGNOSTICS hardware
MCAL
ASAM
Risk Assessment MBD ASAM
Migration
Customizable
Migration DoIP Hazard Analysis
ECU LIN ODX OSEK
AUTOSAR Consulting
AUTOSAR Powerseat DoIP
Validation FUNCTIONAL SAFETY drivers eNOS
Mode
ECU Risk Assessment COM Bootloader ISO 26262 MBD
ECU Validation
ODX
ECU RTE generation Error handling AUTOSAR Management CT-Spec OSEK
PDU Router
Production Ready MCAL ISO 15765 CT-Spec
ISO 15765 Power Window Bootloader Network Management Validation
Development COM
porting MCD3 API
Scalablility MCD3API
Training Tool Qualification CAN Error handling ASAM

ISO 15765
LIN R4.x ODX FUNCTIONAL
CT-Spec Production Ready HIS-MISRA
Portability Configuration ODX
Gateway
ISO 14229
SAFETY LIN
Validation OSEK Scalability
M BD
Gateway ASIL Decomposition
ISO 14229
ARTOP ODX DoIP

CAN Bootloader LIN CAN

Pic source: Google

Agenda
• AUTOSAR Layered Architecture and Methodology and Tools
• Building AUTOSAR Application Software Component
development (M2 level)
• Building RTE and Configuring with OS and integrating with
ASWC
• Understanding the modules of the BSW stack
• COM Stack
• Mode Management
• Memory Stack
• IO Stack
• Diagnostic Stack
• CDD
• Other Modules in AUTOSAR- WDG, Microcontroller services
 AUTOSAR Architecture

APPLICATION LAYER

RUN TIME ENVIRONMENT

B S
SERVICES
A O LAYER
S F
I T COMPLE
C W ECUABSTRACTIONLAYER
A X
R DRIVERS
E MICROCONTROLLERABSTRACTION
LAYER

MICROCONTROLLER
Overview
Objective
• Understand the architecture of AUTOSAR
• AUTOSAR enabling with tools
• AUTOSAR enabling with documents
Why AUTOSAR?
Why AUTOSAR?
• Automotive Industry coping up with increasing complexity
• Software must often be rewritten from scratch when hardware is
changed.

• BSW Standardisation: OEM will prefer to pay only for Application

Software but not for the BSW.

• Hardware Abstraction: The software developer can now focus on

building the application than on worrying about configuring the micro
controller.
• Reusability of functions: across vehicle networks and across OEM
boundaries. One of the biggest challenges faced by the OEM was when
an OEM wanted to add a function to an existing ECU it required a lot
of effort.

• Standardization of exchange formats: Interfaces has been

standardised.
Why AUTOSAR?
What is AUTOSAR?
AUTOSAR Consortium
What is AUTOSAR?
• AUTOSAR – AUTomotive Open Systems ARchitecture

•Middleware and system-level standard, jointly developed

by automobile manufacturers, electronics and software
suppliers and tool vendors.
• More than 100 members

• Motto: “cooperate on standards, compete on

implementations” Reality: current struggle between OEM
and Tier1 suppliers

•Target: facilitate portability, composability, integration of

SW components over the lifetime of the vehicle
AUTOSAR Architecture
 AUTOSAR Architecture

APPLICATION LAYER

RUN TIME ENVIRONMENT

B S
SERVICES
A O LAYER
S F
I T COMPLE
C W ECUABSTRACTIONLAYER
A X
R DRIVERS
E MICROCONTROLLERABSTRACTION
LAYER

MICROCONTROLLER
AUTOSAR Architecture
AUTOSAR Basic Software Module
AUTOSAR has defined a set of BSW modules. They are
responsible for different tasks:
• Operating System
• Access to non volatile memory
• Communication via CAN, LIN, FlexRay and Ethernet
• Handling the diagnostics
• Access to I/O ports
• System services like ECU statemanagement
• In addition, so-called Complex Device Drivers can be
integrated into anAUTOSAR ECU. They are used to
access the features of the ECU, which are not covered by
the standard BSW ofAUTOSAR
CAN Stack Architecture vs AUTOSAR
AUTOSAR Methodology
AUTOSAR Methodology- Tools Perspective
AUTOSAR Interfaces
AUTOSAR Interfaces
AUTOSAR Interfaces
AUTOSAR Interfaces are used in defining the ports of software-components and/or
BSW modules. Through these ports, software-components and/or BSW modules can
communicate with each other AUTOSAR makes it possible to implement this
communication between Software-Components and/or BSW modules either locally or
via a network.

• The AUTOSAR Interface is a generic interface which is derived from the ports of a
SWC. AUTOSAR Interfaces are provided by the RTE and serve as interface
between SWCs or between SWCs or between a SWC and the ECU firmware (IO
HW and Complex Drivers). Via these interfaces, a SWC can e.g. read an input
value or write an output value.

• Rte_Write_ledDial_ledData([Link]);

• The Standardized AUTOSAR Interface is an "AUTOSAR Interface” whose syntax

and semantics are standardized in AUTOSAR. Such interfaces are used by the
SWCs to access AUTOSAR Services, which are provided by BSW modules of
the Service Layer like the ECU manager or the diagnostic event manager.

▪ Std_ReturnType BswM_RequestFullComActionHandle(
constBswM_ActionListItemType *item );
▪ boolean BswM_ComMFullCommuncationlExpressionLogicalExpHandle( void );
 AUTOSAR Interface

• The Standardized Interface is an interface, which is predefined by the AUTOSAR

standard as API in C language. It is used between BSW module within an ECU,
between RTE and Operating System (OS), or between RTE and the Communication
Layer.
▪ Com_SendSignal(ComConf_ComSignal_CanTxSignal, &value);
▪ Com_ReceiveSignal(ComConf_ComSignal_CanRxSignal, value);
AUTOSAR Architecture
Virtual function Bus (VFB)
• The virtual functional bus is the abstraction of the
AUTOSAR Software Components interconnections of the
entire vehicle. The communication between different
software components and between software components
and its environment (e.g. hardware driver, OS, services,
etc.) can be specified independently of any underlying
hardware (e.g. communication system). The functionality of
the VFB is provided by communication patterns.
ASWC- Design Steps

VFB Level

RTE Level

Implementation
SwcImplementation Level
ASWC Design
Types of Software Components
• Software component: software component(SWC) Is a
piece of code that carries out an application or part of an
application.
• An atomic software component is atomic in the sense that
it cannot be further decomposed and distributed across
multiple ECUs.
• In AUTOSAR, software components are not limited to the
application layer, i.e. they also exist in the RTE and BSW
layer.
Types of SoftwareComponents
Types of SWC
• Application software Component is an Atomic Software
Component that implements (part of) an application
• Sensor Actuator Software Component is an atomic SWC
that handles the specifics of sensors or actuators. It
directly interacts with the ecu-abstraction
• A Composition Software Component encapsulates a
collaboration of Software Components, thereby hiding
detail and allowing the creation of higher abstraction levels.
Through delegation connectors a composition software
component explicitly specifies, which ports of the internal
components are visible from the outside.
• The Service Proxy SW Component is responsible for
distribution of modes throughout the system.
Types of SWC
• Service Software Component provides services specified by
AUTOSAR through interfaces specified by AUTOSAR. This
component may interact directly with modules from BSW.
• The ECU-Abstraction Software Component provides access to
the ECU’s specific IO capabilities. These services are typically
provided through client-server PPorts and are used by the
sensoractuator software components.
• Parametric Software Component provides parameter values.
They can be fixed data, constant or variable. It allows access
to fixed data or calibration data. They don’t have an internal
behaviour. They only have PPorts of ParameterInterface type.
Need to be on the same ECU as the SWCs accessing them
since a parameter SWC represents the memory containing the
calibration parameter
• The Complex Driver Software Component generalizes the
“ECUabstraction component”. It can define ports to interact
with other components in specific ways and can also
interact directly
• The NV Block Software Component allows SWC-S access
to non volatile data. Specifically this block allows for the
modeling of the NV data at the VFB level with other basic-
software modules.
Port Interfaces
• Client Server- The server is provider of operations and
several clients can invoke those operations
• Sender-receiver- A sender distributes information to one or
several receivers, or one receiver gets information (events)
from several senders
• Parameter Interface- A parameter interface allows software
components access to either constant data, fixed data or
calibration data.
• Trigger Interface- The trigger interface allows software
components to trigger the execution of other software
components. The purpose of the trigger interface is to allow
for fast response times with regards to the occurrence of a
trigger which might occur sporadic.
Port Interfaces
• Mode Switch Interface- The mode switch interface is used
to notify a software component of a mode. The mode
manager provides modes that can be used by mode users
to adjust the behavior according to modes or synchronize
activities to mode switches.
• Non volatile Data Interface- Provide element level access
(read only or read/write) to non volatile data as opposed to
NV block access.
Ports
• AUTOSAR Software Components may only interact with
Port Prototypes.
• A require-port (in technical terms: RPortPrototype)
requires certain services or data
• A provide-port (or PPortPrototype) on the other hand
provides services or data.
• A provide-require-port (or PRPortPrototype) combines the
ability to provide and require services or data in one entity.
Compatibility of Data Types
 Compatibility of Data Types

• ApplicationDataType Defined on M2 - provides the meta model for data types on

application level. It covers the application-relevant aspects of a data type. An
ApplicationDataType shall finally be mapped to an Implementation-DataType.
• ImplementationDataType Defined on M2 - provides the meta-model for data types
on implementation level. With respect to C source code, an Implementation-
DataType finally boils down to a typedef.
• BaseType Defined on M2 - provides the platform-dependent part of an
ImplementationDataType. the dependency on the platform covers the following
aspects: Definition on the level of the C language - using nativeDeclaration Technical
representation on the target platform (byte order, alignment, encoding) as required
for the support of MCD systems.
Seat Heater Controller- Use Case
Seat heater Controller -SWC
 Seat Heater Controller

• SeatHeatingControl

• Input:
• Whether a Passenger is sitting on the seat
”SeatSwitch”
• Setting of the seat temperature dial “Setting”
• Some information from a central power
management system “Power Management”

• Output:
• DialLED associated with the seat temperature
“DialLED”
• Heating Element to be Turned ON
“HeatingElement”
Sender Receiver Interface
Client Server Interface
Seat Heater Controller- VFB Design
Design and Communication of Software Components

•Client/ Server ports where server is a provider of a service and the

client is a user of a service
•Sender/ Receiver ports where a sender distributes information to
one or several receivers in synchronous as well as asynchronous
environment.
•The implementation architecture of SWC is formally defined
in terms of so-called runnable entities. They correspond to
procedures and are executed on a specific event such as a
periodic activation or reception of new input value.
•During system design phase the SWCs can be integrated
with their environment (e.g. hardware, driver, OS, etc) based
on Virtual Functional Bus (VFB).
•Atomic Software Component- Smallest software component
which will remain in one ECU only. Cannot be broken between
ECUs.
 Seat heater ASWC
Sender-Receiver
RPORT

Client – Server
RPORT

The Component
reads/consumes values
of data-elements The Component
requires operation
defined in theinterface
Client - Server
PPORT
Sender -
Receiver
PPORT

The Component
provides operation
The Component
defined in theinterface
provides values ofdata-
elements
Runnable Entities
Multiple Instances

two instances of the “SeatHeatingControl” component-type are used to control the left
front seat, respectively the right front seat. These components will typically have their own
separate internal state (stored in separate memory locations) but might for example share
the same code
VFB Design
Seat Heater Controller- Internal Behaviour
Runnable Entities
Runnable Entities
• Atomic Software Components contain
• Runnable Entities as part of their internal behaviour
• Function containing the actual implementation
• Function is called by the RTE is the corresponding trigger occurs.

• A software component can have one or more runnable

entities
• Runnables executed when RTE Trigger happens
Runnable Entities
• RunnableEntitys are the smallest code fragments
that are provided by a software-component.
• They are scheduled by the OS
• CompositionSwComponentType cannot have
RunnableEntitys.
• Only the AtomicSwComponentTypemay have
RunnableEntitys.
• It defines what to transmit/receive or control or
manage
Quick Reference
• SWC- the smallest logical unit of the application
• Ports (Port Prototypes) : the communication interfaces of
the SWCs.
• Data elements- the contents of the ports
• Runnables- executable code units of the application
• SWC mapping- assignment of SWCs to ECUs
• Data Mapping – assignment of data elements to the
application to bus signals
ASWC Design

AtomicSwComponent VFB Level

SWCInternalBehavior RTE Level

Implementation
SwcImplementation Level
Next Step
References
• AUTOSAR Virtual Function Bus

• AUTOSAR Methodology

• AUTOSAR Software Component Template

• AUTOSAR Architecture
Runnable Entities
Category 1 and Category 2 Runnable
• The RTE shall support the Runnable Entity categories 1a, 1b and
2 Runnable Entity category:
• 1a) The Runnable Entity is only allowed to use implicit reading
(DataReadAccess) and writing (DataWriteAcess). A category 1a
Runnable Entity cannot block and cannot use explicit read/writ
• 1b) The Runnable Entity can use explicit reading and writing
(DataReadAccess). A category 1b Runnable Entity cannot block.
Implicit read/write is also allowed.
• 2) The Runnable Entity may use explicit reading/writing including
blocking behavior.
• Implicit reading and Writing → Here the value of the variable
does not change during the execution of the runnable
• Explicit reading and Writing→ The value of the variable shall
be updated during the execution of the runnable.
 Category 1 Runnable- StateModel

The OS Scheduler
checks all the tasks
in the running and
Ready state and
decides which task
should be
started/preempted

ALARMS!!! – for
cyclical

Could be auto activated

with startOS or could be
activated by another
task
Activate Task()
 Category 2 Runnable

It can wait for an OS

event – OS Object
Concurrency
• In case the SwcInternalBehavior defines a RunnableEntity
as one that cannot be invoked concurrently it is the
responsibility of the RTE to make sure that the
RunnableEntity is never started concurrently.
• The software-component description itself does not put
any bounds on the number of concurrent
• Invocations of the RunnableEntity that are allowed. The
software-component description only specifies
whether the RunnableEntity can be invoked concurrently or
not.
• Allowing concurrent invocation of a RunnableEntity implies
that the implementation of the AtomicSwComponentType
needs to take care of this additional form of concurrency.
Concurrency
Example:
• The AtomicSwComponentType specifies that the RunnableEntity R1 can be
invoked concurrently. The AtomicSwComponentType MyComponentType is
instantiated on an ECU.
• When a call of the ClientServerOperation is received the corresponding
instance of the RunnableEntity R1 is enabled and the RTE will start executing
the RunnableEntity (the RunnableEntity is in state running) in a task eventually
managed by the AUTOSAR OS.
• If another call of the ClientServerOperation is received, it is allowed that the
same RunnableEntity is started again in a different task.
• A typical use-case of concurrent RunnableEntitys is the implementation of
AUTOSAR services. The AUTOSAR services will typically take care of
concurrency internally: several software-components can directly use the
services in parallel.
• The ECU-integrator could then decide that the RunnableEntity implementing
the AUTOSAR service runs directly in the context (in the task) of the
AtomicSwComponentType invoking the service.
Ways to trigger a Runnable
• Timed Activations
• RTE Events
Runnable Trigger – Timed activations
• In many cases, RunnableEntitys need to be activated in
response to timing events rather than related to
communication (e.g. the reception of a response to an
asynchronous operation invocation).
• Many RunnableEntitys will need to run cyclically with a
fixed rate invoking the service
Runnable Trigger- RTE Events
• The description of an RTEEvent includes two aspects:
1. defining an RTEEvent
[Link] how the RTE should deal with the RTEEvent when it
occurs.

• the RunnableEntitys of an AtomicSwComponentType can

interact with the occurrence of such RTEEvents in two
ways:
• the RTE can be instructed to enable a specific RunnableEntity
when the RTEEvent occurs
• the RTE can provide WaitPoints, that allow a RunnableEntity to
block until an RTEEvent in a set of RTEEvents occurs. (
Category2 Runnables)
Communication among RunnableEntities
• The RTE needsto provide synchronization mechanisms to
the RunnableEntitys such that safe (in the multi-threading
sense) exchange of data is possible.
• Two possible approaches for formal specification of this
kind of communication are described:
• Specifying that several RunnableEntitys belong in a specific
ExclusiveArea
• Specifying the data exchanged between the RunnableEntitys-
InterRunnable Variable