Minutes 21 Aug 2025

Host: Paul Albertella

Participants: Pete Brink, Naga (TimeSys)

Agenda

• Breaking things
  • Can an understanding of how things break help to inform safety?
  • 'Practical' approach as an adjunct / alternative to pure analysis
  • Fault induction concept from RAFIA [1]
• Quality: what does this mean in the context of safety
  • What might a baseline of this for FOSS look like?
• Continue Q&A for Trustable Software Framework (TSF) [2]
  • How does this relate to the other two topics?

Notes

Discussion about software engineering

• The difference between this and ‘computer science’, ‘development’, ‘programming’, or ‘coding’ is that it is about creating software in a system context
• This means that it is heavily informed by system engineering
• One of the challenges when applying this to Linux is that it is (part of) an operating system, which means that it is providing a context in which software will execute
• This means that its role is abstracted from both the physical (hardware) context and the (application) software context
• This also means that the constraints and requirements that apply to the OS are largely (but not entirely) defined by the hardware and the applications
• Linux has evolved around, in particular the developments in processor technology by Intel, AMD and Arm
• There exists a gulf between the expectations around technology developed around this in a desktop context, and the expectations around technology used in embedded and safety-critical applications.
• Pete has a curriculum called ‘Introduction to Software engineering’ - talks about the disciplines that are involved. Did a talk about Software Engineering Competency Model.
• Thirteen categories of skills, which can be used to evaluate an individual’s level of competency
• Many of these are about personal skills, aptitudes, values, behaviours
• Paul: Can we treat the absence or lack of these things as a risk factor, which we can perhaps manage by applying ‘engineering’ measures?
• Is engineering really about the human aspects of working with technology?
• Pete’s question: “How do you know when you’re done?”
• Paul: One of the ideas with TSF is to evaluate what this means on a constant basis, but the ‘definition of done’ is always changing
• Technical skills largely follow the V-Model - Requirements, Design, etc
• Paul: These are very much framed for product development - can we unpick this and understand what each of these disciplines are intended to achieve.
• Where does quality fit in?
• Lifecycle skills - they go across all of the V-Model skill areas “Crosscutting skill”
• Most of the SWECOM is about how to evaluate individuals capabilities.

Follow-up: Use this to frame what we mean when we talk about “Open Source Engineering Process”