Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

ioactive.com

Post reply on HN
Print view View original

41–50 of 58 posts

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#41

Post by hef19898 »

trenchgun wrote: post #39
tjr wrote: post #29

One thing to consider when looking at such things is that commercial avionics software systems are full of known limitations. I do not know if this particular 51-day limitation was intentional or not, but in general: Avionics software starts with writing comprehensive requirements. When the software itself is developed based on those requirements, it is then tested against the requirements, always in a real functioni…

It is on fact possible to write provably correct software for safety critical applications. Not by testing, but by using formal methods.

Including a system reboot, on the ground, as part of your on going maintenance activities is a fault, or incorrect software.

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#42

Post by hef19898 »

Aloha wrote: post #31
tjr wrote: post #29

One thing to consider when looking at such things is that commercial avionics software systems are full of known limitations. I do not know if this particular 51-day limitation was intentional or not, but in general: Avionics software starts with writing comprehensive requirements. When the software itself is developed based on those requirements, it is then tested against the requirements, always in a real functioni…

I work in a field that operates under similar development constraints. (Namely it's a mature product in a mature field with well defined requirements) Because if this I regularly get calls from my customers wondering why their system can't do X or Y in the B way instead of the A way, and I have a similar conversation. Wherein I have to explain "no, that wasn't part of your requirements 5 years ago, if you want to cha…

I never understood why regular, and scheduled, reboots are concidered to be a problem to begin with.

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#43

Post by Yizahi »

pixelfarmer wrote: post #40

I remember articles of the Airbus A350 requiring reboots every N days (150ish or so?). I remember the Patriot missile system required a reboot every 24 hours or so until they fixed the software defect which caused the time counting to drift. And I'm pretty sure there are many more such cases where devices fail if kept on for too long, even in spaces where you are supposed to fill out a lot of "paper"work + jump throu…

We had a bug years ago that after 50 days of uptime all network sessions dropped on our devices. Apparently it was a session timer overflow in a variable. I think it was unsigned int and time was in milliseconds.

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#44

Post by prennert »

hef19898 wrote: post #41
trenchgun wrote: post #39

Earlier quoted context omitted.

It is on fact possible to write provably correct software for safety critical applications. Not by testing, but by using formal methods.

Including a system reboot, on the ground, as part of your on going maintenance activities is a fault, or incorrect software.

Is a roof you have to redo every 20 years, or a paint that only lasts 10 years faulty? Is a car that needs brakes replaced every X thousand kilometers faulty?

It is only faulty if it does not run according to spec, or if you it run outside the spec.

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#45

Post by dotancohen »

trenchgun wrote: post #39
tjr wrote: post #29

One thing to consider when looking at such things is that commercial avionics software systems are full of known limitations. I do not know if this particular 51-day limitation was intentional or not, but in general: Avionics software starts with writing comprehensive requirements. When the software itself is developed based on those requirements, it is then tested against the requirements, always in a real functioni…

It is on fact possible to write provably correct software for safety critical applications. Not by testing, but by using formal methods.

That's nice for the software. Now how about the hardware? How about the electronic hardware's not-exposed firmware, does that count? Did the subcontractor test it for three years at 10,000 feet for radiation-induced bit-flips? With or without lightning strikes?

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#46

Post by ggm »

hef19898 wrote: post #42
Aloha wrote: post #31

Earlier quoted context omitted.

I work in a field that operates under similar development constraints. (Namely it's a mature product in a mature field with well defined requirements) Because if this I regularly get calls from my customers wondering why their system can't do X or Y in the B way instead of the A way, and I have a similar conversation. Wherein I have to explain "no, that wasn't part of your requirements 5 years ago, if you want to cha…

I never understood why regular, and scheduled, reboots are concidered to be a problem to begin with.

It can come with exposure of hidden costs. So a pc which can only be assured to be correct by reboot cannot continuously monitor a flow process which cannot be interrupted for that reboot window. It has to be designed to work with two, or some kind of data buffering has to be designed in, or the specification changed to redefine to continuous(*)

Which btw is what should be done but.. it can cause rage

[*] may not be continuous or complete in all circumstances

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#47

Post by mormegil »

pixelfarmer wrote: post #40

I remember articles of the Airbus A350 requiring reboots every N days (150ish or so?). I remember the Patriot missile system required a reboot every 24 hours or so until they fixed the software defect which caused the time counting to drift. And I'm pretty sure there are many more such cases where devices fail if kept on for too long, even in spaces where you are supposed to fill out a lot of "paper"work + jump throu…

149 hours, see https://en.wikipedia.org/wiki/List_of_software_bugs#Transpor...

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#48

Post by hef19898 »

prennert wrote: post #44
hef19898 wrote: post #41

Earlier quoted context omitted.

Including a system reboot, on the ground, as part of your on going maintenance activities is a fault, or incorrect software.

Is a roof you have to redo every 20 years, or a paint that only lasts 10 years faulty? Is a car that needs brakes replaced every X thousand kilometers faulty? It is only faulty if it does not run according to spec, or if you it run outside the spec.

Exactly. If the manual says "reboot every 51 hours", you do just that and all is fine. If you have to reboot every, say, 25 hours, something is broken.

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#49

Post by hef19898 »

ggm wrote: post #46
hef19898 wrote: post #42

Earlier quoted context omitted.

I never understood why regular, and scheduled, reboots are concidered to be a problem to begin with.

It can come with exposure of hidden costs. So a pc which can only be assured to be correct by reboot cannot continuously monitor a flow process which cannot be interrupted for that reboot window. It has to be designed to work with two, or some kind of data buffering has to be designed in, or the specification changed to redefine to continuous(*) Which btw is what should be done but.. it can cause rage [*] may not be…

But a 787 works fine with those reboots being part of scheduled maintenance. So the issue is what exactly again?

Re: Reverse Engineer’s Perspective on the Boeing 787 ‘51 days’ Directive

#50

Post by ggm »

hef19898 wrote: post #49
ggm wrote: post #46

Earlier quoted context omitted.

It can come with exposure of hidden costs. So a pc which can only be assured to be correct by reboot cannot continuously monitor a flow process which cannot be interrupted for that reboot window. It has to be designed to work with two, or some kind of data buffering has to be designed in, or the specification changed to redefine to continuous(*) Which btw is what should be done but.. it can cause rage [*] may not be…

But a 787 works fine with those reboots being part of scheduled maintenance. So the issue is what exactly again?

Nothing. I respond to a question posing why it might be a problem. It didn't say "in a 787" it was "in general" I suggest a class of problem which it might surface in. The wider question.

All aircraft have schedules of maintenance. Requirements to reboot a computer periodically isn't onerous. It's not onerous but the insane costs of recertification are. Fixing this problem to not require reboot would be very expensive. Not just the FAA process burdens but the wider costs. 787 battery problems probably wrecked the entire profit of the model for years.

The Max flight safety issue on another Boeing aircraft may mean its never profitable. The industry is wierd.

Post reply on HN