This page links to documents, public discussions, meetings, etc. related to Safety Certification of Xen Project based products or code-lines.
|At this stage this category is primarily a place where to track various activities and also to see who is interested in certification efforts of Xen and who could perform which role.|
- 1 Industry Groups having a stake in certifying Open Source Stacks
- 2 Relevant Presentations and Papers
- 3 Automotive Requirements
- 4 Functional Safety Requirements
- 5 Products using Xen and OpenEmbedded that need/have a degree of Safety Certification
- 6 Contributor Spotlights
Industry Groups having a stake in certifying Open Source Stacks
- Automotive Grade Linux Virtualization Expert Group
- Members with Xen based products: GlobalLogic (bronze), StarLab (bronze)
- Members which indirectly support Xen in this context: Renesas (platinum), Arm (gold)
- Members which are also Advisory Board members: Amazon (silver), Qualcomm(silver), Oracle (bronze)
- Genivi: Hyervisor Team (or a group that will eventually become one)
- Linaro: I am not sure whether there is a Linaro group yet, if so it would be worth adding it here
Relevant Presentations and Papers
- Summary Table Comparing Different Hypervisors (March 2018)
- Xen and the Art of Certification - Nathan Studer, DornerWorks, 2014: video, slides
- The AGL software defined connected car architecture, April 2018: whitepaper
- TSC Sponsored BoF: Can Linux and Automotive Functional Safety Mix ? Take 2: Towards an open source, industry acceptable high assurance OS, Robin Randhawa, 2017: slides
Automotive functions requirements for virtualized ECUs (copied from the AGL whitepaper)
It would be good, if we could map these to specific Xen Features, such that we see where there are gaps.
- C1: Static resource partitioning and flexible on-demand resource allocation (CPU, RAM, GPU and IO).
- C2: Memory/IO bus bandwidth allocation and rebalancing.
- P1: GPU and displays shall be shared between execution environments supporting both fixed (each one talks to its own display or to a specified area on a single display) and flexible configurations (shape, z-order, position and assignment of surfaces from different execution environments may change at run time).
- P2: Inputs shall be routed to one or multiple execution environments depending on current mode, display configuration (for touchscreens), active application (for jog dials & buttons), etc.
- P3: Audio shall be shared between execution environments. Sound complex mixing policies for multiple audio streams and routing of dynamic source/sink devices (BT profiles, USB speakers/microphones, etc.) shall be supported.
- P4: Network shall be shared between execution environments. Virtual networks with different security characteristics shall be supported (e.g., traffic filtering and security mechanisms).
- P5: Storage shall support static or shared allocation, together with routing of dynamic storage devices (USB mass storage).
- SE1: Root of Trust and Secure boot shall be supported for all execution environments.
- SE2: Trusted Computing (discrete TPM, Arm TrustZone or similar) shall be available and configurable for all execution environments.
- SE3: Hardware isolation shall be supported (cache, interrupts, IOMMUs, firewalls, etc.).
- SE4: Secure updates shall be supported.
Performance and Power consumption
- PP1: Virtualization performance overhead shall be minimal: 1-2% on CPU/memory benchmarks, up to 5% on GPU benchmarks.
- PP2: Predictability shall be guaranteed. Minimal performance requirements shall be met in any condition (unexpected events, system overload, etc.).
- PP3: Execution environments fast boot: Less than 2 seconds for safety critical applications, less than 5 seconds for Instrument Cluster, and 10 seconds for IVI. Hibernate and Suspend to RAM shall be supported.
- PP4: Execution environments startup order shall be predictable.
- PP5: Advanced power management shall be implemented with flexible policies for each execution environment.
- SA1: System monitoring shall be supported to attest and verify that the system is correctly running.
- SA2: Restart shall be possible for each execution environment in case of failure.
- SA3: Redundancy shall be supported for the highest level of fault tolerance with fallback solutions available to react in case of failure.
- SA4: Real time support shall be guaranteed together with predictive reaction time.
Functional Safety Requirements
I left this out for now, but Safety Certification Challenges provides some initial pointers to groups of information.
Code Size impacting the cost of Safety Certification
Products using Xen and OpenEmbedded that need/have a degree of Safety Certification
Products with a degree of Safety Certification
Pages in category "Safety Certification"
The following 14 pages are in this category, out of 14 total.
- FOSS Industry Groups with a stake in Safety Cerification
- FuSa SIG/Charter
- FuSa SIG/Meetings
- FuSa SIG/Minutes/2019-05-14
- FuSa SIG/Work Stream/Community Interactions and Processes
- FuSa SIG/Work Stream/Documentation
- FuSa SIG/Work Stream/Process Automation Tools
- FuSa SIG/Work Stream/Safety Management System
- FuSa SIG/Work Stream/Verification Tests