[SystemSafety] A Fire Code for Software?

[Tom Ferrell]

As with so many things, I would contend that MBDV helps in some ways and hurts in others.  While I share many of Michael’s angst over DO-331 (along with just about every other output of that committee). I do feel there is value in the overall concept of MBDV.  Specifically, if done well, it allows for a much easier to understand representation of the system/software allocation and helps to ensure the transformation at that boundary is both complete and accurate.  It also enables the possibility for dynamic execution of the model in such a way that architectural issues such as invalid state machine transitions and impacts of problems with I/O can be located early.  Of course, all of this is dependent on the fidelity of the model and should never be taken as wholesale proof that the final implementation is correct.  The major downside of MBDV is by using abstraction, often many levels of it, the engineers may not understand or more likely even consider the types of defects that can arise in the underlying code.  This is particularly troublesome given the increasing reliance on autocode generation, especially when this model to code transformation is not done using formal methods to ensure the correctness of that transformation.  Just as with so many other possible ‘silver bullets’ brought forward in the software engineering domain, there is a major need to ‘trust but verify’ the output of the tools.

From: systemsafety [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of C. Michael Holloway
Sent: Wednesday, March 7, 2018 7:53 AM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] A Fire Code for Software?

 On 2018-03-06 (15.41.49), Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com> wrote:
“Model based software development, accountancy packages, stress analysis packages, etc. - all contribute to the diminution of understanding in the user base.”

What is your definition of “model based software development”? According to my definition, exactly the opposite is true: “Lack of model based software development contributes to the diminution of understanding in the user base”
Over the many years I've been a subscriber to this list and its predecessors, I've read many statements with which I disagree, usually without responding. To the best of my memory there's ever been a statement with which I have disagreed more than the last sentence above. To the extent that there exist good ideas in "model based software development" they are nothing more than renaming of ideas that are almost as old as I am. To the extent that it does differ from established practices, it differs in ways that are detrimental to understanding, coherence, and competency.

Consider for example, DO-331 "Model-Based Development and Verification Supplement to DO-178C and DO-278A". It is 136 pages long, some 126 longer than it needed to be to provide adequate guidance for the subject. It is, being charitable, often incoherent. Of several regrets about my actions during SC-180/WG-71, the biggest is not trying even harder to prevent the approval of this document by the committee. Having an anti-MBDV supplement text message displayed on the Staples Center scoreboard during a Lakers game was cool, but not enough. :-)
--
All the best,
C. Michael Holloway (cMh)
Senior Research Computer Engineer
NASA Langley Research Center, Hampton VA USA
bit.ly/cmhpubs<http://bit.ly/cmhpubs>

Verba volant, scripta manent
spoken words fly away, written words remain

(The words in this message are mine alone;
neither blame nor credit NASA for them.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20180307/faa256ce/attachment.html>