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

51–58 of 58 posts

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

#51

Post by p_l »

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?

Essentially changes in typical operation procedures at airlines broke previous assumptions about regular full aircraft power downs, which triggered both the 248 day bug and the current 51 day bug.

It used to be that an aircraft would get a full power down as often as daily, but as individual components got more reliable and external power easily available, it became common for aircraft to not be shut down fully between flight days.

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

#52

Post by mschuster91 »

dotancohen wrote: post #45
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.

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?

> 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?

Blast the module in a radiation chamber. It can be done, it's only extremely expensive - the military has the budget (makes sense, given that a fighter jet or a bomber should be able to power through a nuclear bomb fallout), but civilian airliners are all about cost efficiency.

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

#53

Post by mnw21cam »

dcormier wrote: post #11
Aperocky wrote: post #8

Earlier quoted context omitted.

51 days seems to be approximately how often my mac dies in kernel panic or starting to be bugged by persistent software problems that go away with a restart.

I’m at 356 days of uptime on my MacBook Pro. ¯\_(ツ)_/¯

I just rebooted my EeePC. It had an uptime of 5.8 years. I only rebooted it to upgrade from Debian 9 to Debian 10, and I'll bump it up to Debian 11 later on. It has a broken screen, so it just sits on top of a cupboard with a couple of 4TB USB hard drives plugged into it, storing all my backups.

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

#54

Post by xattt »

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…

> Nobody is going to write a requirement that says "this avionics subsystem will function without error forever".

These time limits could at least be pegged to real-life intervals to when the system is going to be shut down anyway. If the system continues to be operated past that point, skipped maintenance intervals could be underlined as the cause.

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

#55

Post by xattt »

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.

I worked in healthcare where our EMR went into downtime for two hours on daylight transition days. It was extremely disruptive as we had to switch to a paper process for that time period that needed to get reconciled with the EMR at the end of the shift.

Unless you have a dedicated team doing that, preventative reboots and various “workarounds” sound great on paper for administrators but make for a shitty experience for people doing the actual work.

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

#56

Post by caconym_ »

TillE wrote: post #17
steffan wrote: post #10

Earlier quoted context omitted.

To address the second part: > and yet the plane appears to have no mechanical backup instruments[?] This is unlikely in a modern aircraft because mechanical instruments to back up e.g., the artificial horizon / attitude indicator or directional gyro (DG) / heading indicator are: 1) Mechanically complex - the attitude indicator and DG make use of gyroscopes which rotate at up to 24,000 RPM along with other mechanisms.…

Plus the pilot stress of having to adjust to using dramatically different instruments when already in a difficult situation. It's just not a workable idea in general. There are checklists for stuff like instrument failure which can probably recover from a software bug like this.

It's absolutely a workable idea. Standby instruments are typically a requirement for glass cockpit aircraft, and before electronic standby instruments came onto the scene mechanical instruments were used in the standby role in (AFAIK) all sectors of aviation.

"Fly the airplane" is the highest priority in any aviation emergency, and in many emergencies you will need backup instruments to do so. I don't mean to be mean, but tbh it is a little absurd to suggest that a e.g. a pilot who loses her PFD in IMC is better off running checklists than using backup instruments to establish control of the aircraft and situational awareness, and bailing out asap. Sure, it's stressful, but it's also something pilots need to (and do) train for.

Once the aircraft is under control, you can run your checklists, or if you have a co-pilot you may be able to work in parallel. Maybe you will be able to fix the issue, and maybe you won't, but backups give you a shot at landing safely either way.

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

#57

Post by hef19898 »

xattt wrote: post #55
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.

I worked in healthcare where our EMR went into downtime for two hours on daylight transition days. It was extremely disruptive as we had to switch to a paper process for that time period that needed to get reconciled with the EMR at the end of the shift. Unless you have a dedicated team doing that, preventative reboots and various “workarounds” sound great on paper for administrators but make for a shitty experience…

Difference berween your examole and the reboot requirements of various aircraft: aircraft reboots hapoen in controlled environments, on the ground when the aircraft is out of operations and is done be dedicated, trained and certified maintenance staff. Those reboots, while funny on first glance, do not interfere at all with aircraft operations.

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

#58

Post by fargle »

zokier wrote: post #33
nimish wrote: post #5

Earlier quoted context omitted.

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

exactly. you could find a plausible clock rate that rolls over in ~51 days with any number of assumed counter widths. this is not indicative of anything but guessing.

and there is no margin at all or negative margin, so clearly this is wrong. is the rollover period 52 days? 60? 90?

the whole article is a bunch of unsubstantiated speculation dressed up with lots of facts and details to distract ones attention.

Post reply on HN