Since the first release of its standard in 2003, AUTOSAR has established itself as one of the primary software development standards for the global automotive industry. As the automotive industry is a now undergoing one of the significant changes in its history toward autonomous driving, connectivity and electrification new standards are needed to handle the complexity regarding software architecture for controlling the high-end processors, Ethernet communication, and over-the-air updates in the cloud-connected automobiles. The recent advent of the Adaptive AUTOSAR standard can help accommodate the extensive and complex requirements of autonomous driving by enabling a flexible, dynamic, and service based platform while still maintaining the integrity of high degree of functional safety standards and also properly engaging with established platforms. The standard itself replies on some technologies which are already established in the industry such as virtualization, POSIX PSE51, C++11/14 for application development, ISO26262/ASIL compliance, etc.
This presentation provides example of an implementation of mixed critical Adaptive AUTOSAR stack based on VxWorks RTOS, embedded Linux, and virtualization profile from Wind River. As one of the very few solutions available on the market which is already fulfilling the requirements described above, VxWorks is a strong example of a foundational software platform for Adaptive AUTOSAR-based autonomous driving development. We will also explain what challenges we have encounter with during this process and make some suggestions to the AUTOSAR consortium of how to overcome them in the future.
Call Girls in Malviya Nagar Delhi 💯 Call Us 🔝9205541914 🔝( Delhi) Escorts Ser...
Mixed-critical adaptive AUTOSAR stack based on VxWorks, Linux, and virtualization
1. 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.
2. AUTOSAR 07-Nov-2018 2
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)
6. AUTOSAR 07-Nov-2018 6
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
7. AUTOSAR 07-Nov-2018 7
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
?
9. AUTOSAR 07-Nov-2018 9
▪ 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
10. AUTOSAR 07-Nov-2018 10
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)
11. AUTOSAR 07-Nov-2018 11
▪ 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
12. AUTOSAR 07-Nov-2018 12
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
13. AUTOSAR 07-Nov-2018 13
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
14. AUTOSAR 07-Nov-2018 14
▪ 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
15. AUTOSAR 07-Nov-2018 15
▪ 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
16. AUTOSAR 07-Nov-2018 16
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
17. AUTOSAR 07-Nov-2018 17
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
18. AUTOSAR 07-Nov-2018 18
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
19. AUTOSAR 07-Nov-2018 19
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
21. AUTOSAR 07-Nov-2018 21
• 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
23. AUTOSAR 07-Nov-2018 23
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
24. AUTOSAR 07-Nov-2018 24
• 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
25. AUTOSAR 07-Nov-2018 25
▪ 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
26. 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