search

zephyrproject-rtos / reqmgmt

8 stars 10 forks source link

RFC: Naming of the different Zephyr OS specification levels #23

Closed romkell closed 3 months ago

romkell commented 8 months ago

Current situation

The currently used names

for the Zephyr OS specifications do not seem to be ideal to reflex their content. "High level" is not very specific and "functional" is often used in the context of "functional and non-functional". They also do not seem to be near any name used by the various safety standards such as 61508, 26262, 50128, DO-178 and alike. For easier reuse of downstream Zephyr OS user building systems which will comprise Zephyr OS and shall comply with the listed standards, more common names are an advantage.

Goal

Find specification names that will be recognized in the respective industries because the name is close enough to their (safety, security?) standards.

Approach

Definitions

Collection

IEC EN 61508-3:2010 [Industry in general]

EN 50128:2011 / EN 50657:2017 [Railway]

ISO 13849-1:2023 [Safety of machinery parts]

IEC 62061:2021 [Safety of machinery]

EN 60601 [Medical]

ISO 26262 [Automotive]

DO-178 [Airborne]

quarterbit commented 8 months ago

For ISO 26262 [Automotive] some of the relevant namings:

As a starting point.

romkell commented 8 months ago

For ISO 26262 [Automotive] some of the relevant namings:

* Software Safety Requirements Specification

* Software Architectural Design Specification (iso26262-6.7)

* Software Unit Design

* Software Verification Specification

* Software Verification Report

As a starting point.

Cheers.

legrand-gregshue commented 7 months ago

Architecting/designing a solution is a recursive decomposition activity. The elements identified in one level get broken down into sub-elements in the next level. This recurses as many times as necessary to reach sub-elements with low enough complexity to be directly implemented and verified. This activity starts with solution providers/product manufacturers. They may have multiple recursions before choosing to introduce the Zephyr ecosystem and may need multiple recursions for proprietary subsystems/drivers they introduce. (IIRC, NASA publicly discloses they have typically had 5-8 recursion levels in their system designs.)

What is the plan for identifying/organizing/relating these documents when multiple recursion levels exist?

stanislaw commented 7 months ago

The European space industry:

TL;DR

Customer-level:

All of these documents typically contains inputs from other guidelines and standards and make them directly applicable to what supplier is to produce.

Supplier-level:

Here's a longer version with a disclaimer: I didn't see / attend to the whole world of spacecraft development :)

The European space industry's documents governed by the ECSS standards assume a customer-supplier relationship.

The customer-level software requirements document is typically called Software System Specification (SSS). The supplier-level – Software Requirements Specification (SRS). The SSS focuses on the WHAT of a to-be-developed product and is written by a customer. The SRS focuses on the HOW and is written by a supplier.

This highly depends on the contractual arrangements and the types of the companies, but very often a customer and a supplier DO NOT exchange the SSS and SRS documents directly. Instead, a customer provides an Interface Requirements Document (IRD) to a supplier, and the supplier answers with an Interface Control Document (ICD). The communication therefore happens only at the black-box interface level. Whether or not the customer sees into the details of the supplier's design and implementation again depends on both companies' experience and a contractual arrangement.

If a project is small enough or there is a full transparency, the IRD and ICD could be merged back to the SSS and SRS respectively and exchanged directly between a customer and a supplier. In that case, they simply become chapters of "Interface Requirements" in the SSS and SRS documents.

Finally, in accordance with @legrand-gregshue's comment just above, the SSS is typically not a top-level document in a specification tree. If a project is initiated by the European Space Agency, it can start with a Statement of Work document that contains the most high-level requirements. Depending on the size of a program, the next levels can include one or more Technical Requirements Specifications which cover and breakdown into all spacecraft subsystems, including software. These documents can receive inputs from a number of other documents and agency/company-level guidelines to completely represent a solid background for all inputs to the SSS. Only starting from this level, the actual Software System Specification starts to be written. I have not yet seen an SSS to be a top-level document in a space project.

Zephyr is not a spacecraft but I would still assume that the WHAT and HOW requirements levels must be well separated as if the Zephyr development implemented a "safe and secure RTOS" (WHAT). This is what I also do for StrictDoc and it seems to work well as in the "A requirements tool" vs "The StrictDoc requirements tool" levels.

kestewart commented 3 months ago

From discussions in the Safety working group this has been decided for the project and merged in. This should satisfy https://github.com/zephyrproject-rtos/zephyr/pull/71953