Skip to content

Commit 839cd2f

Browse files
AlexCelesteAlexCeleste
authored
[Liaison] Agenda for 2025-10-02 (#467)
* [Liaison] Agenda for 2025-10-02 * [Liaison] Minutes for 2025-10-02
1 parent 5747b4c commit 839cd2f

1 file changed

Lines changed: 156 additions & 0 deletions

File tree

  • subcommittee/liaison/meetings/2025-10-02

‎subcommittee/liaison/meetings/2025-10-02/minutes.md‎

Lines changed: 156 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,156 @@
1+
# **Liaison Subcommittee Meeting on 2025-10-02 @ 1600 BST / 1700 CEST / 1100 EDT**
2+
3+
[Link](https://www.worldtimebuddy.com/?qm=1&lid=14,12,1850147,5&h=14&date=2025-10-2&sln=16-17&hf=1) to meeting time in common time zones.
4+
5+
| Search Key | Description |
6+
| ----- | ----- |
7+
| \[todo\] | Action Item |
8+
| \[decision\] | Something decided on |
9+
| \[important\] | Key information |
10+
11+
## **“ISO26262 and Rust”**
12+
13+
## **Agenda**
14+
15+
1. Solicitation of notetaker
16+
2. Introduction of speaker
17+
3. Broad scope introduction:
18+
* What is functional safety?
19+
* What are the basics of achieving functional safety for a product?
20+
* Including ASILs
21+
* How tools can assist
22+
* Why they need to be certified
23+
4. Question and answers
24+
5. Round table
25+
26+
## **Check-in area**
27+
28+
**Please add your name, and an emoji that describes your day.**
29+
30+
* Andrew Fernandes ☕
31+
* Tshepang 🙂
32+
* Samuel Wright
33+
* Oreste Bernardi 🛟
34+
* Douglas Deslauriers 😷
35+
* Pete LeVasseur 🚗🦺
36+
* Car
37+
* Joni Pelham ✈️ safety
38+
* José Rui Simões 🚘
39+
* Sabah Kabbou ![Veste de sécurité][image1]![Automobile en approche][image2]
40+
* John Vishnefske🚀
41+
* Félix Fischer ☕
42+
* Xander Cesari 🍳
43+
* Will Cunningham ☕
44+
* Ana Hobden
45+
* Christof Petig 🚲
46+
* Manuel Hatzl
47+
* Max Jacinto 🍀
48+
* Olivier PHILIPPE 🚘
49+
* Samuel Preston 🐱‍🐉
50+
* Orson Pessin🍺
51+
* David Wood 🦀
52+
* Tiago Silva ☕
53+
* Nicholas R. Smith ⚡🔌
54+
* Niko Matsakis 🎃
55+
* Alex Celeste ☕
56+
* Gideon Mueller
57+
* David VomLehn 🚀
58+
* Daniel Szucs 🌀👽
59+
60+
**Notetaker:**
61+
62+
* Alex Celeste ☕
63+
64+
For tips on how we take notes in the Safety-Critical Rust Consortium, please see the [Meeting Notetaker Role](https://github.com/rustfoundation/safety-critical-rust-consortium/blob/main/docs/notetaker-role.md) doc.
65+
66+
## **Tasks**
67+
68+
* Search for the \[todo\] markers
69+
70+
## **Meeting Minutes**
71+
72+
* Solicitation of notetaker (Alex); introduction of Jill Britton
73+
* Jill to introduce herself and the talk: starting at a basic level in order to ensure level field
74+
* Starting with What is meant by Functional Safety
75+
* Protective measures between system, users, and hazards caused by failure of system
76+
* Many industry-specific standards:
77+
* IEC 61508 is the parent ISO standard for functional safety, with industry-specific child standards:
78+
* ISO 26262 for Automotive, well-known, main subject of this presentation
79+
* IEC 62279 for rail
80+
* IEC 61511 for industrial processes
81+
* IEC 61513 for nuclear power plants
82+
* IEC 62061 for other machinery
83+
* DO 178B/C \- Aerospace, independent of ISO
84+
* Same fundamental core used for analysis of all of these except Aerospace: software and tools used must be shown to be safe to a similar end
85+
* *Anything* used in development is a “tool”
86+
* How we go about achieving FS
87+
* Using ISO 26262 as an example (because the basics are the same) \- find *evidence* that the requirements of a Standard have been followed
88+
* “Principle” is a statement of a requirement; ASILs list whether a requirement is highly recommended, recommended, or not applicable
89+
* Most such standards are language-oriented and look like they were designed by C users (because they were)
90+
* *“No unconditional jumps”* and
91+
* *“Restricted use of pointers”*, for example
92+
* Many asterisks on certain requirements: justifications can be provided for different approaches to meeting or not meeting
93+
* These requirements apply to a product rather than to a tool, e.g. a braking system in automotive meets these in order to certify compliance; a tool does not comply to the standard, but helps users write product code which complies
94+
* “The language handles this automatically” can be one piece of evidence of meeting a requirement, but there must be some kind of evidence
95+
* Safety Integrity Level / ASIL applies to most of these standards, ranked by criticality: D for a braking system, B for something less critical
96+
* Safety standards *do not* specify a particular language (do not mandate C despite history)
97+
* MISRA etc exist to mitigate insufficiencies of the language \- these would not be needed if the insufficiencies did not exist at all
98+
* Static analysis is recommended (but not compulsory) in order to both:
99+
* Automate compliance with Guidelines, *and*
100+
* To check quality of the code
101+
* Standards *do not* mandate full compliance to Guidelines
102+
* You don’t have to enforce guidelines that are not relevant, but in that case, **you do have to prove they are not relevant**
103+
* “Strong typing” is an example of a requirement that can easily be determined to be provided by a language because it is usually a language feature.
104+
* How tools can assist
105+
* Compilers, static analysis tools, and similar; are *certified* to meeting FS requirements
106+
* Users need to provide the evidence tables of meeting the process: certifying the tooling means the user does not need to re-demonstrate the process requirement is being met; a product developer *can* re-do this for any tool including a non-certified tool, but would have to prove it fulfils the process requirement
107+
* Tools are classified within 26262 according to impact and error detection, giving a “tool confidence”: a static analysis tool cannot introduce errors, but may miss existing ones, and these are reflected in the impact and detection
108+
* Users can add additional checking to make up for any deficiencies \- the individual tool will remain at the given TD level, but the overall system will become more robust. Using two tools is a common practice though is still not mandatory
109+
* “Confidence through use” is one possible measure of tool quality
110+
* To certify a tool: need a certification body, usually TUV or similar, who will need to assess it if new, or examine what has changed
111+
* For instance: for a static analysis tool, the whole tool could be assessed, or just some of the checkers
112+
* Certification applies to a specific version, although there is some flexibility for point-releases
113+
* Requires evidence of testing that the tool behaves as documented
114+
* Creation of a Safety Manual
115+
* “Are these manual processes or can they be automated e.g. by CI/CD?” recording this is exactly what the documentation should include \- this is how “we” do it and are recorded as doing so; how *the user* runs it is up to them to integrate
116+
* In Aerospace: lower toolchain qualification for a tool that is operated by a human running a checklist, higher threshold for an automated tool \- so that human signoff remains a part of the process (this can be counterintuitive to the mindset of a software engineer, and where the appropriate level of automation is)
117+
118+
## **Questions**
119+
120+
* What parts of the language should a Guidelines document talk about?
121+
* Every part? Can we explicitly not consider parts of the language during Guidelines development?
122+
* Yes\! **Subsetting**[^1] is encouraged
123+
* Safety elements out of context?
124+
* \[conversation moved on\]
125+
* When an element has changed how much needs to be re-certified?
126+
* Depends very much on the part of the system that is being modified (colour of vehicle vs. new engine)
127+
* For example, QAC was re-certified after adding support for MISRA C++
128+
* Automated tests \- what matters is not *how* but the result of the test? Could it happen that different approaches that result in testing incorrectly give wrong results (e.g. difference between development and production)? Does there need to be validation for the test cases themselves to ensure consistency of results? AN audit system associated with testing?
129+
* There is a requirement in DO to split responsibility between writer of test cases and requirements for them, ensuring multiple pairs of eyes
130+
* Need to specify the configuration very tightly \- should not be able to be different from production if that is what is to be tested
131+
* Needs to be repeatable
132+
* State of the art and of acceptance in the safety community? Not all guidelines are the same \- say an original set of guidelines for C that are *not* MISRA and are homegrown \- is this accepted by the community? Can it fulfil the ISO requirement?
133+
* If you write your own guidelines, they need to help to meet the listed requirements
134+
* It is OK to write new guidelines but they need to explain evidence for how they help with that; something someone has already written will already demonstrate this
135+
* Assessors like TUV-SUD are not a government agency \- they are a third-party; DO-178 is government-regulated (FAA et al) and is mandatory for aircraft at all
136+
* You do need to meet ISO26262 to put a vehicle on the road, but the auditing of that fact is independent
137+
* DO-178C is itself recommended *by* the FAA; the FAA accredits designated representatives who approve your process \- it is theoretically possible to not follow DO-178C although not very feasible
138+
* As this applies to Rust and use in Safety Critical?
139+
* The important thing remains to know what its limitations are and where they are, you still need the solid background, still need support from the community and integration into the pipeline
140+
* Rust is thinking a lot about language specification at the moment, where does a language Standard fit in, and how does its evolution over time affect this process?
141+
* This will need an entire separate hourlong meeting\!
142+
* \[TODO\] follow up on this
143+
* “Has anyone found openly available examples of Safety Manuals and accompanying documents? In my experience that is usually NDA'd”
144+
* https://public-docs.ferrocene.dev/main/safety-manual/index.html
145+
146+
## **Additional links**
147+
148+
* Article with flowchart, explaining how a tool becomes determined to be at a certain ISO 26262 Tool Confidence Level: [ISO 26262 tool qualification \- When and how to perform it](https://www.btc-embedded.com/when-and-how-to-qualify-tools-according-to-iso-26262/)
149+
* [Ferrocene Documentation › Safety Manual](https://public-docs.ferrocene.dev/main/safety-manual/index.html)
150+
151+
152+
[^1]: **Subsetting** a language here means to define and use a specific subset of a larger language. Safe Rust is a subset of Unsafe Rust. MISRA C, for example, specifically asks users to subset C in order to more easily (and decidably) satisfy their safety requirements.
153+
154+
[image1]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAC4UlEQVR4Xn2U30tTYRjHLeg/6CqLSOgHtUCbPxtTR+rmnNbcZrP0KMtpRqVYuDLtooIo6MKCyIvoqoSomyDKq0IpHTp/EGgm/shKBKVmhEVz59v7PNtx5+js4st7znk/7+d5zst5T4K50ZagzszVhi00Bp1Zm/8XNauO5mbRfXzTRKulZWxkcnRasgwMG6XeIUN1b8BQ9V6dIbvZTwweFDxR5HGFlNCVxNCY/zfw2I05qRyj6V58SKvFcJoXfXoPXmTqIfuSMD38F3h4FBsKqbtP9y5uJZiFAiapIhxIrcGbFAnfapNYONkfBu5bgacVdvWra7qb9JkWcDk5Imw3A51e7kzp7tmeMiy36GRiWHj7CPDcg7gdUpWfF/aB4Im+lQjccRKBlDIW9hyqwqOdRTyvCMPXcrho0OvRa4S0D4oMvsOR6q1G4I6TF9HrvtSdwETJDp7XMHfLWboqpL2j7kKNB1bhqX5Erm+Ucpe0d9RdqG4v0GTUMPJ1G0vlzqpd1Bh3N37J+hpnDUBzHi9gmBa2ljA8J+nRbdiNcL0uvI7x2SKF2+09LKQOp+rMgyxssoBGhvm+mGHqfj5/G1CTEYexRArftA6RKyYkuD4fqMvGzAB4xPlCoM3Jr8rCikzBFPIcCxXGZ48jZFgIPTkRoRhxWlT2udYL1Qzdk7BNJaRjBreYrBTtV0ZhMeKUEDa5sCLpMG/cDjiyxLM4zDmR5qLBOEKxwe4o7M6LL2QmL8pEhWdcWmFX57vAx7d/MOsHh+Cv0XwfB750B9F1qwsjr5ZkNUOjwvyYl2PCWYcpgNxkGcXidKyN6Chk2Y/Fg4nYmLHQVkSE9O18dpr7kSu+Kas4WrYSbTwulXADptwRE9IpCTrMHbKhAMgWkya7NqXH8Cs3GQsZJjCzdp4iipCDXKtneSld6ljWS/7lVGkslurRKXeDiyoTR9f0TMOINbRW+S9q/jZrf5bK83jXSmiN+vk/0ICjr06GXDcAAAAASUVORK5CYII=>
155+
156+
[image2]: <data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAAUCAYAAACNiR0NAAAB7klEQVR4XmNwL/BhoCbGEKAUYwhQijEEKMUYApRiDAFKMYYADE/ydmdEFyNGDkMAhC/5+jJdMXM58d3M4/83M3cw/mziBse/3EJPgNSg68NpYPaUMyyKc///k5/1/z8My039B8cgOXQ9OA0EGWay5d9i9c3//yuvx41BakBq0fVjGKgia5ftcf//f4+bEOx2BRW7XkBgkFp0/RgGmk3f+tnr4///3l///wfRIOzxDgm/hGKgpSC16PrhjI25HcyXvAp0X5kF/39uHf4fRr9xiPr/yR6C3zvEgPkgORAN4oP0gPRiGAjCf+4Vv/3zIOH/R838/6/OfPv/3L3sv7ygNxhrcLv+l+c2+/8joun/q5u///9zzv//5Urwf5AerC4E4f/vi////5X6/65s9f/3rz/9v+rb919JK/S/uorvfzV5t/9SfLr/Pxcu+w8CX4y6gWQhGOM08Jh587/Lyh3/L+v2/IfRzwwn/n9uNu3/O8vZYAxig8ReO84E8x9a9uI2UEXU5n9L3GIUXBs5+//snnW/QbgjZdl/GO7JWg7GRqouuA0EhZEOp+d/eV6jD8jiUxs3bgNhZDElfov3ILWgYMBqICgrOWslhtoIxW73Vsh2QFaEDXvL59mD1IL0IGdDFEX6qv7MMIxuADrGpRYAivZitRBTt4cAAAAASUVORK5CYII=>

0 commit comments

Comments
 (0)