Mixed-critical adaptive AUTOSAR stack based on VxWorks, Linux, and virtualization

11th AUTOSAR Open Conference
AUTOSAR 07-Nov-2018 1
Mixed-critical adaptive AUTOSAR stack based on VxWorks, Linux and virtualization
Andrei Kholodnyi
Wind River Systems
Type equation here.

Automotive functions workload
consolidation and Adaptive AUTOSAR
Lessons learned of porting Adaptive
AUTOSAR stack to VxWorks RTOS
TOPICS OF MY TALK
TODAY
> Automotive OEM & OES
> ADAS/HAD, Connected Vehicle, IVI, OTA, Automotive Security
> Automotive engineering organization
> Products, Solutions & Partnerships
Andrei Kholodnyi
Principal Technologist
CTO Office
> First GENIVI based project development for BMW
> AdvancedTCA (Networking) for Alcatel and Lucent
> Led and delivered IVI, telematics and connectivity projects
> Thematic pathfinding for the new technologies (Deep Leaning,
Autonomous Robotics)
> Cross-business technology leadership
> Participation to alliances (GENIVI, FASTR, Adaptive AUTOSAR,
PICMG)
> Strategy and Vision for Wind River Automotive Products for ADAS,
HAD, IVI, In car connectivity and Cloud connectivity
FOCUS
RELEVANT PROJECTS (selection)

Chemical Sector Commercial Building Sector Communications Sector Critical Manufacturing
Dams Sector Defense Base Sector Emergency Services Sector Energy Sector
Financial Services Sector Food and Agriculture Sector Government Building Sector Health Care Sector
IT Sector Nuclear Sector Transportation Sector Water and Wastewater Sector
3 © 2018 WIND RIVER. ALL RIGHTS RESERVED.

Partners
Tools
VXWORKS PLATFORM
Virtualization
Virtualize different workloads at the edge
Supports multiple levels of safety and security
Pre-integrated VxWorks and Linux Guest OS environments
Virtualization
LinuxRTOS
Cert
Services
RTOS
Determinism, low latency
Scalability
Security features and CVE protection
Designed for Safety
Device management (Device Cloud)
Safety Certification
ISO26262, IEC 61508 and DO-178C
certification
Certification services
Linux
Security features and CVE protection
Long lifecycle maintenance
Advanced networking and graphics
Device management
Tools
Development tools
Analysis tools
Analytics
Simulation
Partner Ecosystem
Board and semi partners
Industrial protocols
Analytics
Cloud
WORKLOAD CONSOLIDATION
Services
Integration
Application
BSPs
Security
J3061, ISO/IEC 27034, IEC 62443-4-2
Security Assessments
SDL

ENGAGING & CHALLENGING APPLICATIONS WITH
LOTS OF SW & HW
• Driver assistant and autonomous driving systems
• Displays: Instrument Cluster, HUD, IVI, RSE, Augmented Reality
• Navigation: maps, route planning, traffic avoidance
• Connectivity: GPS, Bluetooth, OBD, CAN-FD, TCP/IP, Wi-Fi, LTE
• Security: trusted boot, encryption, attestation, firewall, packet inspection
• Insurance/liability: driver monitoring, system logging/reporting
• Infrastructure: resource mgmt, storage, key mgmt, orchestration
• Maintenance: Over-the-air, diagnostics, health monitoring, fallback
• Sensing, actuation, sensor fusion, sensor distribution/services

REAL-TIME: HARD, SOFT, BEST EFFORT
IP: FOSS, PROPRIETARY
LICENSING: VIRAL, NON-VIRAL, COMMERCIAL
MIXED INTEGRITY LEVELS, CERTIFICATION
BARE-METAL VS. OS-SPECIFIC VS. CONTAINERS
ARCHITECTURES: MONOLITHIC VS. MICRO-SERVICE
STATIC VS. ADAPTABLE: BSP, OS, APPLICATIONS
THE SOFTWARE IN AUTOMOTIVE SYSTEMS IS DIVERSE
DIVERSE AND DIVERGENT SOFTWARE ATTRIBUTES
MACHINE LEARNING: MANY USEFUL ALGORITHMS

CRITICAL SYSTEMS
• AFFORDABILITY: HIGH COST TO MAINTAIN
& UPDATE
• OBSOLESCENCE
• INTEROPERABILITY
• STAFF SKILLS SHORTAGE
• DATA CAPTIVE / PROCESSED IN DEVICE
• LACK OF COMPUTING POWER
• OUTDATED SECURITY FEATURES
• SLOW PRODUCT LIFECYCLES
LEGACY CHALLENGES
SCALABILITY
AGILITY
DEVOPS
PAY-PER-USE
CLOUD DEVELOPMENT
DE-COUPLED:
HW, SW, APPLICATION
MODERN BENEFITS
?

REAL-TIME
ISLAND
SAFETY
ISLAND
SECURITY
ISLAND
CAPABILITY ISLANDS
FOR RESILIENT AUTONOMOUS SYSTEMS

▪ LEVERAGE LINUX/ANDROID WHERE IT MAKES SENSE
▪ CONTAINERS, ANALYTICS, ML, HIGH-LEVEL APPLICATION
FRAMEWORKS (PYTHON)…
▪ USE RTOS WHERE IT MAKES SENSE
• PERFORMANCE, DETERMINISM, CERTIFIABILITY
▪ INCREASE:
▪ DEVELOPMENT VELOCITY
▪ APPLICATION PORTABILITY
▪ ULTIMATELY AFFORDABILITY
ADVANTAGES OF THIS APPROACH
REAL-TIME ISLAND

RTOS
VIRTUAL
MACHINE
▪ PARTITION REAL-TIME NEEDS
▪ RTOS “WORKLOAD ACCELERATION”
▪ RTOS LEVERAGES LINUX FOR
NON-REAL-TIME ELEMENTS & VICE VERSA
▪ RTOS AND LINUX APPS COLLABORATE
▪ SUITABLE VIRTUALIZATION HARDWARE ENABLES
RESOURCE MAPPING & PERFORMANCE
▪ CONSISTENT & FAMILIAR PROGRAMMING MODEL
RT APP(S)
REAL-TIME ISLAND
WHAT IT LOOKS LIKE
MULTICORE HW
LINUX
LINUX APP(S)

▪ BUILD COMPLEX SYSTEMS WITH A PATH TO SAFETY
CERTIFICATION
▪ SYSTEM PARTITIONING ENSURES ISOLATION
▪ LEVERAGE MODERN FRAMEWORKS
▪ TENSORFLOW, OPENCV, PYTHON, NODE.JS…
▪ CREATE AN ASSET BRIDGE
▪ MIGRATE LEGACY CODE FROM ANY OS
▪ INCREASE:
▪ DEVELOPMENT VELOCITY
▪ APPLICATION PORTABILITY & RE-USE
▪ ULTIMATELY AFFORDABILITY
ADVANTAGES OF THIS APPROACH
SAFETY ISLAND

RTOS
VIRTUAL
MACHINE
LINUX VIRTUAL MACHINE/
CONTAINER
▪ RTOS FOR SAFETY AND REAL-TIME
▪ RTOS LEVERAGES LINUX FOR
NON-REAL-TIME/NON-SAFETY ELEMENTS
▪ RTOS AND LINUX APPS COLLABORATE
▪ PATH TO SAFETY CERTIFICATION WHERE NEEDED
▪ SYSTEM PARTITIONING & ISOLATION
▪ MINIMAL CODE BASE FOR SAFETY AND REAL-TIME
TYPE 1 CERTIFIED HYPERVISOR
LINUX APP(S) SAFETY
APP(S)
SAFETY ISLAND
WHAT IT LOOKS LIKE

Partition 1
Reasons to partition a software asset
▪ Fault propagation prevention
▪ Differing core attributes (RT, license, certification etc)
▪ Stabilization (don’t touch it if it works)
▪ Evolution (if it changes a lot, separate it out)
▪ Org chart (agile team ownership)
▪ Live update (things that can be updated live, should)
TYPE 1 CERTIFIED HYPERVISOR
Element Separation motivates many partitions
Principle is “if an element can be separated out and protected with robust partitioning, it should be.”
Partition <n>
…
Core 1 Core <m>
…
 if n > m, fractional core scheduling hypervisor feature required
 as a system evolves, matures, extends and grows, n will trend up

▪ Hypervisor shall support robust partitioning
▪ Hypervisor shall support hard real-time (and be hard real-time itself)
▪ Hypervisor shall enable certification (and be certifiable itself)
▪ Hypervisor shall support uP and SMP guests
▪ Hypervisor shall support fractional core scheduling
▪ Hypervisor shall support VM preemption (e.g. RTOS preempts Windows on a core)
▪ Hypervisor shall support independent VM reboot
▪ Hypervisor shall support unmodified guest OSs (e.g. Android, QNX etc)
▪ Hypervisor shall enable individual device access (e.g. to PCI devices)
▪ Hypervisor shall enable silicon independence
Workload consolidation requirements
(for hypervisors used in autonomous systems)
 the hypervisor is a key foundational layer for workload consolidation
 It should provide flexibility for the system to evolve over time

Emerging Automotive HW/SW Architectures
Ethernet
Body GW
ECU
ECU
ECU
ECU
Body
Domain App
Logic
ECUECU
ADAS/
Autonomous
Driving
ECU
ECU
ECU
ECU
ECUECU
Cluster/IVI/RSE
ECU
ECU
ECU
ECU
ECUECU
Engine Control
ECU
ECU
ECU
ECU
ECUECU
Cloud
OTA
Move app
logic
Lower uC costs
Security GW
OTA
OTA
Telematics
Services
Mobile
devices

Super ADAS
VxWorks RTOS,
Safety Linux
Cluster/HUD
VxWorks RTOS
FUTURE AUTOMOTIVE HW/SW ARCHITECTURES: CONSOLIDATION
SoC
1 Core
GPU
Security
GW
Cloud
CAN/eAVB USB 2 Ethernet
Fastboot
OpenGL
Safe Audio Mixer
Rear IVI
Android
Games
TCU
IoT GW
Firewall
IDPS
Front IVI
Linux (AGL,
WRS, Genivi)
Smart Device Link
Wireless CarPlay
Safe HMI Stack
USB 1
Cloud / OTA
Adaptive Autosar
V2X
Wind River Hypervisor
OpenGL
Adaptive Autosar
OpenGL
Adaptive Autosar Adaptive Autosar
Body Ctrl
Legacy OS
ADAS Applications
Monitor
Adaptive Autosar
Windows
Seat Control
HVAC
HD Maps
CAN Svc
XML Config Health MgmtVirtual Devices OS IPC
X Cores
Smart Device Link
Rear Camera
V2X
VxWorks RTOS
Adaptive Autosar
DSRC drivers
V2X middleware
Applications
Cloud / OTACloud / OTACloud / OTACloud / OTACloud / OTA

VxWorks
Autonomous Framework
Adaptive AUTOSAR
VxWorks Cert Guest OS – Instance AOTA
OTA Back-
end
Remote
Diagnostics
• ASIL-D RTOS
• ASIL-D Type 1 Hypervisor
• Time & space partitioning
• Multi-Core
• Multiple RTOS instances
• Adaptive AUTOSAR provides
standard app services
• Autonomous/ADAS Abstraction
Framework
• Autonomous/ADAS reference
algorithms & drivers
• Sensor/actuator/algorithm
configuration via XML
• V2X stack
• Time Sensitive Network stack
• Certified File-system
• Process/Core affinity
• All OTA updatable
• Secure boot
Multi-Core HW PlatformEth Serial RAM Flash Bus Timer DSRC GPU
Core 0-4 Core 5-9 Core 10-14 Core 15
TSN Crypto OpenCL POSIX
C++ SYCL Health
Persistency
Comm Mgr
Exec Mgr HW Accel
Log / Trace
Security Mgr
Diagnostics
Health
Filesys
V2X
Sensor …n
Sensor 1 Sensor Fusion
Perception
Nav/Maps
LocalizationRoute Plan Maneuvers
Output…n
Actuator 2
Actuator 1
Customer Application Components
Autonomous Driving SW Reference Architecture
InstanceB
InstanceC
Multi-OS Safety IPC
Runtime Processes
User Space
Low level features
Type 1 Hypervisor
Hardware
Wind River HypervisorXML Config Health MgmtVirtual Devs OS IPC
Actuation
2 of 3
Trajectory
Arbitration
LCLS Mgmt
Shared
Services
Video
Decode
CAN
Storage

Adaptive AUTOSAR Demo (VxWorks RTOS + Linux +
HV)
ARA::COM
(SOMEIP)
VxWorks
Gazebo Simulator
ActuatorSensor
Gazebo/ARA::COM
Bridge
Sensor
Application
libGazebo
Process
Application
Actuator
Application
Linux
ARA::COM
(SOMEIP)
Wind River Hypervisor

• Adaptive AUTOSAR standard helps accommodate the extensive and complex
requirements of autonomous driving by enabling a flexible, dynamic, and service based
platform
• The standard itself relies on some technologies which are already established in the
industry such as POSIX PSE51, C++11/14 for application development, ISO26262/ASIL
compliance
• Lightweight (ASIL-D) hypervisor with support of different guest OS’s adds another level
of flexibility to adaptive AUTOSAR standard and allows creating mixed-critical
configurations
• Safety, real-time and security islands provide isolation capabilities for the automotive
functions running on the same multicore CPU
• A complete solution reduces total costs of ownership and shorten development
lifecycles
Automotive Workload consolidation summary

Part 2
Lessons learned of porting Adaptive AUTOSAR stack to
VxWorks RTOS

Development environment: Build and Deploy on the target
Build app
rpm
Get App
SDK
Setup Yocto
environment
Add Yocto
app recipe
Deploy app
rpm on the
target
Generated by
CI
Eclipse CDT +
Yocto plugin +
Yocto build
system
Yocto specific
recipe
Yocto specific
build
Linux specific
deployment
method
Start app
on the
target
Linux specific
start method
User space
shell, UNIX
commands
Rpm pkg
manager
Yocto and CDT Eclipse specific

• Linux is the only reference POSIX OS in Adaptive AUTOSAR consortium at the moment
• As a consequence source code is polluted with Linux headers
• While POSIX PSE 51 is the application API, underneath interface is POSIX
• POSIX implementation is different for different OSes
• POSIX Runtime behavior is different
• Linux Yocto build system is different in compare to the RTOS build system
• Non-friendly licenses in adaptive AUTOSAR reference implementation e.g. GENIVI
licenses for SOMEIP and DLT (MIT and others, not clear who owns a copyright)
• SOMEIP, DLT (Wind River reimplements it)
• Large Footprint of the reference implementation (e.g. BOOST)
• C, C++ libraries are different for Linux OS and RTOS
• Development environment differences between Linux and non-Linux
Challenges of porting Adaptive AUTOSAR stack to non-
Linux OS

▪ Integrate Adaptive AUTOSAR with other POSIX RTOS e.g. with Zephyr
▪ Add more compelling use cases for the ADAR demonstrator :
– Two nodes running different OSes (at least)
▪ Virtualization
– Add hypervisor usecase e.g. Hypervisor running Linux and RTOS
▪ Build system shall cover not only Linux use case but also virtualisation and
RTOS use cases
Porting adaptive AUTOSAR stack summary

11th AUTOSAR Open Conference
Thank you for your attention!
AUTOSAR 2607-Nov-2018
www.windriver.com/auto
1-800-545-WIND
Andrei.Kholodnyi@windriver.com
https://www.linkedin.com/in/akholodnyi/ https://www.slideshare.net/AndreiKholodnyi
Andrei Kholodnyi, Principal Technologist,
Wind River Technology Office

Mixed-critical adaptive AUTOSAR stack based on VxWorks, Linux, and virtualization

More Related Content

What's hot

Similar to Mixed-critical adaptive AUTOSAR stack based on VxWorks, Linux, and virtualization

More from Andrei Kholodnyi

Recently uploaded

Mixed-critical adaptive AUTOSAR stack based on VxWorks, Linux, and virtualization