From 4abdce1f012c6d4e82db4c72c7eac1269bae45a6 Mon Sep 17 00:00:00 2001 From: Rob Craig Date: Mon, 25 Nov 2024 11:34:26 -0500 Subject: [PATCH] Create 2024-11-15.md Adds meeting minutes/agenda SPDX FuSa Meeting 2024-11-15 --- safety/2024/2024-11-15.md | 48 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 48 insertions(+) create mode 100644 safety/2024/2024-11-15.md diff --git a/safety/2024/2024-11-15.md b/safety/2024/2024-11-15.md new file mode 100644 index 00000000..c1cbea67 --- /dev/null +++ b/safety/2024/2024-11-15.md @@ -0,0 +1,48 @@ +# SPDX FuSa Meeting 2024-11-15 +## Attendees +- Steven Carbno +- Alfred Strauch +- Nicole Pappler +- Chuck Wolber +- Sandra Hermoso Rodriguez + +## Agenda +- 3.1 Schedule & Branch Info +- Review of Class & Properties to be submitted, division of work +- Gaps still to be defined + +## Notes +- discussing https://docs.google.com/presentation/d/1i4hmr4UZTDdcNv1YRS4vYWqpiknzCoytHbgdv_wnFhc/edit?usp=sharing +- a piece of hardware is never just a piece of hardware but always a result of a process with a specific specification +- proposal to address the most rigorous standards (DO 178 & DO 330) with the FuSa profile +- covering IOS 26262 is not nearly enough for aerospace +- rigorous approach can be used also for lower level safety needs +- process refinement + - continuant: exists (produced torque wrench) + - occurant: has starting and ending (standard for creating accurate torque wrenchs) + - example: DO-178C would be considered as process, so should be considered occurant. + - processes should only call to processes. + - implementatoin of a process in hardware and software world. Abstraction and processes, in functional safety. Defining specifics of what need to happen. Part of BOM requirement. Needing level of safety/security in software - expressed via requirements, specific categories are instances that fit this. + - test against a requirement, that references a process, which is a standard. + - Only fulfill requirements. All the requirements as a group, would be referencing the process. + - Evidence is also referencing the processes, but should be tied to specific requirement. +- Discussion of Basil + - testing concept is lining up with generation of evidence. + - capturing requirements, and then identifies test plans to run it, and then captures evidence. +- Example: Building a paper plane + - Hardware: piece of paper + - Specification(s): What is needed to make a paper plane (plan/model/??); How to do the folds on paper to make a plane (Organmi book with chapter on paper planes) - ** Book written by Orgami master + - Process: + - All the required elements to meet the specification (ie. which folds should be done) + - Requirements are specified for aspects of the process + - Test plan will validate requirements (what are actions of test) + - Action: Doing the process at a point in time (ie. manufacture of the paper plane) - capture event. Should be a series of folds made. (ie. Student trained to do folds, then applies the process, and makes plane) + - Test: is design validation (aka implementation assurance) ie. + - Orgami masters has validated that the book chapter is going to yield a functional paper plane. (validated design) + - Teacher looks at created plane and review it's matching the drawing + - Evidence: recording how far the plane flies: And which Individual involed with throwing the plane. + +- Cost of specs + - DO-178C (Software Considerations) is $525 + - DO-254 (Hardware Considerations) is $375 + - DO-330 (Tool Qualification) is $258 (Trust of automated system)