Difference between revisions of "Category:Safety Certification"

From Xen
m (Contributor Spotlights)
(Added requirements section)
Line 17: Line 17:
 
* '''The AGL software defined connected car architecture''', April 2018: [https://docs.google.com/document/d/1HpYzClh0nDEocsUHb17X0DxiehsAbCgyWE-P2Wk_RNU/edit# whitepaper]
 
* '''The AGL software defined connected car architecture''', April 2018: [https://docs.google.com/document/d/1HpYzClh0nDEocsUHb17X0DxiehsAbCgyWE-P2Wk_RNU/edit# 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: [https://www.slideshare.net/linaroorg/tsc-sponsored-bof-can-linux-and-automotive-functional-safety-mix-take-2-towards-an-open-source-industry-acceptable-high-assurance-os-sfo17218 slides]
 
* '''TSC Sponsored BoF: Can Linux and Automotive Functional Safety Mix ? Take 2: Towards an open source, industry acceptable high assurance OS''', Robin Randhawa, 2017: [https://www.slideshare.net/linaroorg/tsc-sponsored-bof-can-linux-and-automotive-functional-safety-mix-take-2-towards-an-open-source-industry-acceptable-high-assurance-os-sfo17218 slides]
  +
  +
== Requirements ==
  +
  +
Automotive functions requirements for virtualized ECUs (copied from the [https://docs.google.com/document/d/1HpYzClh0nDEocsUHb17X0DxiehsAbCgyWE-P2Wk_RNU/edit# AGL whitepaper])
  +
  +
{{TODOLeft|It would be good, if we could map these to specific Xen Features, such that we see where there are gaps.}}
  +
  +
=== Computing ===
  +
  +
* C1: Static resource partitioning and flexible on-demand resource allocation (CPU, RAM, GPU and IO).
  +
* C2: Memory/IO bus bandwidth allocation and rebalancing.
  +
  +
=== Peripherals sharing ===
  +
* 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).
  +
  +
=== Security ===
  +
* 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.
  +
  +
=== Safety ===
  +
* 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.
  +
  +
=== Safety Certification ===
  +
{{TODOLeft|I left this out for now, but [[Safety Certification]] provides some initial pointers to groups of information.}}
  +
  +
==== Code Size impacting the cost of Safety Certification ====
  +
{{TODOLeft|Add coarse analyses from misc e-mail threads.}}
   
 
== Products using Xen and OpenEmbedded that need/have a degree of Safety Certification ==
 
== Products using Xen and OpenEmbedded that need/have a degree of Safety Certification ==

Revision as of 11:56, 6 April 2018

This page links to documents, public discussions, meetings, etc. related to Safety Certification of Xen Project based products or code-lines.

Icon Info.png 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.


Industry Groups having a stake in certifying Open Source Stacks

Relevant Presentations and Papers

Xen Specific

Industry Wide

  • 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

Requirements

Automotive functions requirements for virtualized ECUs (copied from the AGL whitepaper)

Icon todo.png To Do:

It would be good, if we could map these to specific Xen Features, such that we see where there are gaps.


Computing

  • C1: Static resource partitioning and flexible on-demand resource allocation (CPU, RAM, GPU and IO).
  • C2: Memory/IO bus bandwidth allocation and rebalancing.

Peripherals sharing

  • 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).

Security

  • 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.

Safety

  • 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.

Safety Certification

Icon todo.png To Do:

I left this out for now, but Safety Certification provides some initial pointers to groups of information.


Code Size impacting the cost of Safety Certification

Icon todo.png To Do:

Add coarse analyses from misc e-mail threads.


Products using Xen and OpenEmbedded that need/have a degree of Safety Certification

Products with a degree of Safety Certification

Automotive Products

Embedded/Other Products

Contributor Spotlights