Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create 2024-11-15.md #816

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Create 2024-11-15.md #816

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
48 changes: 48 additions & 0 deletions safety/2024/2024-11-15.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -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)