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

Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

flightglobal.com

Post reply on HN
Print view View original

241–250 of 311 posts

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#241

Post by CPLX »

akira2501 wrote: post #130
wyldfire wrote: post #43

Earlier quoted context omitted.

> he system can't recover from an error in an individual flight plan, bringing the whole system down with it From the system's POV maybe this is the right way to resolve the problem. Could masking the failure by obscuring this flight's waypoint problem have resulted in a potentially conflicting flight not being tracked among other flights? If so, maybe it's truly urgent enough to bring down the system and force the h…

> obscuring this flight's waypoint problem have resulted in a potentially conflicting flight not being tracked among other flights? Flights are tracked by radar and by transponder. The appropriate thing to do is just flag the flight with a discontinuity error but otherwise operate normally. This happens with other statuses like "radio failure" or "emergency aircraft." It's not something you'd see on a commercial flig…

This isn’t quite correct. The oceanic tracks do not have radar coverage and aren’t actively controlled.

There are other fail safe methods of course all the way up to TCAS, but it’s not great for an oceanic flight to be outside of the system.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#242

Post by InDubioProRubio »

jrochkind1 wrote: post #33

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to b…

Reminds me of the switches we used to put into production machines that could self destroy

if -- well defined case else

Scream

while true do

  Sleep(forever)
Same in

switch- default

Basically every known unknown its better to halt and let humans drive the fragile machine back into safe parameters- or expand the program.

PS: Yes, the else- you know what the else is, its the set of !(-well defined conditions) And its ever changing, if the well-defined if condition changes.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#243

Post by agos »

jrochkind1 wrote: post #33

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to b…

Erlang was born out of a similar problem with signal towers: if a terminal sends bogus data or otherwise crashes it should not bring everything down because the subsequent reconnection storm would be catastrophic. so, "let it fail" would be a very reasonable approach to this challenge, at least for fault handling

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#245

Post by [deleted] »

skissane wrote: post #131
throw0101a wrote: post #82

Earlier quoted context omitted.

> C dev: "You are telling me that the three digit codes are not globally unique??? They are understood not to be. They are generally known to be regionally unique. The "DVL" code is unique with-in FAA/Transport Canada control, and the "DVL" is unique with-in EASA space. There are pre-defined three-letter codes: * https://en.wikipedia.org/wiki/IATA_airport_code And pre-defined four-letter codes: * https://en.wikipedia…

> They are understood not to be. They are generally known to be regionally unique. Then why aren’t they namespaced? Attach to each code its issuing authority, so it is obvious to the code that DVL@FAA and DVL@EASA are two different things? Maybe for backward compatibility/ human factors reasons, the code needs to be displayed without the namespace to pilots and air traffic controllers, but it should be a field in the…

[deleted]

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#246

Post by akavel »

jrochkind1 wrote: post #33

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to b…

Take a look at the book: "Systemantics. How systems work and especially how they fail" - a classic, has more observations like this.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#247

Post by rounce »

skissane wrote: post #131
throw0101a wrote: post #82

Earlier quoted context omitted.

> C dev: "You are telling me that the three digit codes are not globally unique??? They are understood not to be. They are generally known to be regionally unique. The "DVL" code is unique with-in FAA/Transport Canada control, and the "DVL" is unique with-in EASA space. There are pre-defined three-letter codes: * https://en.wikipedia.org/wiki/IATA_airport_code And pre-defined four-letter codes: * https://en.wikipedia…

> They are understood not to be. They are generally known to be regionally unique. Then why aren’t they namespaced? Attach to each code its issuing authority, so it is obvious to the code that DVL@FAA and DVL@EASA are two different things? Maybe for backward compatibility/ human factors reasons, the code needs to be displayed without the namespace to pilots and air traffic controllers, but it should be a field in the…

Given airport codes are namespaced by ICAO, it seems a bit of an oversight that the same scheme hasn’t been extended to other infrastructure like VORs and waypoints for systems exactly like this one, for cases when uniqueness is required.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#248

Post by jvanderbot »

ronsor wrote: post #93
jrochkind1 wrote: post #33

I don't know how long that failure mode has been in place or if this is relevant, but it makes me think of analogous times I've encountered similar: When automated systems are first put in place, for something high risk, "just shut down if you see something that may be an error" is a totally reasonable plan. After all, literally yesterday they were all functioning without the automated system, if it doesn't seem to b…

> The general engineering challenge, is how we deal with little-used little-seen functionality (definitely thinking of fault-handling, but there may be other cases) that is totally reasonable when put in place, but has not aged well, and nobody has noticed or realized it, and even if they did it might be hard to convince anyone it's a priority to improve, and the longer you wait the more expensive. The solution to th…

That is "a" solution.

Another solution that is very foreign to us in sweng, but is common practice in, say, aviation, is to have that fallback plan in a big thick book, and to have a light that says "Oh it's time to use the fallback plan", rather than require users to diagnose the issue and remember the fallback.

This was one of the key ideas in the design of critical systems*: Instead of automating the execution of a big branching plan, it is often preferable to automate just the detection of the next desirable state, then let the users execute the transition. This is because, if there is time, it allows all users to be fully cognizant of the inner state of the system and the reasons for that state, in case they need to take over.

The worst of both worlds is to automate yourself into a corner, gunk everything up, and then require the user to come in and do a back-breaking cleanup just to get to the point where they can diagnose this. My factorio experiences mirror this last case perfectly.

* "Joint Cognitive Systems" - Hollnagle&Woods

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#249

Post by krick »

andyjohnson0 wrote: post #67
jp57 wrote: post #9

FYI: nm = nautical miles, not nanometers.

Even though I knew this was about aviation, I still read nm as nanometres. Now I'm wondering what this says about how my brain works.

I wouldn't have guessed until I read the comments. My assumption was somebody just mistyped km and somehow nobody cared to fix it.

Re: Air traffic failure caused by two locations 3600nm apart sharing 3-letter code

#250

Post by d1sxeyes »

lmm wrote: post #220
d1sxeyes wrote: post #210

Earlier quoted context omitted.

Yeah, I was not really trying to argue that that was actually the case, so won’t waste time trying to defend the merits of the model I pulled out of my arse. Alternatively then, perhaps safety developments in cars made them safer to drive around the same time? Or maybe advances in medicine made fatal crashes less likely? Or perhaps there’s some other explanation that doesn’t immediately spring to mind, it’s irrelevan…

> The only point I’m really making is that the data OP referred to does not show an increase in excess deaths, and in fact specifically fails to find this. That data absolutely does show an increase in deaths, it's right there in the table. It fails to find a statistically significant increase in deaths. The most plausible explanation for that is that the study is underpowered because of the sample size, not that som…

> That data absolutely does show an increase in deaths

Please be careful about removing the word 'excess' here. The word 'excess' is important, as it implies statistical significance (and is commonly understood to mean that - https://en.wikipedia.org/wiki/Excess_mortality).

I didn't argue that there was no change in the number of deaths, and I did not say that the table does not show any change in the number of deaths.

If your contention is that the sample size is too small, we can actually look at the full population data: https://en.wikipedia.org/wiki/Motor_vehicle_fatality_rate_in...

Notably, although 2002 had a higher number of fatalities, the number of miles traveled by road also increases. However, it represents a continuation of a growing trend since 1980 which continued until 2007, rather than being an exceptional increase in distance travelled.

Also, while 2002 was the worst year since 1990 for total fatalities, 2005 was worse.

Fatalities per 100 000 population in 2002 was 14.93, which was around a 1% worsening from the previous year. But 2002 does not really stand out, similar worsenings happened in 1988, 1993, 1994, 1995, 2005, 2012, 2015, and 2016 (to varying degrees).

One other observation is that in 2000, there was a population increase of 10 million (from 272 million to 282 million), while other years on either side are pretty consistently around 3 million. I'm not sure why this is the case, but if there's a change in the denominator in the previous year, this is also interesting if we're making a comparison (e.g. maybe the birth rate was much higher due to parents wanting 'millenial babies', none of whom are driving and so less likely to be killed in a crash, again, just a random thought, not a real argument from my side that I would try to defend).

The reason 'statistical significance' is important is because it allows us to look at it and say 'is there a specific reason for this, or is this within the bounds of what we would expect to see given normal variation?'. The data don't support a conclusion that there's anything special about 2001/2 that caused the variation.

Post reply on HN