Minutes 16 Oct 2025

Host: Paul Albertella

Participants: Florian Wuehr, Pete Brink, Daniel Krippner, Victor Lu, Naga (Timesys)

Agenda

1) Avoiding the 'Philosophy' trap

• Qualify those sweeping assertions!
• Share your reasoning (in detail)
• Support claims with evidence
• Repeatable = verifiable

2) The Supply Chain perspective

• Is a 'Safety Element out of Context' approach inevitable?
• What are the problems with SEooC?
• Can open source approaches help to address these deficiencies?

Notes

Safety_is_a_system_property.jpg

ISO PAS 8800 - Safety of Machine Learning in automotive

Supply chain

Paul: Do we have to think about safety specifically when we are constructing a component that is going to be used in a safety-relevant context?

Pete: Yes, because - in the automotive context - the OEM needs a level of confidence and a contractual basis for liability that extends to the suppliers.

Paul: So there is a liability imperative and a commercial imperative - and a quality management imperative - but not necessarily a safety imperative per se? In the sense of preventing harm, etc.

Pete: Safety standards in general are mostly based around liability

• Showing that you have exercised ‘due diligence’ in the process of product creation
• Aimed at minimising systematic error for systems and software

Daniel: This is the point I was trying: can we decouple the liability for these things from the actual development of the software?

• Open source decouples software development from the IP / origination of software
• Is it possible to apply a similar principle to the liability / quality dimension?

Pete: Open source projects like Eclipse SDV might potentially be a way to move towards this, but by actively considering the standards as part of their working practices

Daniel: Can we decouple the ‘standards-compliance’ aspect from the actual engineering practices by using something like TSF to manage the evidence and enable a mapping to the standards?

Paul: TSF is in the process of doing just this: aligning the guidance with the objectives of the standards, without mandating a specific process model.

Victor: How would you describe the relationship between this discussion and ISO related safety standard - is the goal to eventually for the result to become part of ISO standard ?

Paul: The problem with ISO and similar is that the standards, while public, are not freely available and not freely open to participation. This makes them particularly unsuitable for open source

Victor: This is an open source project certified for ISO 42001 compliance https://www.ibm.com/new/announcements/ibm-granite-iso-42001

Paul: Can we ‘add’ quality after the fact? Quality ultimately requires us to have some specific criteria or objectives in mind, and these are not always evident in an open source project

Pete: But establishing - documenting - what your objectives are at the outset is always valuable. And adding quality after the fact is hard.

Daniel: Quality is not a one-off thing, but you don’t always have to apply all of the quality criteria throughout the development.

The missing piece in the documentation is often the ‘why?’ - or at least the ‘why?’ in sufficient detail to guide the ongoing development of a project.

Pete : I think that Open Source might benefit from the establishment of a standard, but then we run into difficulty with explaining to a given project participant what (and why) they are supposed to work a specific way.

Daniel: There are two different types of ‘why?’: ‘why do we do things this way?’ and ‘why is the software designed / implemented in this way?’

Victor: What is the ultimate goal for this open source safety community then ?

Pete: We want an alternative to the existing safety standards. And open source alternative could remove a barrier to entry for organisations that wish to argue that their software is safe enough to be used.

Paul: TSF tries to be permissive, describing what they do and how it fulfils a set of objectives

Victor: How do organizations prove that they have successfully adopted this alternative new open standard ?

Paul: Good question! We are not there yet.

Daniel: I hope that TSF can give adopters some templates to help them bootstrap

Paul: For next time: how can we capture this in the way that other people can engage with it?,