[SystemSafety] Stupid Software Errors [was: Overflow......]

Steve Tockey Steve.Tockey at construx.com
Mon May 4 23:08:41 CEST 2015


There are three possible angles of attack:

*) Trust/certify the developers
*) Trust/certify the process
*) Trust/certify the product

While I personally would vote for a combination of all three—particularly in safety- and mission-critical projects—one thing DO-178C/ED-12C does have going for it is that it is a pretty good way (although definitely not perfect) of trusting/certifying the process. I trust DO-178C/ED-12C much more than the FDA's requirements on medical device software.




From: Andy Ashworth <andy at the-ashworths.org<mailto:andy at the-ashworths.org>>
Date: Monday, May 4, 2015 2:02 PM
To: Steve Tockey <Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com>>
Cc: Mike Ellims <michael.ellims at tesco.net<mailto:michael.ellims at tesco.net>>, "M.Pont at SafeTTy.net<mailto:M.Pont at SafeTTy.net>" <M.Pont at SafeTTy.net<mailto:M.Pont at SafeTTy.net>>, The System Safety List <systemsafety at techfak.uni-bielefeld.de<mailto:systemsafety at techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] Stupid Software Errors [was: Overflow......]

So safety critical software today is being developed by inexperienced personnel with little or no relevant training... I guess on the positive side, development costs are cheap :(

Sent from my iPhone

On May 4, 2015, at 16:59, Steve Tockey <Steve.Tockey at construx.com<mailto:Steve.Tockey at construx.com>> wrote:


With the average age of developers being about 29 years old, maybe most aren't old enough. And many have no formal software education so even a discussion of such failures in a degree program would have little effect on the target population.



From: Mike Ellims <michael.ellims at tesco.net<mailto:michael.ellims at tesco.net>>
Date: Monday, May 4, 2015 1:01 PM
To: 'Andy Ashworth' <andy at the-ashworths.org<mailto:andy at the-ashworths.org>>, "M.Pont at SafeTTy.net<mailto:M.Pont at SafeTTy.net>" <M.Pont at SafeTTy.net<mailto:M.Pont at SafeTTy.net>>
Cc: 'The System Safety List' <systemsafety at techfak.uni-bielefeld.de<mailto:systemsafety at techfak.uni-bielefeld.de>>
Subject: Re: [SystemSafety] Stupid Software Errors [was: Overflow......]

> With the established history of date/time roll-over issues, shouldn't any date be viewed with suspicion during design safety analysis appropriate defensive design measures put in place?

The question is why?
I know this issue is documented in at least one book.
Did any of the programmers/coder on this even know about previous examples?


From:systemsafety-bounces at lists.techfak.uni-bielefeld.de<mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de> [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of Andy Ashworth
Sent: 04 May 2015 13:55
To: M.Pont at SafeTTy.net<mailto:M.Pont at SafeTTy.net>
Cc: The System Safety List
Subject: Re: [SystemSafety] Stupid Software Errors [was: Overflow......]

Why wait until testing? With the established history of date/time roll-over issues, shouldn't any date be viewed with suspicion during design safety analysis appropriate defensive design measures put in place?

Andy

Sent from my iPhone

On May 4, 2015, at 08:49, Michael J. Pont <M.Pont at SafeTTy.net<mailto:M.Pont at SafeTTy.net>> wrote:
Matthew:

“On the other hand I don't think we should loose sight of the fact that the Boeing 'bug' was found by running a long duration simulation, not by an airliner falling out of the sky. So perhaps thanks is due to the Boeing safety or software engineer(s) who insisted on a long run endurance test and who might have actually learned something from history?”

OK – but maybe next time we can ask them to do this testing before the aircraft goes into service …

Michael.

Michael J. Pont
SafeTTy Systems Ltd.
_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE<mailto:systemsafety at TechFak.Uni-Bielefeld.DE>


________________________________
[Avast logo]<http://www.avast.com/>

This email has been checked for viruses by Avast antivirus software.
www.avast.com<http://www.avast.com/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20150504/c68ee976/attachment-0001.html>


More information about the systemsafety mailing list