Live data from Hacker News

Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

pdfs.semanticscholar.org

31–40 of 40 posts

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#31
post #11

Earlier quoted context omitted.

PLM I'm familiar with, though none of the ones I've seen seem to focus in any particular was on the requirements/specification end of the equation...

Ah okay. So PLM systems would be used to store and manage the requirements, the requirement documents are going to be, at least in my corner of the world... Word and/or Excel templates.

On my corner of the world it would UML, using tools like Enterprise Architect.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#32
post #27
post #26

Earlier quoted context omitted.

A few years ago, AdaCore's Robert Dewar observed that nobody has ever been killed by a flaw in Avonics software. That's perhaps not a good elevator pitch for a hockey stick startup but it's a good testament to the capabilities and skills of the people in the High Integrity community. It's true that High Integrity development is not compatible with deadline or budget driven projects. But there is a lot to learn from t…

> A few years ago, AdaCore's Robert Dewar observed that nobody has ever been killed by a flaw in Avonics software. While that may be technically correct, I would consider the crash of Air France Flight 447 to be partially an avionics software failure. Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state (alternate law) and throwing con…

> partially an avionics software failure... Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state

You could write that software in rust to do exactly the same thing.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#33
post #30
post #25

Earlier quoted context omitted.

> I'm always surprised by how thoroughly uninterested the Haskell and Rust communities are in learning from the Ada/High Integrity Software community. If you read the paper you would find that the VAST majority of issues were human communication or understanding of the problem. No programming language can fix that. Rust was started with one overriding goal: make programming on Firefox manageable. And they identified…

Ada exists where killing people is not an option for sloppy programming. The moment software companies start to actually pay heavy fines and are forced to do refunds for sloppy software like in other industries, the situation will change.

Probably an advantage of Ada vs other languages, hard to find a sloppy Ada programmer.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#34
post #32
post #27

Earlier quoted context omitted.

> A few years ago, AdaCore's Robert Dewar observed that nobody has ever been killed by a flaw in Avonics software. While that may be technically correct, I would consider the crash of Air France Flight 447 to be partially an avionics software failure. Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state (alternate law) and throwing con…

> partially an avionics software failure... Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state You could write that software in rust to do exactly the same thing.

Quoting myself upthread:

> If you read the paper you would find that the VAST majority of issues were human communication or understanding of the problem. No programming language can fix that.

At no point did I argue that Rust would have prevented the Air France Flight 447 kind of failure. However, neither would Ada have prevented this kind of failure.

I WAS however taking issue with the quoted "nobody has ever been killed by a flaw in Avonics software".

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#35
post #24

Can't help but think we'd learn a lot if other industries were as mature in tracking these things as the safety critical ones.

I'm always surprised by how thoroughly uninterested the Haskell and Rust communities are in learning from the Ada/High Integrity Software community. Here you have people who are actually doing what you purport to be interested in (creating defect-free code) who have a great deal of experience and a great many insights from actually putting their code into avionics bays knowing that thousands of lives are depending up…

Hm, I find this to be a pretty mischaracterizing view of Rust. Nobody on the core team lives in California. We never talk about category theory. Our average age is mid-30s. And in general, we love hearing about other languages, including Ada.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#36
post #24

Can't help but think we'd learn a lot if other industries were as mature in tracking these things as the safety critical ones.

I'm always surprised by how thoroughly uninterested the Haskell and Rust communities are in learning from the Ada/High Integrity Software community. Here you have people who are actually doing what you purport to be interested in (creating defect-free code) who have a great deal of experience and a great many insights from actually putting their code into avionics bays knowing that thousands of lives are depending up…

If we are talking about the community of users, the experiences of Ada programmers are likely of no little help to someone working with Haskell. Ada is an imperative language with explicit declarations and mutation everywhere. Its mechanims to help out with safety basically have to do with managing side effects.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#37
post #34
post #32

Earlier quoted context omitted.

> partially an avionics software failure... Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state You could write that software in rust to do exactly the same thing.

Quoting myself upthread: > If you read the paper you would find that the VAST majority of issues were human communication or understanding of the problem. No programming language can fix that. At no point did I argue that Rust would have prevented the Air France Flight 447 kind of failure. However, neither would Ada have prevented this kind of failure. I WAS however taking issue with the quoted "nobody has ever been…

> Avonics software

It's not the software that killed people it's the spec.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#38
post #24

Can't help but think we'd learn a lot if other industries were as mature in tracking these things as the safety critical ones.

I'm always surprised by how thoroughly uninterested the Haskell and Rust communities are in learning from the Ada/High Integrity Software community. Here you have people who are actually doing what you purport to be interested in (creating defect-free code) who have a great deal of experience and a great many insights from actually putting their code into avionics bays knowing that thousands of lives are depending up…

We're using Rust in building safety-critical runtime software for autonomous vehicles precisely because we do care about these kinds of things for non-R&D products.

We have many experiments showing how trivially easy it is to write MISRA compliant C, that normally passes muster for "safety-critical" in automotive, which is horribly unsafe, but for which analogous Rust fails to even compile.

We're also working to go many steps beyond ISO 26262 in terms of process and process verification. To the point that we're going to attempt to have a formally verified development lifecycle in addition to as much of the software that comes out of it being formally verified as well.

We're not stopping at formal verification for the software or process either due to fairly glaring gaps/shortcomings in the methods available today.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#39
post #27
post #26

Earlier quoted context omitted.

A few years ago, AdaCore's Robert Dewar observed that nobody has ever been killed by a flaw in Avonics software. That's perhaps not a good elevator pitch for a hockey stick startup but it's a good testament to the capabilities and skills of the people in the High Integrity community. It's true that High Integrity development is not compatible with deadline or budget driven projects. But there is a lot to learn from t…

> A few years ago, AdaCore's Robert Dewar observed that nobody has ever been killed by a flaw in Avonics software. While that may be technically correct, I would consider the crash of Air France Flight 447 to be partially an avionics software failure. Responding to an inconsistent airspeed measurement by disconnecting the autopilot and then dropping into a weird, modal operating state (alternate law) and throwing con…

Welcome to the entire basis of SAE Level-3 autonomy. Yes, it does often seem fairly silly.

Re: Software Requirements Errors in Safety-Critical, Embedded Systems (1993) [pdf]

#40
post #29

Strange how whatever Adrian Colyer covers in his The Morning Paper makes its way here. People perfer posting the original paper rather than his blogs posts.

This happens because the HN submission guidelines at https://news.ycombinator.com/newsguidelines.html say: “Please submit the original source. If a post reports on something found on another site, submit the latter.” The main objective is to highlight and share interesting research, and if a post on ‘The Morning Paper’ achieves that and promotes informative discussions like the ones in this thread, then I’m happy. On…

Thanks for taking out the time to write such an elaborate clarification, Mr Colyer. I was unaware of the guidelines until you brought them to my attention. I myself am quite an avid reader of The Morning Paper, and was initially taken aback to see that people post the original paper after reading your blog, and don't mention you anywhere. It kind of didn't feel right to me. But now after reading your explaination, I am okay. Thanks again :)
Post reply on HN