Skip to content

Minutes 09 Oct 2025

Jump to bottom
Paul Albertella edited this page Oct 15, 2025 · 1 revision

Host: Paul Albertella

Participants: Daniel Krippner, Pete Brink, Igor Stoppa, Naga (Timesys)

Agenda

  1. New PR from Daniel (OSS and safety supply chains)
  1. Continue with the 'open source engineering process' topic
    • Same list of questions from the last session.

Notes

Two different ‘cultural perspectives’: ‘open source’ and ‘traditional engineering’

  • Start from a different set of preconceptions
  • Not mutually antagonistic, but can miss the point of what the other school believes to be necessary (or sufficient)

Pete: One aspect of this is the principle of iteration: you don’t have to start with a ‘finished’ design in order to make useful progress

Igor: Some boundaries are needed:

  • If we stray too far away from what is expected for certification, we can tend to talk in ‘philosophy’ rather than what is needed in practice
  • We can expect someone further down the supply chain to deal with some of the challenges, but the earlier we can deal with the problems the better

Pete: Thinking about the eventual system integrator as our ‘customer’ may be the best way to think about this

Daniel: Arguing in the document that these aspects do not necessarily have to be considered in all of the contexts involved in a supply chain.

  • Not a fan of the ‘out of context’ concept in general, but thinking about how and where the liability / assurance resides in the supply chain, and whether it can be decomposed

Igor: Responsibility distributed through a supply chain makes ‘out of context’ unavoidable

  • The longer the supply chain the more remote the context may be
  • What is necessary in any given context may not be evident until a specific context is being considered
  • Ultimately need hard evidence, not philosophy

Paul: Can we call it ‘reasoning’ instead of ‘philosophy’?

  • Igor: With reasoning, it is possible to reach some agreement

Pete: Empiricism is a philosophy, which demands that we consider the context, and provide evidence to support our reasoning and claimed solution for a given problem

Daniel: Intent was that this text would provide a context for discussing a more detailed approach / solution.

Igor: Understanding of scope and complexity is an important part of this.

Pete: We also need to consider risk

Paul: My problem with ‘safety element out of context’ has always been that trying to make a perfect component for any safety critical context is not realistic when you are building complex systems

  • Igor: I’d argue that it is not impossible to do this, but it may be impossible within a given set of constraints (e.g. you have 3 months to do this)

Paul: Constructing systems from components with known flaws or limitations and adding measures and/or mechanisms to mitigate these can result in defensibly ‘safe’ systems

  • Igor: This starts from the assumption that we can’t do any better than this
  • If I cannot solve a problem, that doesn’t mean that it is not soluble

Pete: Can we focus on what kind of practices we can advocate that will accomplish our engineering objectives and be something that open source communities can engage with

  • The simpler the better, the more logical the better

Igor: Why should we expect anything from the upstream Linux community?

  • Paul: Agree that expecting ‘safety’ from them is not viable, but encouraging them to adopt (or make possible) engineering practices that make our lives easier

Clone this wiki locally