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

From: Tom Ferrell < >
Date: Sun, 3 May 2015 16:34:48 -0400

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.  

Sent: Sunday, May 03, 2015 2:07 PM
To: Derek M Jones
Cc: systemsafety_at_xxxxxx 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_xxxxxx


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>

The System Safety Mailing List


Mr Jean-louis Boulanger

The System Safety Mailing List
systemsafety_at_xxxxxx Received on Sun May 03 2015 - 22:35:03 CEST

This archive was generated by hypermail 2.3.0 : Tue Jun 04 2019 - 21:17:07 CEST