[SystemSafety] Categorising "errors" [was: Stupid Software Errors]

[Drew Rae]

I know some people who would look at this whole discussion and say "For forty years we've had better ways of talking about safety problems in complex systems than simply categorising them as human error. I can't believe people are still making this same basic mistake. I blame this young generation who haven't had a proper education in safety engineering, and are just messing about in organisations without a proper understanding of the fundamentals. What are we teaching engineers these days?"

Does anyone else find it remarkable that a company is publicly releasing information about a potential problem with a system, even though their own understanding of how the system is used suggests that the conditions that would cause the problem are unlikely to exist? 

They've recognised that there is variability in the socio-technical system, and that information sharing is important. I can think of similar occasions in the past when this sort of hazard would be considered "covered" by instructions in the operating procedures that "prevented" the power units being on for that long, with no explanation of the rationale. I'm optimistic enough to see this as a sign of progress. 

Drew

* This message is from my work email
* I can also be contacted on andrew at ajrae.com
* My mobile number is 0450 161 361
* My desk phone is 07 37359764
* My safety podcast is DisasterCast.co.uk





On 05/05/2015, at 8:47 AM, Heath Raftery wrote:

> On 5/05/2015 1:41 AM, Daniel Kästner wrote:
>> some performance figures about an Astrée analysis for a Level A avionics
>> application:
>> - code size > 700.000 lines of C code
>> - analysis duration: 6 hours
>> - hardware: Intel Core2Duo 2.66 GHz, 8GB RAM.
>> - result: 0 alarms
>> I.e. the absence of run-time errors was proven, including arithmetic
>> overflows.
> 
> Is the implicit assumption that zero run-time errors is better, actually sound? Here's a "run time error":
> 
> <code>
> uint16_t buttonPressTime = 0, timeInMilliseconds = 0;
> 
> while(1)
> {
>  wait(1);
> 
>  timeInMilliseconds++;
> 
>  if(buttonPressed)
>    buttonPressTime = timeInMilliseconds;
> 
>  if(buttonPressTime && (timeInMilliseconds-buttonPressTime > 300))
>  {
>    printf("A button was pressed 0.3s ago.");
>    buttonPressTime = 0;
>  }
> }
> </code>
> 
> Eventually timeInMilliseconds will wrap - apparently a run time error. But this code will "work" forever, even after the wrap occurs.
> 
> Here's a "fix" for the run-time error:
> 
> <code>
> uint16_t buttonPressTime = 0, timeInMilliseconds = 0;
> 
> while(1)
> {
>  wait(1);
> 
>  if(timeInMilliseconds < SHRT_MAX)
>    timeInMilliseconds++;
> 
>  if(buttonPressed)
>    buttonPressTime = timeInMilliseconds;
> 
>  if(buttonPressTime && (timeInMilliseconds-buttonPressTime > 300))
>  {
>    printf("A button was pressed 0.3s ago.");
>    buttonPressTime = 0;
>  }
> }
> </code>
> 
> Tada! No run-time errors! Of course, it stops working after a minute.
> 
> Yes, the tools are great, and not using them would take extraordinary justification. But to cry that "integer overflow was fixed 30 years ago!" may be missing the point.
> 
> Heath
> 
> _______________________________________________
> The System Safety Mailing List
> systemsafety at TechFak.Uni-Bielefeld.DE

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