V0.3 | 2017-07-11

What is the AUTOSAR Adaptive Platform? Overview, architecture and use cases.

AUTOSAR Adaptive Platform

2

u Introduction and Use Cases

Overview and Objectives

Workflow and Architecture

Functional Clusters

Activities and Roadmap

Conclusion

Agenda

3

Adaptive AUTOSAR Use Cases

Introduction and Use Cases

u 2D/3D accel. support in POSIX systems

u Video Codecs, Streaming support, multi-media library, etc…

Infotainment

Connectivity

u “App-Store” for automotive applications

u Installation and update over the air

Dynamic Software Platform

u Car-2-X (LTE, WiFi, GPS, etc.)

u Multimedia (USB, SD-Card, NFC, etc.)

source: fotolia

u Image- and preprocessing of Camera/Radar/LIDAR

u Sensor Fusion and Machine Learning

Highly Automated Driving

4

Definition of Adaptive AUTOSAR

Introduction and Use Cases

u As a partner of the Automotive industry AUTOSAR saw the necessity to define a new platform

u It was clear that future cars will have heterogenous architectures

u The existing architectures

had to be complemented

by another one

Adaptive AUTOSAR

Deeply Embedded

Architecture

Infotainment Architecture

Dynamic Architecture

5

New Platform Requirements

Introduction and Use Cases

Adaptive Platform

Good Hardware Abstraction

Interoperability with Classic

Update of Software

Service Oriented Architecture

Easy configuration Common Methodology

for Classic and Adaptive

Security

Safety

Connection to non-AUTOSAR Services

Multi/Many Core support

Diagnostics

Libraries for high performance computing

Realtime

File handling

New Programming Model

Faster Development Cycles

u The new platform has to

fulfill

u Existing requirements

u Changed requirements

u New requirements

6

u Paradigm change due to the use of

u OO programming in C++

u Service-Oriented-Architecture (SOA)

u POSIX operating system

u Planned dynamics > incremental deployment

> Configuration changes during runtime

u Software is organized in Cluster.

u A Cluster Specification is reduced to the description of APIs and semantics (e.g. through state machines).

u No constraints on the SW architecture of a platform implementation

u No internal technical architecture description

Charactersitics

Overview and Objectives

7

AUTOSAR Classic Platform - CP

AUTOSAR Product Comparison

Overview and Objectives

AUTOSAR Adaptive Platform - AP

Real Time Requirements

Computing Power

Safety Critical

u All modules completely specified

u Developed in C

u Whole stack compiled and linked in one piece

u Will still remain in the current focus

u Less modules, only API specification

u It is the intention to give more room for different implementations

u Developed in C++

u Software components as POSIX processes

u Service oriented communication (SOME/IP)

8

Application Code Service Description (ARXML)

Tools and Workflow

Workflow and Architecture

libara

libsomeip

Logic

SOME/IP Config

AppSWCTypes

Port

Auth

ori

ng T

ool

Com

piler

Soft

ware

Configura

tion M

anagem

ent

ServiceInterface ServiceInterface ServiceInterface

Vehicle

SOMEIPd

ComServer

Diag

EM

Installed APP

Application Manifest (JSON)

BIN

Instance Manifest(s) (JSON)

Installed APP

Application Manifest (JSON)

BIN

Instance Manifest(s) (JSON)

POSIX IPC

BSD Sock

Deploy Package

/opt/myApp/

Application Manifest

./etc/MANIFEST.arxml

BIN

./bin/myApp

Instance Manifest(s)

./etc/instance1.arxml

./etc/instance2.arxml

Genera

tors

Port Port

Static

Proxies / Skeletons

SOME/IP Serializer

E2E Serializer

POSIX IPC

Generated

9

Adaptive Architecture

Workflow and Architecture

Applications

Platform

POSIX OS

SCM Service

App1

POSIX Process

Persistency EM (Execution

Manager)

ara::com ara::em ara::pers

ara::com ara::em ara::pers

Diagnostic Service

ara::com ara::em ara::pers

Middleware ara::com SOMEIPd Service Discovery

App2

POSIX Process

ara::com ara::em ara::pers

Shared Memory

ara::em

…

BSD Socket BSD Socket for DoIP

10

Adaptive Applications

Workflow and Architecture

Manifest

Instance Config

u Application

> Multi-threaded

> Execution states

> Manifest contains platform related information (recovery action, dependencies to services or libraries)

> Instance config contains application specific static information (variant, options, )

u Interfaces

> ara::com for communication with adaptive services (Basic Services and User Applications)

> PSE51 is the usable OS API subset

> The Adaptive AUTOSAR Foundation clusters (Execution Management, Persistency, etc.) are available via direct APIs

App1

POSIX Process

INIT:

RUN:

SHUTDOWN: Thre

ad

Thre

ad

Thre

ad

Adaptive AUTOSAR Services

Adaptive AUTOSAR

Foundation

ara::com Direct API PSE51

C++ Stdlib

POSIX OS

11

Ovwerview ara::com

Functional Clusters

u Service-oriented communication

u Location-transparent

u Supports multiple communication bindings

u AUTOSAR Model defines available bindings for each service provider and consumer

u Explicit support for optimized shared memory implementations

Services

APP 1 APP 2

ara::com

u Applications connected at runtime (Service Discovers)

u Find Service Instances dynamically without hardwiring in model

u Connection between proxies and skeletons can be recovered

u Real-time support: Developers’ choice of polling or event-driven processing of communication

12

Data serialization

u Today, signals are “serialized” statically to fit the PDU layout specified in the database

u Especially in the ADAS domain, there are more and more data elements of dynamic length

u A static PDU layout considers the worst case scenario > “Empty” signals are transmitted

Scalable Service-Oriented Middleware over IP – Data Serialization (SOME/IP)

u (De-)Serialization during runtime > Signals and PDUs of dynamic length

> Don’t specify the PDU layout in a database

> Transmit only the relevant and currently available data elements

> Save bandwidth

> Save computing resources

Service-Oriented Communication

Functional Clusters

Signals PDU

DB

struct

Structured data PDU

(Byte stream)

uint32 val1

float32 val2

int8 arr[1..9]

uint8 val3

val1_1

val1_2

val2_1

val2_2

val2_3

val2_4

val1_3

val1_4

arr len

arr_1

arr_2

val3_1

SOME/IP

13

Build up communication relationships during runtime

u Don’t send meaningless data and send data only when there is a need

u Reduce bandwidth usage (unicast)

u Save processing resources especially at receiver side

u The location of the sender shall be flexible

u Variant handling

Scalable Service-Oriented Middleware over IP – Service Discovery (SOME/IP-SD)

u What is a service? > Methods: Remote Procedure Calls

> Events: Publish/Subscribe, get notifications

u Service provider (server): Announce the availability and location of an offered service (broadcast)

u Service consumer (client): Subscribe to event groups to get notifications

Service-Oriented Communication (2)

Functional Clusters

Offer service

Call method

Get return values

Subscribe to event group

Get notifications

S C

Offer service

14

Startup

u OS launches Execution Manager (EM) (PID1, “init”)

u EM inspects system for installed applications

u E.g., scan filesystem in /opt/ for Application Manifests

u EM runs startup applications (fork(), exec())

u e.g., bring up IP stack

u EM consults Machine State Manager to determine desired Machine State

u Machine State defines set of Applications desired to run

u EM starts/stops applications to reach desired machine state (fork(), exec(), signal(SIGTERM))

u EM configures scheduling parameters & resource limits

u Configuration Data obtained from Application Manifest

u EM monitors for machine state changes or process termination

Execution Management Overview

Functional Clusters

ECU running

15

Diagnostic Manager

Diagnostic Manager - Overview

Functional Clusters

ara::com

Application (Software Components)

Diagnostic Event monitoring and notification

Diagnostic Request Diagnostic Response

Diagnostic Service Callbacks

Tester

u Main Tasks

u Communication with Tester

u Event Memory Management

u Configurable via AUTOSAR Diagnostic Extract (DEXT)

u Extendable during runtime…

u Uses ara::com interfaces

16

u In AUTOSAR Adaptive the Persistency cluster provides a library based implementation to access non-volatile memory to Adaptive Applications so that data can be stored non volatilely.

u Key-Value Storage

u Multiple values stored in one storage location

u Addressing of single values by using a key as identifier

u Multiple storage locations/databases can be used

u Database format not specified by AUTOSAR

u Stream Storage

u Raw access to storage locations/files

u Used for access to files in any format

u API derived from C++ Standard Library std::fstream classes

Functional Overview

Functional Clusters

Application

Key-Value Storage Location

Stream Storage Location

ara::per KeyValueStorage

ara::per arafstream

ara::per KvsType

ara::per KvsType

17

Planned Adaptive Roadmap

Activities and Roadmap

ASR Release 17.3: > Execution

Management > Communication/

Middleware > DLT > Diagnostics > Operating System > Persistency

ASR Release 17.10: > Package Management > HW Acceleration > Signal based

communication > Safety and Platform

Health Management > Security Features

ASR Release 18.03: > SW-Lockstep > FR + LIN Bus > Crypto Hardware

ASR Release 18.10: > Vehicle API > Container Support

Adaptive MICROSAR 18.06: Development release Based on 17.10 Feature set

Adaptive MICROSAR 19.01: Development release Based on 18.03 Feature set

2017 2018 2019 2020

Adaptive MICROSAR 19.06: Production release Based on 18.10 Feature set

Deliveries based on Adaptive AUTOSAR Code

Vector Adaptive modules replace community source parts gradually as development is progressing

18

Conclusion

Conclusion

u The new Adaptive Platform complements

the existing Classic Platform

u The Classic Platform will be still necessary to

implement deeply embedded functionalities

while the Adaptive Platform will run high

level parts of functions

u Implementing a new Architecture was the

right decision to handle future use cases

u Vector will continue to contribute to AUTOSAR

and provide implementations and tools for

Classic and Adaptive AUTOSAR

19 © 2017. Vector Informatik GmbH. All rights reserved. Any distribution or copying is subject to prior written approval by Vector. V0.3 | 2017-07-11

For more information about Vector and our products please visit www.vector.com

Author: Stefan Albrecht Vector Germany