FuSa SIG/Charter: Difference between revisions
Lars.kurth (talk | contribs) No edit summary |
No edit summary |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{InfoLeft|This charter is not yet finalized}} |
|||
= Background = |
= Background = |
||
Modern safety critical systems such as autonomous vehicles or industrial robots are constantly and rapidly increasing their complexity with cloud-connected and dynamically deployed functions. Keeping such systems “safe” may require reducing their complexity by separating critical and non-critical parts |
Modern safety critical systems such as autonomous vehicles or industrial robots are constantly and rapidly increasing their complexity with cloud-connected and dynamically deployed functions. Keeping such systems “safe” may require reducing their complexity by separating critical and non-critical parts which can be achieved with Xen. |
||
= Goal = |
= Goal = |
||
Xen can be safety-certified: it has been certified in the past by individual companies, and experts groups have confirmed its certifiability after careful analysts of the codebase and contribution processes. However, the burden of the certification process falls on the user. The goal of the Xen FuSa SIG is to reduce this burden by moving upstream Xen closer to safety-certifiability. The Xen FuSa SIG oversees activities such as improving the Xen code quality and producing artifacts (documentation, tests, traceability matrices, etc.) necessary for certifications. |
|||
Create a framework and all required artifacts (documentation, tests, traceability matrices, etc.) that can be used to build and certify safety-critical systems (e.g compliant to IEC61508 or ISO26262) based on mainline Xen hypervisor codebase. |
|||
= Members = |
= Members = |
||
| ⚫ | |||
Implementers |
|||
| ⚫ | |||
| ⚫ | |||
| ⚫ | |||
* EPAM (Artem Mygaiev, Alex Agizim) |
* EPAM (Artem Mygaiev, Alex Agizim) |
||
* LF (Kate Stewart) |
* LF (Kate Stewart) |
||
* Renesas (Hisao Munakata) |
* Renesas (Hisao Munakata) |
||
* Resiltech (Francesco Rossi) |
* Resiltech (Francesco Rossi) |
||
* |
* AMD (Stefano Stabellini, Ayan Kumar Halder) |
||
Assessors |
Assessors |
||
| Line 31: | Line 28: | ||
SIG activities can be represented in several streams: |
SIG activities can be represented in several streams: |
||
=== |
=== Code Quality === |
||
Definition and implementation for the safety management system that can coexist with generic Xen mainline development. |
|||
''Keywords: hazard analysis, safety manual'' |
|||
=== Process to eliminate gaps of community-driven development === |
|||
Define and implement processes to keep design documentation artifacts (requirements, architecture, design) and corresponding validation & verification artifacts updated without significant changes in existing development process and tools. This may include creating guidelines to keep existing public documentation updated - a change requiring support for all key members of Xen project community (maintainers, committers), as well as retrospective application of defined guidelines to existing codebase. Many of such artifacts can be made public which will benefit the community. |
|||
Improve Xen code quality and safety. Implement features to improve real-time and reduce interference. Improve Xen coding style and align it with MISRA-C. |
|||
| ⚫ | |||
''Keywords: MISRA, code quality, static analysis, real-time'' |
|||
=== Process for interacting with mainline development community === |
|||
=== Documentation === |
|||
Define and implement processes to keep a subset of Xen hypervisor codebase compliant without significant impact on generic mainline development. This may include implementing guidelines and changes to coding standard, probably the most painful change requiring support for all key members of Xen project community (maintainers, committers), as well as retrospective application of defined guidelines to existing codebase. |
|||
Define and implement guidelines, templates and examples related to requirements, architecture, design and API documentation. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed. |
|||
''Keywords: MISRA, fusa clang compiler, code maintainability, code coverage, static analysis'' |
|||
''Keywords: documentation,'' ''requirements, architecture, design, APIs,'' ''traceability'' |
|||
=== Process automation tools === |
|||
=== Verification Tests === |
|||
Most of the processes above shall be optimized or fully automated with software tools - either existing or new, FOSS or proprietary. |
|||
Define and implement guidelines and examples related to the verification of requirements, architecture, design and APIs as required for safety certification. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed. |
|||
''Keywords: code minimization tool, impact analysis tool, coverity, qa-verify, osstest'' |
|||
| ⚫ | |||
= Considerations = |
|||
At the initial stage SIG operate independently from Linux Foundation but this may be changed with time. |
|||
[[Category:Safety Certification/FuSa SIG]] [[Category:Safety Certification]] |
[[Category:Safety Certification/FuSa SIG]] [[Category:Safety Certification]] |
||
Latest revision as of 14:35, 25 September 2024
Background
Modern safety critical systems such as autonomous vehicles or industrial robots are constantly and rapidly increasing their complexity with cloud-connected and dynamically deployed functions. Keeping such systems “safe” may require reducing their complexity by separating critical and non-critical parts which can be achieved with Xen.
Goal
Xen can be safety-certified: it has been certified in the past by individual companies, and experts groups have confirmed its certifiability after careful analysts of the codebase and contribution processes. However, the burden of the certification process falls on the user. The goal of the Xen FuSa SIG is to reduce this burden by moving upstream Xen closer to safety-certifiability. The Xen FuSa SIG oversees activities such as improving the Xen code quality and producing artifacts (documentation, tests, traceability matrices, etc.) necessary for certifications.
Members
- ARM (Antonio Priore, Bertrand Marquis, Robin Randhawa)
- Citrix (George Dunlap)
- EPAM (Artem Mygaiev, Alex Agizim)
- LF (Kate Stewart)
- Renesas (Hisao Munakata)
- Resiltech (Francesco Rossi)
- AMD (Stefano Stabellini, Ayan Kumar Halder)
Assessors
- Exida (Piotr Serwa)
- MIRA (David Ward)
- TUV Rheinland (Robert Heinen)
- TUV SUD (Bernhard Nalte, Claudio Gregorio)
Scope
SIG activities can be represented in several streams:
Code Quality
Improve Xen code quality and safety. Implement features to improve real-time and reduce interference. Improve Xen coding style and align it with MISRA-C.
Keywords: MISRA, code quality, static analysis, real-time
Documentation
Define and implement guidelines, templates and examples related to requirements, architecture, design and API documentation. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed.
Keywords: documentation, requirements, architecture, design, APIs, traceability
Verification Tests
Define and implement guidelines and examples related to the verification of requirements, architecture, design and APIs as required for safety certification. Develop a strategy to produce missing documentation and work with the Community Interactions and Processes stream to ensure documentation stays up-to-date and is generated where needed.
Keywords: traceability, testing, dynamic analysis
