4 ms·

Something unclear from the article, but jumped out at me. It seems that the Achilles heel of the IBNS system was that too much information tended to bork it, b

Something unclear from the article, but jumped out at me. It seems that the Achilles heel of the IBNS system was that too much information tended to bork it, but what’s unclear to me (as implied by the article) is if dropping incoming data was actually the sensible thing to do (as is often the case) and if incoming data was prioritized over existing data and that was dropped instead. The other thing I would point out is that the technical failure is not that a system is complex, but that a complex system has a user interface that allows a sequence of actions to leave it in an invalid or unpredictable state. The transfer of throttle control being incomplete while other actions were taken, for example. I think the thing lacking here was consistent and sound changes to the state, lack of fuzzing user input to observe this possibility, and the reliance on training to avoid the issues at all. These are problems that can be solved with design.

iudqnolq 7y ago
I haven't worked on any project anywhere approaching significant complexity, but the magic number of 150 supported tracked ships sounds insanely low to me. Is this at all reasonable, or does it indicate the design and implementation were shit? Does anyone know how much processing is needed here? Is it just updating an internal model of locations and warning about impending collisions? Presuming constant speed and heading that sounds easy, not presuming it sounds not feasible even for just a handful of ships. Also, if only 150 ships are supported, wouldn't it makes sense for the computer to automatically untrack them? Maybe allow manual prioritization of what to drop first, but surely within a few days of a competent vendor learning adding too many items borked their system they would put out a patch that does the absolute minimum by automatically preventing adding too many items? > In 2014, Navy officials discovered a flaw in the IBNS. One component could not keep track of more than 150 ships at a time without malfunctioning, according to Navy investigators. The Navy’s solution? Sailors were told to delete tracked ships before the total hit the magic number. > The navigation system could also become overloaded if too much information streamed in from a ship tracking database used worldwide to prevent maritime collisions. The Navy’s second solution was similar to the first: Drop the feed when it became too much. > They were patches on top of patches that left the Navy’s destroyers without a full picture of the seas around them. But none of the problems was serious enough to attract high-level attention. A Navy system designed to track problems in major ship systems did not contain any reports that mentioned the IBNS until last year, according to a Navy official.
- unlinked_dll 7y ago
  This is what I mean, I have no idea if it’s reasonable or not. Or why the issue exists (bandwidth, memory, etc etc). Or if the “dropped” data is actually dropped at all past 150 ships, and not dropped when it is lowered in priority compared to incoming data. The number of 150 seems odd as well, but I have no idea what that 150 limit corresponds to in terms of actual data, methods to poll it, update it, connections to leave open, packets to receive, etc. It could be totally reasonable. It could also be insanely small. My point is, it’s difficult to pass judgement on tech specs out of context.
  - jws 7y ago
    No inside knowledge here, but in tracking moving objects it would be easy to build in an O(n^2) algorithm when predicting interactions or intersections between ships. Combine this with the sort of logic used in real time displays (or video games) and as the number of ships increases, the processing time required for the analysis goes up rapidly until you miss a critical time deadline and get your analysis ignored. At which point the system is classified as broken.
- tomatotomato37 7y ago
  Maybe it was due to a weird hardware dependency like the correlation of each ship to a dot on a 10x15 light matrix or something
  - iudqnolq 7y ago
    One would hope that would then have been understood at the planning stage and not discovered unexpectedly once the system was running.
- touisteur 7y ago
  150 tracks without knowing the range of their navigation radar systems doesn't say much. It's hard to put more than 150 objects in a 5-10NM radius. Since it's a navy ship the nav radar is probably more powerful, but still, it's not like a 200NM range air-defence radar. I'm guessing they spec-d the system with incoherent requirements, and either the contractor that won went for the cheapest working hardware without asking too many questions, or maybe they took an old system's spec and asked for an incomplete upgrade... or nobody wanted to go to their boss saying the system didn't work because of some badly written spec or badly managed contractor and we need more money, please ? That would track with leaving the system badly working like this without even having some face-saving 'we're trying to work it out with the contractor right now'. Or, most likely, normalisation of deviance. The system came at first with so many bugs and problems that when they got it in some stable state, they'd got so used to work around the bugs that they kept on doing that. Look we already put so much effort in this, what's a bit more? Yeah, we're quite happy with the system, at least it doesn't crash every hour like when it was delivered...

iudqnolq 7y ago

I haven't worked on any project anywhere approaching significant complexity, but the magic number of 150 supported tracked ships sounds insanely low to me. Is this at all reasonable, or does it indicate the design and implementation were shit? Does anyone know how much processing is needed here? Is it just updating an internal model of locations and warning about impending collisions? Presuming constant speed and heading that sounds easy, not presuming it sounds not feasible even for just a handful of ships. Also, if only 150 ships are supported, wouldn't it makes sense for the computer to automatically untrack them? Maybe allow manual prioritization of what to drop first, but surely within a few days of a competent vendor learning adding too many items borked their system they would put out a patch that does the absolute minimum by automatically preventing adding too many items? > In 2014, Navy officials discovered a flaw in the IBNS. One component could not keep track of more than 150 ships at a time without malfunctioning, according to Navy investigators. The Navy’s solution? Sailors were told to delete tracked ships before the total hit the magic number. > The navigation system could also become overloaded if too much information streamed in from a ship tracking database used worldwide to prevent maritime collisions. The Navy’s second solution was similar to the first: Drop the feed when it became too much. > They were patches on top of patches that left the Navy’s destroyers without a full picture of the seas around them. But none of the problems was serious enough to attract high-level attention. A Navy system designed to track problems in major ship systems did not contain any reports that mentioned the IBNS until last year, according to a Navy official.

unlinked_dll 7y ago
This is what I mean, I have no idea if it’s reasonable or not. Or why the issue exists (bandwidth, memory, etc etc). Or if the “dropped” data is actually dropped at all past 150 ships, and not dropped when it is lowered in priority compared to incoming data. The number of 150 seems odd as well, but I have no idea what that 150 limit corresponds to in terms of actual data, methods to poll it, update it, connections to leave open, packets to receive, etc. It could be totally reasonable. It could also be insanely small. My point is, it’s difficult to pass judgement on tech specs out of context.
- jws 7y ago
  No inside knowledge here, but in tracking moving objects it would be easy to build in an O(n^2) algorithm when predicting interactions or intersections between ships. Combine this with the sort of logic used in real time displays (or video games) and as the number of ships increases, the processing time required for the analysis goes up rapidly until you miss a critical time deadline and get your analysis ignored. At which point the system is classified as broken.
tomatotomato37 7y ago
Maybe it was due to a weird hardware dependency like the correlation of each ship to a dot on a 10x15 light matrix or something
- iudqnolq 7y ago
  One would hope that would then have been understood at the planning stage and not discovered unexpectedly once the system was running.
touisteur 7y ago
150 tracks without knowing the range of their navigation radar systems doesn't say much. It's hard to put more than 150 objects in a 5-10NM radius. Since it's a navy ship the nav radar is probably more powerful, but still, it's not like a 200NM range air-defence radar. I'm guessing they spec-d the system with incoherent requirements, and either the contractor that won went for the cheapest working hardware without asking too many questions, or maybe they took an old system's spec and asked for an incomplete upgrade... or nobody wanted to go to their boss saying the system didn't work because of some badly written spec or badly managed contractor and we need more money, please ? That would track with leaving the system badly working like this without even having some face-saving 'we're trying to work it out with the contractor right now'. Or, most likely, normalisation of deviance. The system came at first with so many bugs and problems that when they got it in some stable state, they'd got so used to work around the bugs that they kept on doing that. Look we already put so much effort in this, what's a bit more? Yeah, we're quite happy with the system, at least it doesn't crash every hour like when it was delivered...