I don't know if I'm interpreting that correctly but what I'm getting out of it is clock skew between sensors and the fusion system, which I assume to be referring to sensor fusion.
That makes sense, analogous to a typical distributed systems issue. I would imagine the skew needed for the type of sensing they do is quite small. I doubt they can just toss an atomic clock on the plane :)
They totally could. Some atomic clocks are quite small. The one pictured on the below wiki page doesn't look that much bigger than a 3.5" hard drive.
Are they mil spec? In other words do they operate correctly over a very large temperature range, with large input voltage variance, under high G-forces, in high vibration environments, etc?
I don't know anything about atomic clocks past what I can read on wikipedia but, I can say there is generally a large difference between mil spec ICs and commercial or industrial grade ICs, I would assume this would extend to atomic clock scale devices as well, but just a guess.
I don't think a single atomic clock would do it -- sounds like they'd need a high accuracy clock for each separate subsystem.
But unlike distributed systems, it seems like an aircraft is small enough to have one clock that everyone uses - any idea why they don't do that? Single (or too much of a) point of failure? Disparate vendors can't agree on a standard? Too much extra wiring or other complexity?
Problem is you need a reference time clock. On monolithic arch, is easy : the backbone bus timestamp the paquets it sees. On networked arch you need a time server a la NTP, otherwise you have time skew and loopbacks.
Even with a accurate time clock, you may also need to correct for timing issues due to cable length.
And to clarify, we're talking about PHY level protocol clocks here, not time clocks.
As I understand it, an early variant of the TCAS system for collision avoidance did just that. Every aircraft would have a Cs or Rb standard that was synchronized to a master clock, and they'd broadcast their position and altitude at an assigned time slot.
This would have been very expensive at the time (late 60s-early 70s?) they were proposing it, and it would only have worked if everyone had the necessary equipment. So it didn't fly. But in later decades it was no big deal to put a high-quality atomic time/frequency standard onboard an aircraft, and I wouldn't be surprised if most large airplanes actually do carry a Rb standard for one reason or another.
Edit: the proposed system was called EROS: http://www.allstar.fiu.edu/aero/tcas.htm
Where one of the tricky parts comes in, is in distributing this clock signal to all portions of the avionics system that need it. But that's beside the point.
It doesn't really sound like a timing skew problem (as in, a problem with making all systems recognize the same time simultaneously) but rather with making sure that all relevant information needed to construct a coherent 'picture' from all sensors reaches the core processors in a timely manner.
You can't provide a real time display if, say, your radar data is delayed for a significant period of time due to problems or instabilities with the radar's onboard processor.
These are warplanes - you don't want critical systems reliant on satellites that could be jammed, or downed, during wartime, which I suspect is why they don't do this already.
But...
>>> Just make the plane use GPS.
...implies you would make them absolutely depend on it. Military aircraft use GPS daily, because it's cheaper and better. However, they also have accurate inertial navigation systems as a backup, so they can still operate effectively if the enemy makes GPS unavailable.
According to references, 13.5 hours [0] is the record for the F-16 combat mission, and this was actually a SEAD (Suppression of Enemy Air Defenses) mission in a single-seat F-16CJ. Similar missions in the EA-18G extended to 13+ hours with a single pilot, along with a WSO/EWO in the back seat.
Various unofficial reports indicate F-16s do fly 14 hour ferry flights, but that is highly unusual.
At the Evergreen Air & Space museum (home of the Spruce Goose), they have an old SR-71 on display. Part of the exhibit has a TV playing a video loop with pilots and crew talking about their experiences. One of the pilots recalls how they'd have a "high-protein, low-residue" breakfast like steak & eggs before a long mission. The idea was to provide long lasting energy without having to go "number two" in the suit. He says that some of the crew who would help them out of the flight suit at the end of a mission were female, so it'd be especially embarrassing if you'd pooped yourself. I got the impression that, while rare, it did happen sometimes. :-\
(2 + 2 + 2 + 2 + 12) / 5 = 4.
And so on. This whole statement is meaningless without more information about the distribution of lengths of flights.
[0] http://abcnews.go.com/US/jet-skier-broke-jfk-airports-securi...
A 4-hour MTBF window (even for a subsystem) is terrifying considering modern vehicles like this are likely all fly-by-wire.
This article should clarify what the radar reset that they are referring to is. Integer, origin, and timing resets are a function of radar tech, and are not specifically related to something like a system reboot. This would be something like restarting a process due to bad data getting into your process from a sensor and potentially leading to a bad result from a range or trajectory.
I don't know much about Navy / Air Force ops, but it's possible that a sortie may consist of taking off and returning to rearm / refuel without shutting down, which could easily span more than four hours. In addition, lots of fighter planes do refuel in mid-air, so the requirement is still very prevalent for the subsystem to remain functional.
With the F-35 and other jets, its possible to swap crew and perform minor maintenance with the jet electrically powered up and cooled with auxiliary air supply, although the engine is shutdown and then restarted. This actually saves significant time on the pre-takeoff procedures. I would think the Lockheed Martin engineers could also perform diagnostics after a failure, without interrupting power or restarting the sub-system.
Edit: It is mentioned elsewhere in this thread that it is a timing issue, see: http://breakingdefense.com/2016/02/bogdan-predicts-f-35s-for...
Yes, I can understand the problem is complicated, but come on.
It was the first number that shocked me the most.
EDIT: I found it:
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.”
I don't understand a lot of that, but I think the fusion softwre refers to a unified UI for the pilot that merges information from the plane's very many sensors and presents it in a comprehensible way on one screen. Apparently pilots in older planes suffer from data overload and from watching many different screens at once - all while trying to fly a plane in combat. UI is reported to be a highly consequential improvement for the new plane.