<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Paul,<br>
<br>
Thanks for sharing this. Hot take: felt more like a sales pitch than
a really concrete explanation. Old ways dismissed based more on
"nobody wants to do it" and "new is better". I get why that
argument has appeal, and surely some (not all) people don't do the
old ways as well as they should. But it was pretty light on why "new
will be sufficient for acceptable safety" vs. deciding that doing
the new ways really well will automatically be fine. I just
recently saw a live talk that had a lot of the same arguments and
was similarly left with more questions than answers on this topic.
Maybe those in the trenches on the new technology have a different
viewpoint. To be sure, this is not me trying to die on the hill of
the old ways, but rather expressing what I think is appropriate
caution on jumping to new system design approaches on life critical
systems. <br>
<br>
We can justify the old way in hindsight in that it seems to work,
even if we struggle to rigorously explain why. Do we want to jump to
a new way without understanding why it is expected to work and spend
decades of mishaps climbing the hill to getting to where it really
needs to be? Or is there a way to have some confidence about it
before then?<br>
<br>
Assuming they make good on everything they plan, what would help me
a lot is understanding the basis for the safety case for their
approach in a general sense. What parts of assurance does it
provide, and what parts does it not provide? What underlying
assumptions does it make? As a simple example, supply chain attacks
will be a huge issue compared to a proprietary OS + custom
application. This is not news to them, but is an example of the type
of new challenge that might surprise us with an mishap news
headline.<br>
<br>
Discussion here is fine, but this is not something we are likely to
resolve in an e-mail chain. This is a whole discussion that needs
to happen over many years in many forums. And it is not just about
FOSS in general. There are these concerns plus additional specific
concerns about using machine learning technology, tool chains and
libraries as well, in which we already have multi-ton machines
hurtling down public roads by companies who have decided (most, but
not all of them) that core safety standards -- including ones
specifically for their technology -- are irrelevant because they
stifle innovation.<br>
<br>
We might not be happy with old-school safety practices, but there
are lessons there learned the hard way over decades. We should be
reluctant to throw them out wholesale without taking some time to
figure out what lessons we need to learn with the new approaches.<br>
<br>
My own take on this topic in a somewhat more abstract discussion is
here, in which I point out the gaps in understanding how/why current
approaches work and how we might close those gaps going forward for
any approach: <br>
<ul
style="color: rgb(0, 0, 0); font-family: "Times New Roman"; font-size: medium; font-style: normal; font-variant-ligatures: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; white-space: normal; text-decoration-thickness: initial; text-decoration-style: initial; text-decoration-color: initial;">
<li>Johansson, R. & Koopman, P., "<a
href="https://users.ece.cmu.edu/~koopman/pubs/Johansson2022_CARS_ContinuousLearningSafety.pdf">Continuous
Learning Approach to Safety Engineering</a>," Critical
Automotive Applications: Robustness & Safety /
CARS@EDCC2022.</li>
<li><a class="moz-txt-link-freetext" href="https://users.ece.cmu.edu/~koopman/pubs/Johansson2022_CARS_ContinuousLearningSafety.pdf">https://users.ece.cmu.edu/~koopman/pubs/Johansson2022_CARS_ContinuousLearningSafety.pdf</a><br>
</li>
</ul>
<br>
Kind regards,<br>
Phil<br>
<br>
<br>
<div class="moz-cite-prefix">On 2/8/2025 10:03 PM,
<a class="moz-txt-link-abbreviated" href="mailto:paul_e.bennett@topmail.co.uk">paul_e.bennett@topmail.co.uk</a> wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e6042e7195c86c66065ba9f3c0afe75020291d76d5aa0e24@smtp.hushmail.com">
<pre wrap="" class="moz-quote-pre">I cannot recall if this might have been linked in recently, but from
the date iof the talk, probably not.
<a class="moz-txt-link-rfc2396E" href="https://fosdem.org/2025/schedule/event/fosdem-2025-6204-the-trustable-software-framework-a-new-way-to-measure-risk-in-continuous-delivery-of-critical-software/"><https://fosdem.org/2025/schedule/event/fosdem-2025-6204-the-trustable-software-framework-a-new-way-to-measure-risk-in-continuous-delivery-of-critical-software/></a>
Paul gives a view on the attempt to evaluate Free Open Source
Software for trustability. I offer the link with no further comment
or claim from my side. I'll let people make up their own minds.
Regards
Paul E. Bennett IEng MIET
Systems Engineer
Lunar Mission One Ambassador
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Prof. Phil Koopman <a class="moz-txt-link-abbreviated" href="mailto:koopman@cmu.edu">koopman@cmu.edu</a>
(he/him) <a class="moz-txt-link-freetext" href="https://users.ece.cmu.edu/~koopman/">https://users.ece.cmu.edu/~koopman/</a></pre>
</body>
</html>