1. Xen in Automotive
Artem Mygaiev,
Technology Solutions Director
at EPAM Systems

2. Xen in Automotive
• Xen for Automotive uses first time appeared on XDS in 2013
• Initially virtualization was not very well accepted by the industry
• But since then Automotive OEMs started to use hypervisors and
became more inclined to use OSS
• Still, proprietary solutions used most of times

3. Virtualization use case evolution

4. Automotive systems requirements
• Extended guest domain functionality
• Peripherals sharing for complex user scenarios
• Virtualization of GPUs and other co-processors
• TEE support for guest OSes
• Power & Performance
• Full system power management
• Real-time guest domain scheduling
• Heterogeneous multi-core scheduling support
• Functional safety support

5. What has been done in Xen
• Extended (UI-centric) peripherals support added
• Mechanisms to implement GPU sharing (all implementations
proprietary due to limitations of GPU vendors)
• TEE virtualization support added
• Hard/Firm RT scheduling improvements
• Time accounting, runstate, cache coloring, etc. - WIP
• System EAS-like power governance
• DVFS support, governance, etc. - WIP
• No dependency on Linux in Dom0
• Dom0-less, xl RTOS port - WIP
• Approximately one zillion of demos with industry players

6. Virtualization use case evolution
Digital Cockpit
Communication
Gateway
Application server
Cluster + HUD
Driver infotainment
Rear-seat infotainment
5G firewall
Internal buses broker
Edge services
Adaptive AUTOSAR
• Few centralized mixed criticality systems
• Migration of services between nodes and possibly cloud
• Flexible resource partitioning and usage mixing RT and non-RT
• Bare metal applications (unikernels)
• VM Introspection

7. Standardisation for hypervisors
• AGL Virtualization Expert Group
• “The Automotive Grade Linux Software Defined Connected Car
Architecture”
• GENIVI Hypervisor Work Group
• “Automotive Virtual Platform Specification”
• In both groups (also at Google) standardisation of hypervisor
APIs are treated as extremely important
• For vendors, VirtIO looks promising as a widely used standard

8. What is Functional Safety
• Safety is a freedom from unacceptable risk of a harm
• Risk is a combination of probability and severity of a harm
• Harm means injury to people or damage to equipment or
environment
• Functional Safety is absence of unreasonable risk due to hazards
(potential source of harm) caused by malfunctioning behavior of
the complex electronic systems

9. Safety standards
• IEC 61508
• “Basic” functional safety standard applicable to any industry
• ISO 26262
• Adaptation of IEC 61508 for Automotive systems
• NOTE: Many others exist for Medical, Rail, etc.
• MISRA
• Coding guidelines for automotive created before ISO 26262, still widely
used in mission-critical embedded applications.

10. How Xen is seen for the Safety POV
IEC 61508
• Route 1S. This route covers the requirement for elements and components
designed in accordance with IEC 61508
• Does not fit us because Xen is not created from the beginning with Functional Safety in
mind
• Route 2S. This route covers components that are used based on proven-in-
use IEC 61508-2
• Does not fit us because Xen was not massively used before in Functional Safety
environments
• Route 3S. This route covers pre-existing software elements and refers
directly to IEC 61508-3
• Fits our needs as Xen can be viewed as a “compliant non-compliant development”.
Basically this means existing processes are mapped to those required by standard and
gaps eliminated

11. How Xen is seen for the Safety POV
ISO 26262
• The ISO 26262 functional safety standard describes a Safety Element out of
Context (SEooC) as a safety related element that is not developed for a
specific item (i.e. in the context of a particular vehicle, or for a particular
vehicle). A SEooC can be a system, an array of systems, a sub-system, a
software component or a hardware component.
• Xen is a generic reusable component that is not developed for a particular
vehicle, so Xen shall be treated as SEooC
• Xen has a set of “assumptions” (requirements, high-level system architecture) that must
be documented for tailoring to a safety system

12. Certification path for Xen
• Generic scope, easy to contribute:
• Identify & eliminate gaps in documentation & testing
• Implement fault processing and deterministic behavior
• FuSa-specific scope, hard to contribute:
• Implement some defensive programming techniques (MISRA subset, ISO
26262 subset) and waive against inapplicable
• Support certified tools (FuSa compliant compiler and linker e.g. clang-
based from ARM)
• Also: have safety management processes and tools in place to
maintain the “supporting evidence” and follow main release cycle

13. Key things to take care of
• In lot of projects formality takes over – we don’t want this to
happen
• We need to do meaningful things and avoid meaningless
• Stick to mainline codebase, don’t fork
• Do not increase engineering burden too much
• Actually improve for non-safety cases as well

14. Xen Certification TODOs
• Tracing the development life cycle, V-model like (UGLY)
• Documentation (requirements & design) coverage
• Testing (plans & execution) coverage
• Design & implementation
• Add fault processing
• Use defensive programming
• Improve overall system determinism

15. Fault processing
• Systematic Faults - proper design, validation and verification
• Transitional Faults - processing
• Why it makes sense for also non-safety Xen

16. Defensive programming
• Avoid nasty stuff
• Define “nasty”... dynamic memory allocation?
• Why it makes sense for also non-safety Xen

17. Determinism
• Cache coloring - please see session by Stefano
• Real time scheduling fixes and further development
• Preemptive Xen - point to old work of Sang-Bum
• Why it makes sense for also non-safety Xen

18. Workflow
• Assumptions
• We have defined a “safety compliant” codebase
• We have agreed on rules and approach for fault processing, defensive
programming, determinism
• We have significantly improved on testing and documenting things –
artifacts and processes in place
• Maintain the process
• Running tests for all changes and documenting all changes properly
• Identify changes that break rules (fault processing, defensive
programming, determinism) for defined codebase
• Lots and lots of paperwork
• Collaborating with assessors (learning something new every day)