4 ms·

> Pilots found that jets’ systems would shut down midflight about once every three or four hours and have to be rebooted. > But the new, improved version of 3i

> Pilots found that jets’ systems would shut down midflight about once every three or four hours and have to be rebooted. > But the new, improved version of 3i is a significant improvement, according to the JPO. The new version showed approximately twice the level of stability as the previous load, Block 2B, and three times better stability than the original 3i software Does that mean it "only" needs to reboot once every 6-8 hours? If that's considered stable enough to sign off for production, does that mean they will simply reboot before each flight and just hope for the best?

flyinglizard 10y ago
That's continuous delivery for you.
protomyth 10y ago
> Does that mean it "only" needs to reboot once every 6-8 hours? If that's considered stable enough to sign off for production, does that mean they will simply reboot before each flight and just hope for the best? Ferry flights must be an experience.
- engi_nerd 10y ago
  F-35s have ferried across the Atlantic without difficulty, and across the continental US on numerous occasions.
hackuser 10y ago
According to earlier articles about this issue, planes currently in wide use need to be 'rebooted' at a similar frequency, it's just specific subsystems that get rebooted (I think the F-35's former problem was a sensor), the planes keep flying, and missions don't often last that long anyway (IIRC all the details). Here, I found the link: https://news.ycombinator.com/item?id=11260927 https://news.ycombinator.com/item?id=11260927 EDIT: Heck, I'll just copy the meat of it here: http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for-less-than-80m-engines-included/ http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for... The toughest problem the program is having is matching the timing of the aircraft’s fusion software with its sensors’ software. “As we add different radar modes and as we add different and capabilities to the DAS system and to the EOTS system, the timing is misaligned,” and then you have to reboot it. Bogdan said he’s aiming for eight to nine hours between such software failures when a radar or DAS or EOTS needs to be rebooted, which is what legacy aircraft boast. Right now they are at four to five hours between such events. “That’s not a good metric.”
- Gravityloss 10y ago
  I guess if you demand a lot of interaction between almost all systems, it's harder to ensure high levels of independence.
  - arca_vorago 10y ago
    Welcome to the perils of globalism...
    - mlvljr 10y ago
      Coming to those less-developed on the wings of F-35s! :)
  - ArkyBeagle 10y ago
    It's not hard at all - you buffer it and make the communications paths asynchronous. You allow dropped "packets" when necessary. I don't think you can enforce hard realtime constraints across subsystems and expect anything but tears.
    - Retric 10y ago
      Buffering is not such a great idea when your getting shot at.
      - ArkyBeagle 10y ago
        I'm not talking about buffering that breaks a time line. I'm talking about buffering to deal with something that can be modelled as essentially clock uncertainty.
- ArkyBeagle 10y ago
  Holy friggin crap. Can I buy a hardware timer, pls? I have to be reading this wrong - they can't even enforce the time budget for different tasks/threads under varied configurations? Don't nobody here know how to play this game?
AJRF 10y ago
Would a jet be flying missions for 6-8 hours anyway?
- engi_nerd 10y ago
  Yes, with aerial refueling, missions of 12 hours or more are not unheard of. The pilot's endurance is the limiting factor. Or, as I've heard it said, "You worry about running out of ass, not running out of gas."
billforsternz 10y ago
My intuition is that occasional software crashes like this probably follow a Poisson distribution statistically speaking. Like occasional cars appearing on a lonely street. One car appearing doesn't affect the expected arrival of the next car. So rebooting before the start of a mission is not an effective strategy. Just idle speculation based on a stats and probability class 36 years ago. Happy to be proven wrong.
- albinofrenchy 10y ago
  I somewhat doubt that model is valid for these issues. A large number of software issues relate to run time of a system. In particular, this one seems to be clock drift from other comments. That's more of a random walk; which crashes a system at some given distance.
- woodman 10y ago
  Unless the crashes are caused by things cosmic rays, they're very likely influenced by the internal state of the aircraft and therefor not independent events. If that car showing up causes the world to reset - then you won't likely see another car for a few million years.
- ArkyBeagle 10y ago
  If I read the thing right, the system is in sync at reboot and effectively, jitter renders it unstable over time. So events are not independent.
- engi_nerd 10y ago
  When you start a mission you are literally starting up the plane. Along the way you turn on the avionics, authenticate, turn on the engine, ask the plane to perform a comprehensive set of built in tests, etc. You are booting up. It does not make sense to reboot before you've even booted up in the first place.
- Matthias247 10y ago
  In general I would agree. But there could be indeed some SW failures that are more likely after a given time of running. E.g. memory [de]allocation problems, memory fragmentation - in case the use some kind of dynamic memory. Or other types of resource leaks.

flyinglizard 10y ago

That's continuous delivery for you.

protomyth 10y ago

> Does that mean it "only" needs to reboot once every 6-8 hours? If that's considered stable enough to sign off for production, does that mean they will simply reboot before each flight and just hope for the best? Ferry flights must be an experience.

engi_nerd 10y ago
F-35s have ferried across the Atlantic without difficulty, and across the continental US on numerous occasions.

hackuser 10y ago

According to earlier articles about this issue, planes currently in wide use need to be 'rebooted' at a similar frequency, it's just specific subsystems that get rebooted (I think the F-35's former problem was a sensor), the planes keep flying, and missions don't often last that long anyway (IIRC all the details). Here, I found the link: https://news.ycombinator.com/item?id=11260927 https://news.ycombinator.com/item?id=11260927 EDIT: Heck, I'll just copy the meat of it here: http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for-less-than-80m-engines-included/ http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for... The toughest problem the program is having is matching the timing of the aircraft’s fusion software with its sensors’ software. “As we add different radar modes and as we add different and capabilities to the DAS system and to the EOTS system, the timing is misaligned,” and then you have to reboot it. Bogdan said he’s aiming for eight to nine hours between such software failures when a radar or DAS or EOTS needs to be rebooted, which is what legacy aircraft boast. Right now they are at four to five hours between such events. “That’s not a good metric.”

Gravityloss 10y ago
I guess if you demand a lot of interaction between almost all systems, it's harder to ensure high levels of independence.
- arca_vorago 10y ago
  Welcome to the perils of globalism...
  - mlvljr 10y ago
    Coming to those less-developed on the wings of F-35s! :)
- ArkyBeagle 10y ago
  It's not hard at all - you buffer it and make the communications paths asynchronous. You allow dropped "packets" when necessary. I don't think you can enforce hard realtime constraints across subsystems and expect anything but tears.
  - Retric 10y ago
    Buffering is not such a great idea when your getting shot at.
    - ArkyBeagle 10y ago
      I'm not talking about buffering that breaks a time line. I'm talking about buffering to deal with something that can be modelled as essentially clock uncertainty.
ArkyBeagle 10y ago
Holy friggin crap. Can I buy a hardware timer, pls? I have to be reading this wrong - they can't even enforce the time budget for different tasks/threads under varied configurations? Don't nobody here know how to play this game?

AJRF 10y ago

Would a jet be flying missions for 6-8 hours anyway?

engi_nerd 10y ago
Yes, with aerial refueling, missions of 12 hours or more are not unheard of. The pilot's endurance is the limiting factor. Or, as I've heard it said, "You worry about running out of ass, not running out of gas."

billforsternz 10y ago

My intuition is that occasional software crashes like this probably follow a Poisson distribution statistically speaking. Like occasional cars appearing on a lonely street. One car appearing doesn't affect the expected arrival of the next car. So rebooting before the start of a mission is not an effective strategy. Just idle speculation based on a stats and probability class 36 years ago. Happy to be proven wrong.

albinofrenchy 10y ago
I somewhat doubt that model is valid for these issues. A large number of software issues relate to run time of a system. In particular, this one seems to be clock drift from other comments. That's more of a random walk; which crashes a system at some given distance.
woodman 10y ago
Unless the crashes are caused by things cosmic rays, they're very likely influenced by the internal state of the aircraft and therefor not independent events. If that car showing up causes the world to reset - then you won't likely see another car for a few million years.
ArkyBeagle 10y ago
If I read the thing right, the system is in sync at reboot and effectively, jitter renders it unstable over time. So events are not independent.
engi_nerd 10y ago
When you start a mission you are literally starting up the plane. Along the way you turn on the avionics, authenticate, turn on the engine, ask the plane to perform a comprehensive set of built in tests, etc. You are booting up. It does not make sense to reboot before you've even booted up in the first place.
Matthias247 10y ago
In general I would agree. But there could be indeed some SW failures that are more likely after a given time of running. E.g. memory [de]allocation problems, memory fragmentation - in case the use some kind of dynamic memory. Or other types of resource leaks.