Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solutions, EPAM Systems

34 views

Published on

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.

Published in: Automotive
  • Be the first to comment

  • Be the first to like this

XPDDS19 Keynote: Xen in Automotive - Artem Mygaiev, Director, Technology Solutions, EPAM Systems

  1. 1. Xen in Automotive Artem Mygaiev, Technology Solutions Director at EPAM Systems
  2. 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. 3. Virtualization use case evolution
  4. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 15. Fault processing • Systematic Faults - proper design, validation and verification • Transitional Faults - processing • Why it makes sense for also non-safety Xen
  16. 16. Defensive programming • Avoid nasty stuff • Define “nasty”... dynamic memory allocation? • Why it makes sense for also non-safety Xen
  17. 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. 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)

×