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

31–40 of 58 posts

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

#31

Post by Aloha »

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 change it, you'll need to pay us for more development", that normally eliminates the requirement for whatever it was they wanted pretty quickly.

Also, uptime is a factor, I've seen what windows looks like when it runs out of GDI objects, it's strange. But once you see it, you can explain to the customer the importance of regular reboot/restarts.

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

#32

Post by lamontcg »

drewrv wrote: post #3
rcyeh wrote: post #2

tl;dr: 51 days is the wraparound point of a signed 6-byte counter running at 33 MHz, used to invalidate stale data from instruments.

This assumes there is no margin of error baked into the 51 day rule, which surprises me.

This communication is not Boeing communicating a required maintenance interval, they're communicating a problem. It wouldn't seem natural for me for Boeing to add a random hidden margin in a problem description. When it comes to the maintenance remedy, I don't know if Boeing would do this or airlines or the FAA. Presumably the mandatory maintenance reboot interval will be much shorter than 51 days.

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

#33

Post by zokier »

nimish wrote: post #5
drewrv wrote: post #3

Earlier quoted context omitted.

This assumes there is no margin of error baked into the 51 day rule, which surprises me.

2^47/(32MHz) ~= 50.9 days Not much of a margin there.

2^47/33e6 = 49.36 days. The value is so much off that makes me suspect that this is not the correct analysis, or at least that there are additional factors at play

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

#35

Post by FPGAhacker »

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…

Sounds about right. But it’s still a critical failure for a fault of any kind to ever display incorrect information to the pilot.

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

#36

Post by inferiorhuman »

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 do not know if this particular 51-day limitation was intentional or no
I highly doubt it was intentional. Boeing's already had to issue an AD for similar behavior on the 787:

https://www.engadget.com/2015-05-01-boeing-787-dreamliner-so...

If they knew about it there'd be no need for an AD. Boeing tried to become the aviation equivalent of a fabless chip designer with the 787 and it didn't go well at all. Turns out they had little-to-no experience managing external development and manufacturing teams. I don't know anything about the 51-day bug, but the 248-day bug caused critical failures that you really wouldn't want happening in flight.

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

#37

Post by phkahler »

FPGAhacker wrote: post #35
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…

Sounds about right. But it’s still a critical failure for a fault of any kind to ever display incorrect information to the pilot.

And in this case it seems one function of the software is interfering with another, which causes the incorrect display.

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

#38

Post by Teongot »

userbinator wrote: post #7

For example, let’s imagine that the timestamp set by the transmitting ES is close to its wrap-around value. After performing the required calculation, the receiving ES obtains a timestamp that has already wrapped-around, so it would look like the message had been received before it was actually sent. Isn't it surprising that modulo arithmetic, as already employed successfully in TCP sequence numbers and the like, sti…

> Isn't it surprising that modulo arithmetic, as already employed successfully in TCP sequence numbers and the like, still seems to be incorrectly implemented today

Even in TCP sequence numbers, it can be implemented incorrectly.

https://engineering.skroutz.gr/blog/uncovering-a-24-year-old...

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

#39

Post by trenchgun »

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.

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

#40

Post by pixelfarmer »

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 through a lot of defined processes like in avionics, medical, or automotive field, among a good few others (safety and all that).
Post reply on HN