Standardized Runtime platforms and

component integration
AutoSAR and ARINC653

Ákos Horváth
András Balogh
Dept. of Measurement and Information Systems

Budapest University of Technology and Economics

Department of Measurement and Information Systems
 Abstract
 ” The goals of standardization can be to help with
independence of single suppliers
(commoditization), compatibility, interoperability,
safety, repeatability, or quality.”

2
 Agenda
 AutoSAR
o Overview
o High-level design flow
o Components
o Runtime Environment

 ARINC 653

3
 History
 AUTomotive Open System ARchitecture
 Started in 2002
 BMW, Bosch, Daimler, Conti, VW, + Siemens
 Industrial standardization group
o Current standard version: 4.0 (end 2009)
o Currently we use 3.1 (end 2008)
 Members: OEMs, Tool vendors, Semiconductor manufacturers Europe-
dominated
 Scope
o Modeling and implementation of automotive systems
o Distributed
o Real-time operating system
o String interaction with HW and environment
 Out of scope
o GUI, Java, internet connectivity, File systems, Entertainement systems, USB
conncetivity etc.

4
 Key Concepts of AutoSAR
 A standard runtime architecture
o component-oriented
o layered
o extensible
• New functionalities
• New components (component implementations)
o all major interfaces standardized
o Standardized Run Time Environment (RTE)
 A standard modeling and model interchange approach
o follows the principles of model-driven design
o supports the interchange of designs
o supports the collaborative development
• Between different developers,
• Teams,
• And even companies
 Conformance test framework
o assuring the conformance to the standard
o Still evolving – new in version 4.0

5
High-level design flow

6
 High-level design process
High-level Component
SW modeling Model (VFB)

High-level software modeling

• Definition of
• components
• component ports
• port interfaces
• data types – logical
• Result
• VFB-level software model
 High-level design process
High-level Component
SW modeling Model (VFB)
Detailed
Component
Design
Component
Internal
Behavior

Detailed component design

• Specification of
• component internal behavior
• functional breakdown
• implementation/use of ports
• Non-AutoSAR
• specification of detailed behavior
• any tool can be used
• UML
• Simulink
• etc.
• Result
• AutoSAR component internal behavior
model
• Non-AR: behavioral models/design
 High-level design process
ECU
High-level Component High-level
resource
SW modeling Model (VFB) HW modeling
model
Detailed
Component
Design
Component
Internal High-level hardware modeling
Behavior • Specification of
• ECU resources
• CPU
• memories
• peripherals
• communication hw
• system topology
• ECU instances
• clusters
• connections
• Result
• ECU resource model – for all ECUs
• System topology model
 High-level design process
ECU
High-level Component High-level
resource
SW modeling Model (VFB) HW modeling
model
Detailed
Component
Design HW/SW integration
Component
• component allocation
Internal • communication
Behavior • mapping
• configuration
• scheduling
Hardware-software integration
• mapping
System • software component allocation
model • component implementation selection
• data-element to signal mapping
• inter-ECU communication
• communication configuration
• signal to PDU mapping
• PDU to frame mapping
• Signal, PDU, Frame triggering
• Cluster and controller configuration
• Frame scheduling (LIN, FlexRay)
• Result
• System model describing the integrated
HW/SW system
 High-level design process
ECU
High-level Component High-level
resource
SW modeling Model (VFB) HW modeling
model
Detailed
Component
Design HW/SW integration
Component
• component allocation
Internal • communication
Behavior • mapping
• configuration
• scheduling

Component
implementation System
model Component implementation
• Implemeting all components
Component • automatically
Component
Impl. • TargetLink
Component
Impl.
files
• Simulink Realtime workbench
Impl. • SCADE
files
files • etc.
• manually
• Result
• implementation of the components
• C/C++/…
 High-level design process
ECU
High-level Component High-level
resource
SW modeling Model (VFB) HW modeling
model
Detailed
Component
Design HW/SW integration
Component
• component allocation
ECU configuration
Internal
• Configuring all basic software•modules
communication
Behavior
• based on the system model • mapping
• for each ECU separately • configuration
• Result • scheduling
• ECU configuration model
Component
System ECU Configuration
implementation
model configuration model

Component
Component
Impl.
Component
Impl.
filesImpl.
files
files
 High-level design process
ECU
High-level Component High-level
resource
SW modeling Model (VFB) HW modeling
model
Detailed
Component
Design HW/SW integration
Component
• component allocation
Internal • communication
Behavior • mapping
• configuration
• scheduling

Component
BSW configuration generation
System ECU Configuration
implementation
• Configuration generation for basic software
model configuration model
• from the configuration model
• Result
Component
• Configuration files (c,h)
Component
Impl.
•Component
Generated modules/module fragments
Impl. BSW config Code
filesImpl.
files files generation
files
 High-level design process
ECU
High-level Component High-level
resource
SW modeling Model (VFB) HW modeling
model
Detailed
Component
Design HW/SW integration
Component
Compilation and •linking
component allocation
Internal
• Building and linking all sources• communication
Behavior
• application • mapping
component implementations
• basic software modules • configuration
• BSW configuration files • scheduling
• Result
Component
• Deployable binary file
System ECU Configuration
implementation
model configuration model

Component
Component
Impl.
Component
Impl. Compiling BSW config Code
filesImpl.
files Linking files generation
files

Binary
 Models in the design flow

 Software Component Template

o Components, ports, interfaces
o Internal behavior
o Implementation (files, resource consumption, run
time, etc.)
 ECU Resource Template
o Hardware components, interconnections
 System Template
o System topology, HW/SW mapping
o Comm. matrix
 Models in the design flow 2

 Basic Software Module Template

o BSW modules
• Services
• Schedulable entities
• Resource consumption
 ECU Configuration Parameter Definition Template
o Configurable paramters of BSW modules
 ECU Configuration Description Template
o Actual configurations of BSW modules
o Based on the ECU Parameter Definition
AutoSAR vs. UML/SysML/... modeling
 AutoSAR defines models with
o Domain Specific Constructs
o Precise syntax
o Synthesizable constructs
• Direct model -> transformations
• Direct model -> detailed model mappings
o Different abstraction levels
• From Virtual Function Bus to configuration
 Result
o Models are primary design and implementation
artifacts
• More precise, consistent modeling should be done
AutoSAR Components

18
 Component-oriented design
 What is a component?
o “A component is a self contained, reusable entity that
encapsulates a specific functionality (and/or data), and
communicates with other components via explicitly defined
interfaces.”
 AutoSAR uses the term component for application-level
components
o Elements related to the high-level functionality of the system
under design
 Basic software (middleware) components are called modules.
o Standard elements of the AutoSAR architecture
 Component-based approach
Component
• Encapsulates a specific functionality
• Different kinds
• Composite component – hierarchical refinement
• Application SW component – generic, high level functionality
• Sensor/actuator SW-C – handling sensor or actuator data
• ECU HW abstraction – higher level device driver and abstraction
• ComplexDeviceDriver – time-critical, low-level driver
• Calibration parameter SWC – collects system calibration
parameters
<<interface>>
SenderReceiver1
• Service SWC – represents a basic software module from the service
layer
dataElement1
dataElement2

Component
 Component-based approach
Ports
• The only interaction points between the component and its
environment
• Are implementing port interfaces
• sender receiver (message-based unidirectional
communication)
• client-server (remote procedure call)

<<interface>>
SenderReceiver1

dataElement1
dataElement2

Component
Component-based approach – port notation

Receiver port Sender port

Server port Component Client port

Service port
To Basic Software
(BSW) Module
services
Inverted image
Component interconnection – the Virtual Functional Bus

Component A Component B Component C Component X

…..

…..
Virtual Functional Bus
Virtual Functional Bus (VFB)
• Abstract interconnection layer
• Implementation of data/control transport between components
• No hardware/network dependency
• Hides the details of the implementation
• Allows high-level integration and simulation of components
• Before hardware architecture is chosen
 Software Components

 On high-level, atomic components are black

boxes
 Detailed design “looks into” these black boxes
 Main goals
o Detail the behavior to get schedulable entities
o Specify the semantics of port handling
o Specify any service needs
o Specify any RAM, nvRam needs
 Refinement of a component
Black box definition of a component

Component

Definition of component internal

behavior
Schedulable entities, connections to
the ports

Component implementation.
Comp.c Comp.h
Specification of source and header
files
 Component internal behavior
 Specification of the internals of an atomic
SWC
 Schedulable elements
o Called: runnable entities
 Connection of ports
o Port semantics
o Port API options
 Inter-runnable communication
 Runnable activation and events
Component internal behavior – runnable entities
 Smallest code-fragments considered by RTE
 Subject to scheduling by the OS
 Abstraction of a schedulable function
 Communicates
o Using the SWC ports
o Using inter-runnable communication facilities
 Is activated by
o An RTE event
• Communication-related event
• Timing event
Run Time Environment

28
 AutoSAR Runtime Architecture
 Software architecture of a single ECU
 Layered approach
o Application software
o Runtime Environment (RTE)
• Implementation of the VFB
o Basic software modules
• Platform services
• Device drivers
• Operating system
 Standardized
AutoSAR Architecture – layered view

Application Layer

AUTOSAR Runtime Environment (RTE)

Services Layer

Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller
AutoSAR Architecture – layered view

Application Layer

AUTOSAR Runtime Environment (RTE)

Microcontroller Abstraction Layer
• Low-level peripheral drivers Services Layer
• Memory devices
• Communication controllers
• Internal uC peripheral units (ADC, GPIO, PWM)
Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller
AutoSAR Architecture – layered view

ECU Abstraction Layer

Application Layer
• Uniformization of device access
• Memory devices
• Communication controllers
AUTOSAR
• Onboard devices Runtime
(watchdog, etc.) Environment (RTE)
• ECU specific hardware abstraction
• I/O abstraction software components
Services Layer

Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller
AutoSAR Architecture – layered view

Application Layer

Complex drivers
AUTOSAR Runtime Environment (RTE)
• Custom, low level hardware manipulation
• Time critical components
Services Layer

Complex
ECU Abstraction Layer Drivers

Microcontroller Abstraction Layer

Microcontroller
AutoSAR Architecture – layered view

Application Layer

AUTOSAR Runtime Environment (RTE)

Services Layer

Complex
ECU Abstraction Layer Drivers

Services layer
Microcontroller Abstraction Layer
• System services
• RTOS
• Diagnostic event handling Microcontroller
• ECU and COM state management
• Non-volatile memory
• Communication controllers
• Onboard devices (watchdog, etc.)
• Communication services
• PDU router, transport protocols, network management, COM, DCM
AutoSAR Architecture – layered view

Application Layer

AUTOSAR Runtime Environment (RTE)

Services Layer

RTE Complex
• Provides interconnection between components
ECU Abstractionand BSW
Layer Drivers
• orchestrates component execution
• manages communication
• manages application modes
Microcontroller Abstraction Layer
• Implements the VFB

Microcontroller
 AutoSAR Runtime Architecture
Application Actuator Sensor Application
AUTOSAR Software Software Software AUTOSAR Software
Software Component Component Component Software Component
Component
AUTOSAR AUTOSAR AUTOSAR AUTOSAR
Interface Interface Interface .............. Interface

Interface
AUTOSAR Runtime Environment (RTE)
Standard
Standardized
Software Standardized Standardized AUTOSAR AUTOSAR
AUTOSAR
Interface Interface Interface Interface
Interface
API 2
VFB & RTE ECU
Services Communication
relevant Abstraction

API 1 Standardized Standardized Standardized

Standardized

RTE Interface Interface Interface

Interface

relevant Complex
Operating
Device
System
API 0 Drivers
Standardized
API 3 Private
Interface
Interfaces inside Basic Software Microcontroller
Basic Software
possible Abstraction

ECU-Hardware
The overall mapping process – 1. step
 Overall System specification
o Selection of implementations for the components
• Implicitly includes the selection of internal behavior
o Selection of ECUs for the components
• Allocation
o Mapping of data elements/operation parameters
to signals
• For inter-ECU communication
o Communication configuration
• Signal  Isignal PDU  Frame mapping
• Cluster and comm. Controller configuration
o Result: configured system
• ECU Extract: a slice of the model representing elements required
for a single ECU
 The overall mapping process – 2. step
 Single ECU configuration
o Input ECU extract
• Component internal behavior
• Communication matrix (of the ECU)
o OS Configuration
• Runnables needs to be mapped to tasks
– Basic tasks
» Finite execution time
– Extended tasks
» Can run forever (blocking calls required)
o Events to notification mapping

38
 Summary
 AutoSAR defines
o A component-oriented system design approach
• Domain specific modeling language
• A high level design process
• Standard middleware (basic software) stack
– Standard interfaces
– Standard configuration descriptors
 AutoSAR compliant ECU software
o Includes several BSW and application components
o RTE provides the integration (glue) between these
o Configuration and glue code is mostly auto-generated
 Agenda
 AutoSAR
o Overview
o High-level design flow
o Components
o Runtime Environment

 ARINC 653

40
 ARINC 653 Overview
 ARINC 653 - Avionics Application Standard Software
Interface) is a software specification for space and time
partitioning in Safety-critical avionics Real-time operating
systems.
 ARINC 653 is a specification for an application executive
used for integrating avionics systems on modern aircraft
 It is an API of 51 routines (ARINC 653 APEX – APplication
Executive): time and space (memory) partitioning, health
monitoring (error detection and reporting),
communications via “ports”
 ARINC 653 OS and applications are typically certified per
DO-178B;
o different partitions can be certified to different DO-178B
“levels” running on the same CPU
41
 ARINC 653 Structure
 Part 1: Definition of Required Services - 1996
o Health management
o Time and space partitioning
o Suplement 3: corrected XML schema definition based
on Boeing 787 issues (2010 Oct 6)
 Part 2: Extended Services - 2006
o File system, logbook, service access points
 Part 3: Conformity Test Specification - 2006
 Part 4: Embedded profiles for small embedded
systems – under definition
42
 Architecture
 Complete time and
space partitioning
o Integration of SW of
Multiple Criticalities
 Portability
o Abstract away
underlying HW and
RTOS
 Reusability
o Resuse components
 Modularity
o Removes HW and
SW dependencies

43
 ARINC 653 Key Components

 Partitoning and scheduling

 Communications

 Health Monitoring

44
 Partitions
 Completely deterministic time scheduling
 Fix cyclic scheduling
 Scheduling is a negotation process between
o System integrator and App developers
 Health Monitor check for any temporal violations
(jitter, deadlines)

45
 Processes
 Runs inside a partition  time jumps when partition
is activated  do not know about anything else
 Types
o Periodic
o Aperiodic
 Hard deadline
o Remedial action if deadline are missed
 Soft deadline
o Records failure and continues
 Health Monitor defines all actions if a deadline is
missed

46
 Communications
 Inter Partition Communication
o Port – channel- port
o One-to-one, or one-to-n
o Queuing ports
• Stored messages
• variable length
• FIFO or priority
o Sampling ports
• Overwrites previous messages
• Fixed length
• Time stamped (validity time)
 Streaming like data is not supported
47
 Communications
 Intra Partition Communication
o Buffers
• FIFO
o Blackboards
• Message is overwritten by teh next message (or clear if
required)
• Processes can queue for a message  reads lates version
data on blackboard
o Semaphore
• counting
o Events
• For notification of condition occurance

48
 Health Monitoring
 Defines the actions when an error occurs
o Deadline missed, numeric error, illegal request, power fail,
memory violation, etc.
 Precisely defines roles
1. Process HM
• ”error handler process”
• Optional
2. Partition HM
• Memory and context belongs to Module OS but scheduled in Partition
window
3. Module HM
• Not part of any partition  higher priority than any partition
• Severe error if it is activated
 Multi role definition
o System integrator
o Application provider
49
 Summary
 IMA systems are very complex
o 10+ applications
o 2M lines of code, 50k configuration element

 ARINC 653
o became the De facto avionics RTOS standard
o Fits into the DO-297 concept
• Strong partitioning
• Incremental certification
o Decreases the cost of change
 Field proven technology
o Airbus 380
o Boeing 787
o Airbus 400m

50