[SystemSafety] Overflow triggering AC power cut-off in Boeing787

[Tom Ferrell]

Having some insight into the development of this aircraft, I would contend the real issue here is not the counter rollover that warrants the attention of this list but rather the aircraft-level operating scenario at the heart of the issue.  I would not at all be surprised that the counter was known about but that no one considered a realistic scenario for the aircraft to remain powered with no interruption for more than eight months.  This is a Concept of Operations (ConOps) consideration that varies by aircraft operator, the routes flown, the types of ground power available and the overall utilization rate of the airplane.  Even if you apply all the tools/mitigations available to the engineer to protect against a rollover and the myriad of other ‘known’ software gotchas, there is still a limit to how far you can economically take the fault tolerant features before the product as a whole simply ceases to be economically viable.  While I agree that counter and clock rollover is something that always warrants some sort of graceful treatment in a safety-related system, understanding the operating environment remains central to ensuring that a safe system is fielded.

 

From: systemsafety-bounces at lists.techfak.uni-bielefeld.de [mailto:systemsafety-bounces at lists.techfak.uni-bielefeld.de] On Behalf Of jean-louis Boulanger
Sent: Sunday, May 03, 2015 2:07 PM
To: Derek M Jones
Cc: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] Overflow triggering AC power cut-off in Boeing787

 

The question raised by david is related to "do you have some additional informations on this issue" ?

 

before discussing of tools, we need to discuss of methodology, in this case, do you have a systematic activity to detect overflow ?

if yes when an overflow is identified, it's remove or can we accept it after justification ?

 

for tools, actually, we have very powerful formal tools that check many thing and we demonstrate (in many industrials used) that its work.

yes we can have false positive but manually manage X00 000 lines of code is not easy ....

yes we can have some lack (partial coverage of language, efficiency, ...) but a tools is an help 

 

actually, the different standards requested some tools qualification effort and evidence ....

 

...

 

2015-05-03 19:48 GMT+02:00 Derek M Jones <derek at knosof.co.uk>:

David,

This would not happen if absence of overflow was automatically checked
(by using tools like Frama-C, Astrée or Polyspace). Or more probably


Automatic checking is not in itself enough and without the source code
to try out the tools you cannot claim that any of them
would have detected the problem.

Deciding what kinds of thing a static analysis tool involves
lots of trade-offs, such as:

   o what can be implemented with the available resources,

   o what level of false positive is considered acceptable,

   o what kinds of mistakes are most likely to occur and hence
     the ones for which it is cost effective to check for,

   o for commercial tools, what the customer wants to know and what they
     are willing to pay,

   o for academic projects, what is likely get published when written
     up.

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667 <tel:%2B44%20%280%291252%20520667>   blog:shape-of-code.coding-guidelines.com


_______________________________________________
The System Safety Mailing List
systemsafety at TechFak.Uni-Bielefeld.DE





 

-- 

Mr Jean-louis Boulanger

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