Artem will briefly cover what has been done since the first talk on Xen in Automotive domain back in 2013, what is going on now and what is still missing for broad adaptation of Xen in vehicles. The following topics will be covered: Embedded/automotive features of Xen Collaboration with AGL and GENIVI organizations for standardization Efforts on Functional Safety compliance Artem will also go over typical automotive use scenarios for Xen which may not be the same as generic computing use of hypervisor.

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)