> The Connecticut alone carries enough torpedoes to destroy any other nation's entire nuclear submarine force.
Nitpick, but isn't that a lot like saying "this magazine carries enough bullets to kill a whole platoon of soldiers"? I mean, it technically does, but only if they're all lined up in front of you and you never miss, which is almost certainly not true in real-world conditions.
> This failure to intervene is probably the most egregious shortcoming of VMS. But it's notoriously awful along other dimensions. Here's some of what I remember, mixed in with conversations with folks more recently onboard:
It seems like the military really ought to give the users of systems like this the ability to say "fuck no" and send it back after doing some user testing. Some of the issue identified are egregious and maybe the kind of thing that could get a submarine that's actually fighting sunk. I mean, it sounds like it's so bad it nearly got a submarine that was just cruising around sunk.
Hell, if we assume one-hit-kills and no duds/misses, a mid-war German U-Boat probably qualifies for the same achievement, as far as sheer amount of ordnance carried. Not that WWII subs were any good at hunting other subs, but still. It's not really impressive or surprising that a sub would carry enough torpedoes to technically be able to sink all the nuclear subs of any non-US country.
It's even more restrictive since the statement is only about nuclear subs. I don't think that there are 8 nations with nuclear subs at all, let alone a dozen of them.
I believe my point was that a modern torpedo hitting a ship is a very high kill probability (mobility or other), being it is guided and explosive.
I would say a missile is more similar to a torpedo. We can look to the Falklands as to how dangerous missiles are against ships. This isn't your grandfathers WWII torpedo.
There is only one other case of an anti-ship missile I can think of off hand, in Desert Storm when a Silkworm was shot at a fleet and shot down with a SeaRAM(?) I think.
I am surprised at the downvotes, but I guess also not. Either way, the information is out there. I agree with the article in that military software is generally awful, but I'm guessing it is not easy to innovate.
> Torpedos are not bullets, I don't think this is a good analogy.
The point of the analogy is that the enemy platoon / nuclear submarine force would need be to be located and behave in a way that allowed a single shooter to wipe them all out almost simultaneously. This is particularly unlikely for submarines, especially nuclear-armed ones.
I took "nuclear sub" to mean "nuclear powered" (as opposed to e.g. diesel-electric, which are still fairly common), which I think represents a somewhat larger set of submarines, outside the US, than just the set of all non-US "boomer" (nuclear-armed) subs. That is, attack subs without nuke-tipped missiles can still be nuclear subs because they have a nuke plant onboard for power.
Agree - it's not actually clear which type is meant. If boomers then this is a indeed very small number (e.g. only four for the UK, which is one of the few non-US countries (four?) to operate boomers).
I do think that's a fair critique of my analogy on the firepower of a Seawolf class submarine.
I'm trying to relay that it's exceedingly deadly submarine. The best in the world. The envy of all other submarine classes.
I don't think there are fighter aircraft that carry enough missiles to down an entire country's bomber force.
The Seawolf was made to destroy other ships. It has all the stats and capabilities to do it. But the kicker is it has incredibly bad navigation software.
Well, the design requirements for the Seawolf class were actually probably something like this!
Basically the Navy wanted a monster that go deep behind Soviet lines and tear things up before they made it out of the backyard.
"[Seawolf's] emphasis on fast tactical search speeds and a massive torpedo magazine were reflections of its design mission, which was to independently search for and kill Soviet submarines in the relatively confined and target rich northern waters of the Soviet Arctic littoral." [1]
It is surprising that there isn't constant passive bathymetrics. The models exist, the hydrophones are already there, and the entire hardware/software stack needed to implement it is there. What's the hold up?
No way. RF doesn't go anywhere in water. Besides, an entire hydrophone array is at least 60 dB quieter than propulsion systems in terms of EM emissions and will be on par with life support systems, which I assume do not ever get voluntarily shut down underwater.
The author seems to know about submarines, so let's give him (?) the benefit of the doubt... But without knowing the cause of the accident, the author is calling for a specific change. This seems problematic. Perhaps there is a very good reason that the computer system performs like this.
Also, if you have the computer checking everything, then those 5 people that are supposed to be redundantly computing the navigation plan are highly likely to be less diligent. Human nature and all. Isn't that likely to result in a worse outcome?
Everything about this hilarious and terrifying. It's hilarious and terrifying that they couldn't drive a $3 billion nuclear submarine without crashing it. That the navigation software on the sub is so bad that there is a website about it describing how its navigation software takes "minutes" to zoom in and out of maps. That if the sub were to be equipped with smarter and smarter autopilot software, the humans operators would eventually forget how to pilot the sub themselves the way that commercial airline pilots keep forgetting how to fly.
> That if the sub were to be equipped with smarter and smarter autopilot software, the humans operators would eventually forget how to pilot the sub themselves the way that commercial airline pilots keep forgetting how to fly.
Well the lack of situational awareness with EFIS (glass cockpit) systems is a known issue. Pilots tend to 'switch off' because of the low workload and then when something goes wrong they're not aware of the situation because they haven't been following along.
This has contributed so some incidents such as the AF 447 crash where the pilots were basically unaware of the actual situation of the plane and flew it straight into the ground (well, sea).
I can understand the Navy wants its crews to be more involved for that reason (and perhaps also because the enemy might deliberately instill confusion by messing with navaids etc), but I think there should be at least a warning if you try to do something that's known to be stupid.
I think you're identifying one of the strongest argument against my claims. Automated, or computer assisted, reviews will only increase error rate because humans will assume that computers took care of it all.
You're probably on to something. When radar was first rolled out to all Navy ships to assist navigation (post WWII), accident rates actually increased.
My hunch is that Sailors drove ships riskier thinking that radar would save them. A bit like the findings of seat-belt safety laws: no impact on fatalities.
But I'm not agitating for full-blown computer reviews. It just feels like the software should have the computing capabilities of Excel lol
Fair enough. Perhaps something like doing checks after the plans have been manually computed, and then errors/warnings are flagged and used for evaluations and training. But then again, how is the culture of the Navy? Would such data be used exclusively to punish people?
It's a tradeoff. Trusting computers too much gets you into trouble (loss of navigation skills, over reliance on a potentially faulty system), but having to do things manually and depending on discipline also doesn't scale. You need to maintain enough discipline (validate the computer's results) but still have a better source than "Well, myself and three others looked at this chart for an hour and couldn't find anything above 350FT".
Discipline works until time pressure causes discipline to relax, and then the loosened discipline becomes the norm (normalization of deviance). There is no reliable way to restore discipline (in a timely fashion) after that happens, and then a collision would become inevitable. If you only rely on discipline, you're bound to fail. If you have means of relieving the reliance on discipline and don't use them, you're making a tragic mistake.
> Also, if you have the computer checking everything, then those 5 people that are supposed to be redundantly computing the navigation plan are highly likely to be less diligent. Human nature and all. Isn't that likely to result in a worse outcome?
I'm not sure I've even seen a situation in practice where an additional safety check made the situation worse. Those same people that shirk their duties and half-ass their job under the assumption the computer will just find the problems generally make a plethora of other mistakes if a computer isn't there to double check.
Computer verification of work, usually done by applying rules and heuristics, is useful and when done well, and roughly analogous to an additional human checker IMO. If policies and expectations are set right, it's a better outcome.
This may or may not follow for the initial calculation being done by computer and then checked by a human. Some of the competitiveness of people to make sure they do the job well and don't need fixes from a computer/human checker go right out the window and perhaps that does lead to complacency.
> Those same people that shirk their duties and half-ass their job under the assumption the computer will just find the problems generally make a plethora of other mistakes if a computer isn't there to double check.
If they half-ass, but follow the computer fixes, maybe nobody knows they were half-assing. If they half-ass and other people fix it, their half-assing is known and remediations are available.
It's pretty easy to have the computer log and/or notify about failures. Presumably if a person is double checking and notices repeated failures, they would be expected to notify superiors that there's a problem somewhere. I'm not sure why we would assume the computer would do any less.
> Also, if you have the computer checking everything, then those 5 people that are supposed to be redundantly computing the navigation plan are highly likely to be less diligent.
This is surprisingly easy to fix. If the computer notices before the human, call that a failure. Say, if the computer spots terrain higher than the current depth within X radius (that wasn't intentionally planned for), that's a failure.
I assume the military already has a regime in place to handle "you dun goofed". You can string failsafes after goofed but before the wall.
There is a specific reason for the system performing like that... a development process that lets somebody in a far off office choose software components for financial/political/office politics reasons, wires together separate programs doing each task that are developed separately with barely any integration testing until it's too damn late to fix anything, and a whole host of other "our team is going to do this part using X" bullshit that winds up with the overall system looking like somebody tried to use Legos in one part, Lincoln logs in another, pottery cast clay elsewhere, and has three different interconnection schemes because each level of bureaucracy involved mandated a different buzzword when it got to review things two to five years after the last level saw it.
At least, that's what it looked like when I saw it in '98. It doesn't sound like it's gotten any better.
>>>At least, that's what it looked like when I saw it in '98. It doesn't sound like it's gotten any better.
It's 10x worse now. Now there are half-a-dozen different browser-based apps that all do the same thing, and that's BEFORE you mention the AI data fusion initiatives people want to integrate.
That's because the Navy doesn't rely on software to do these checks, the officers and crew are supposed to ensure they don't crash. This idea of having software check things is dead in the water, because of that. The real problem is training, and much like any other human problem, this one cannot be solved through technology; it has to be solved by culture changes.
VMS, however, was horrible a decade ago, and I'm not surprised it's still horrible. We used paper charts rather than VMS back then because it was so horrible.
> This idea of having software check things is dead in the water,
I accept that people have to make the judgement calls and sign-off, but if the maps are in fact accurate why couldn't the computer at least issue a warning / red flag or similar when there are obvious problems (requested depth within some threshold of the actual depth).
I came across a scenario editor for a land training simulator that didn't provide any way of testing intervisibility between two points. The course authors wasted vast amounts of time when assigning vehicle positions clicking around maps to see if potential targets were in fact visible to the trainees. An auto check would have allowed the course authors to use their expertise to do things that couldn't be automated, building better scenarios faster.
I agree in the case of planned maneuvers for sure, however if you want the result of the "5 Whys" (kinda joking) then my answer is: because the contractors that build this stuff SUCK ASS. Sorry for the harsh language, but I worked on a pre-com ship during my time (an LCS, go figure) while it was being built, and the absolute lack of standards on every level (from the top of the SWO military chain through the dogshit contractors) is part of what made me leave the Navy.
I'm not gonna complain about it too much, but man oh man, I think you and I could build better software than what I saw, and I don't even know you from Adam.
My understanding is that all government vendors must be listed on the GSA - getting onto that is a start. Or, buy a company already listed and then start fighting for procurement contracts.
Defense contracts are awarded extremely subjectively: there is very much an old boy network in play here. There are only a few primes. If you dig deeper into the "small businesses" that are awarded contracts, many / most are started by people already deeply involved in the defense space.
The Air Force has an initiative called Kessel Run [1] to embrace agile software development — that might be your best route to building better software for the DoD. I'm not sure if other branches have similar programs.
Without having a foot in the vendor / contracting process, it's going to be near impossible.
Other responses have mentioned some routes inside... but beware... make the incumbents look bad too much and you'll be bought out and shut down.
Pride takes a seriously distant back seat to maintaining the current procurement monopolies and relationships, and maximizing contract payments for the least effort.
I'll stop there before I start to incriminate myself or get on watch lists if I mention possible solutions.
Borrow a few hundred billion dollars from investors, aquire a major defense contractor like Lockheed-Martin, and have your lobbyists get Congress to insert a sole-source VMS replacement line item in next year's defense budget. Simple.
If you have a business you can start by going through a program like SBIR (https://www.navysbir.com/) or STTR. The catch is that the Navy has to want to buy a replacement (i.e. I don't see VMS on the list of SBIR topics you could apply to solve).
So that means you'd basically have to do business development first with an organization like NUWC Newport or NUWC Keyport (the undersea warfare centers who do submarine R&D) to drum up interest so that the government can issue an actual RFP or similar, and then you could bid to work on it.
Exactly. VMS probably literally "meets the requirements".
HN dunked all over that agile vs. waterfall article from a few days ago, wondering whether or not waterfall wasn't just some boogeyman that a bunch of consultants had to invent to sell certificates, but I'm here to tell you waterfall is a thing and it's still alive and kicking in the Navy, even now.
The vast majority of navigational incidents are caused by human error, but better systems would give the crew a chance to realise their mistakes
At the moment lots of maritime crew have alarm fatigue, the system constantly warns them of danger so they learn to ignore alarms and when something super serious does happen, they can ignore it
Sure, the officers and crew are ultimately responsible. But how are "we" enabling the officers and crew to do their jobs? Manually verifying minimum soundings is a terrible use of one's time AND something that a computer will beat a human at every time.
A colleague visited a multi-billion-dollar, safety-critical facility that had adopted automated alarms based on safety rules.
He was there because they were asking for software to help them sift through the cacophony of constantly-firing alarms which were distracting all their staff playing whack-a-mole "disable" and ruining situational awareness.
I imagine it's similar here. Do you want the sub to move up automatically? To fire an alarm? To dissalow a maneuver? Absolutely not. Imagine a crew knowingly pushing their vehicle into potentially dangerous maneuvers and spending those critical moments fighting the vehicle or disabling alarms.
This is how the "stick pusher" causes crashes on airplanes.
The fault lies with whomever commanded the maneuver, not with the ship for doing a minor mutiny to prevent it.
> I imagine it's similar here. Do you want the sub to move up automatically? To fire an alarm? To dissalow a maneuver? Absolutely not. Imagine a crew knowingly pushing their vehicle into potentially dangerous maneuvers and spending those critical moments fighting the vehicle or disabling alarms.
These kind of systems typically have manual overrides. If the operator truly believes they know best (or are in an exceptional situation that the automated system cannot account for), they can override the automated system (including many, if not most, safeguards). That's design 101 when you're building critical systems.
> The real problem is training, and much like any other human problem, this one cannot be solved through technology; it has to be solved by culture changes.
What this makes me think of:
> Why test software? It's a culture problem, not a technical problem. Just write correct software.
As long as no one ever makes a mistake it's a totally valid approach...
This can be solved through technology. The post is all about how easy it would be to solve through technology and how ridiculous it is that the technology doesn't help. How can you say that the real problem is training?
Although it does sound like this piece of software could use improvement, I would never expect a mission support system to be the only thing safeguarding me from going aground. I don't know anything about submarines, but I would expect some kind of real-time navigation system to alert me before hand.
> I don't know anything about submarines, but I would expect some kind of real-time navigation system to alert me before hand.
For docking simulation to the space station, SpaceX has a website for controlling the Dragon capsule's UI. That could be the UI ergonomy baseline for measuring the current submarine's software against. The Orion and Starliner capsules have their own different more hardware oriented UI. I would expect nextgen submariners to be digital first native fast twitch glass screen navigators, but a submarine taking damage will be a splashy environment as seen in the movies and touch screens won't be as reliable as physical toggles with redundant bypasses etc.
Maybe "Fat Leonard" contributed to the contracting process that put this software on the suboptimal submarine without proper human factors consideration.
Something doesn't add up here. If it's China's official policy that it blatantly and deliberately attacked a USN warship, why aren't we at war with them? They've never directly attacked any other US ships or planes in the South China Sea.
Because even if true neither country wants to go to war, countries test each other's military responses all the time and it never goes much further than sending in jets/ships to watch each other while some diplomatic phone calls take place.
Yes but it wasn't supposed to be there. Are you going to start WW3 for material damages? Even if the entire sub had been destroyed, would you start WW3 for a few hundred people?
No. You take the losses, put a brave face and spin a story about navigation error.
Then if you think you weren't in the wrong and they need to get a lesson you destroy something of theirs a while later.
Btw, I'm not saying that's what's happened. I'm just hypothesizing that in case it happened like that they wouldn't start WW3 over it.
Foreign spies are caught and punished/executed probably every year more or less. And governments have virtually no incentive to admit "hey my spy got caught by the enemy". Ditto for stealth submarines.
It's really hard for me to believe the USN allows countries to blow up their warships then has the courtesy to hide it domestically. The whole purpose of the USN is a show of force and power projection. If countries are allowed to take that sort of action without immediate retaliation that is all gone.
Firstly, they didn't blow it up. If the Chinese story is true, they surgically disabled it. Either way, no American blood was shed.
Secondly, the modus operandi of the contemporary Pentagon is walking a fine line between a) inflating foreign threats to secure Congressional funding and b) deflating any challenges to the perception of American military supremacy. Defending Americans from actual threats is a distant follower.
> This was an intentional placement. This locations was as far away as possible > from the nuclear power plant for a close local directed-explosion attack.
> It was then ignited, and ended up causing serious damage to the bow of the boat > and a complete loss of sonar sensing ability.
It is not “the Chinese story”; were it the actual official Chinese story we wouldn't be getting it by this circuitous route, we’d get it from Chinese state media, both in Chinese for domestic consumption and English (etc.) for international consumption.
There are many criticisms you can make of the PRC, but “they are incapable of assuring that their official position is heard clearly and loudly” is...not among them.
> There are many criticisms you can make of the PRC, but “they are incapable of assuring that their official position is heard clearly and loudly” is...not among them.
What an incredible claim. Americans think China is literally committing a Holocaust right now. Chinese/Russian media is soft/hard censored on the biggest Western social platforms and official narratives from those governments almost never make it to American/Western ears without massive amounts of spin from Western state/corporate media.
Besides, there is a strong explanation for why Beijing didn't broadcast this: they don't want to inflame tensions, especially in the runup to the Olympics.
> Americans think China is literally committing a Holocaust right now
Yes, but they aren't exactly unaware that China's official position is that they are not, and the awareness of this official position doesn't come through random minor internet sites reporting “official” accounts machine translated after being received from anonymous friends who got release that were authorized by Beijing.
Getting the official story heard loudly and clearly and getting it believed are too very different goals.
> Besides, there is a strong explanation for why Beijing didn't broadcast this: they don't want to inflame tensions, especially in the runup to the Olympics.
Yes, that's a very plausible reason why, even if this highly improbable story were true, it wouldn't be China's official story right now.
It's not, however, even a remotely plausible reason why it would be the official story and simultaneously completely absent from official media and yet still authorized for release via the channel supposedly used here.
Don't confuse "official" with "true". Beijing is happy, officially, to accept Washington's story that they clumsily crashed into a rock.
The "true" story is really only relevant to the military planners on both sides. And presently it doesn't serve either of their interests to broadcast it publicly.
The claim in the article which provided the story is that it is the “official Chinese story”. The article carefully avoids claiming that the story is true, though it obviously wants people to conclude that.
> Beijing is happy, officially, to accept Washington's story that they clumsily crashed into a rock.
Right. So the simplest claim in the article about the story—that it is China’s official story—is simply false.
> The "true" story is really only relevant to the military planners on both sides. And presently it doesn't serve either of their interests to broadcast it publicly.
Or, maybe the true story is what is officially broadcast, and the one with the obvious lie about the nature of the story is false beyond just that obvious lie?
> > There are many criticisms you can make of the PRC, but “they are incapable of assuring that their official position is heard clearly and loudly” is...not among them.
> What an incredible claim. Americans think China is literally committing a Holocaust right now.
You have conflated "heard" with "believed". The CCP is heard, not believed. Everybody knows the CCP denies those claims; the CCP has been heard.
We might already be at war, and it seems to be escalating.
The Biden admin is growing cold to both China and Russia. They just announced they won't support the 2022 Olympics.
Cyber warfare and espionage are reaching new peaks.
Russia just blew up a satellite, which caused NASA astronauts to take shelter. Target practice for fog of war.
China demonstrated their orbital hypersonics and glide platform, which is hard to track and defend against. Nuclear MAD that defeats US countermeasures.
Russia is amassing forces to take over Ukraine and Georgia.
China is increasing incursions over Taiwanese airspace.
China is delisting from US exchanges.
The US pulled out of Afghanistan, freeing up personnel and logistics. The best reason to do this was to prepare for a two front war. They could have otherwise remained deployed indefinitely.
Australia and Japan are buffing their navies and warfare capabilities substantially.
The US is in the awkward period between upgrading existing systems and designing next generation weapons.
We might really go to war in 2022 if China and Russia think they can take Ukraine and Taiwan. A hot war.
> The Biden admin is growing cold to both China and Russia.
Washington has been cold to both nations for the better part of a decade/century depending on your perspective.
> They just announced they won't support the 2022 Olympics.
False. Virtually all American athletes are attending. Whether the Biden admin is diplomatically boycotting or wasn't even invited is a matter of perspective.
> Cyber warfare and espionage are reaching new peaks.
> Russia just blew up a satellite, which caused NASA astronauts to take shelter. Target practice for fog of war.
> China demonstrated their orbital hypersonics and glide platform, which is hard to track and defend against. Nuclear MAD that defeats US countermeasures.
> Russia is amassing forces to take over Ukraine and Georgia.
> China is increasing incursions over Taiwanese airspace.
When a historically passive person starts acting assertively, an unscrupulous observer might judge it as aggression. Russia and China are demonstrating that Washington is no longer the undisputed military superpower it once was, that it can't bully anyone it wants. This has critical geopolitical implications but does not necessarily point to an inevitable war.
The fact is that USA has hundreds of overseas military bases while Russia and China combined have less than 10. Many of those American bases are on the doorstep of both competitors. Until China is parking carriers in the Gulf of Mexico, it hasn't even begun to reciprocate American military assertiveness/aggression.
> China is delisting from US exchanges.
...and relisting on e.g. HKEX which is historically accessible to international investors from America and elsewhere. More likely, Chinese companies are hedging against the collapse of Wall St. (if the Fed raises rates) or the USD (if they don't).
> The US is in the awkward period between upgrading existing systems and designing next generation weapons.
Like the F35? Pretty sure that failure has nothing to do with "bad timing" and everything to do with the corrupt state of Washington and the Pentagon.
> We might really go to war in 2022 if China and Russia think they can take Ukraine and Taiwan. A hot war.
Why, though? Whose interests does it really serve?
> > > The US is in the awkward period between upgrading existing systems and designing next generation weapons.
> Like the F35? Pretty sure that failure has nothing to do with "bad timing" and everything to do with the corrupt state of Washington and the Pentagon.
IIRC this concern is mainly about attack sub capabilities, and the US navy will in fact enter a period of exceptionally poor preparedness for operating in the waters around Taiwan in the event that war breaks out, for a few years between about 2025 and 2030. This is due to procurement decisions made years and years ago, since there's huge lead-time on building new ships.
Whether this actually means anything—I don't know.
>> We might really go to war in 2022 if China and Russia think they can take Ukraine and Taiwan. A hot war.
>Why, though? Whose interests does it really serve?
Not sure about Ukraine, but if Xi's perceived legitimacy falls further then he could invade Taiwan (and risk huge domestic backlash) as a gambit to hold onto power.
Don't forget that the CCP's raison d'etre is not to responsibly govern China but simply to accrue power. If that means sending 3 million Chinese youth into the Taiwan meat grinder, then that's a price he's willing to pay.
Quite the opposite, actually - KRudd's speeches and essays.
(I think a lot of people that don't keep up with Chinese news and politics are quite dismissive of both the public and the China watchers' fear of Xi, and I think a big part of this dismissal comes from trash-tier organisations like Sky News constantly publishing dumb "China Bad" pieces.
When you listen to the people on the ground, though, and see all kinds of major precedents being broken daily, it's clear that something profoundly unsettling is going on under Xi's leadership.)
That's the funny bit. Supporting the rise of China has been in the direct financial interest of corrupt politicians and businessmen all over the world for the past 30 years, yet now even they are spooked.
The conversation is about the threat of war with China, which you don't believe is serious but others do. That's fine. You have a right to your opinion, and I'm sure there are reasons behind this opinion.
So please share them, or rebut others' posts. Maybe inject a bit of humour into it to lighten the mood somewhat.
The "smart" quips you're posting are just annoying, though.
I thought we were solidly in shitposting territory when I read "Don't forget that the CCP's raison d'etre is not to responsibly govern China but simply to accrue power".
China is a real place with real people, not one of your Marvel comic book settings.
> If it's China's official policy that it blatantly and deliberately attacked a USN warship, why aren't we at war with them?
It is not China’s official position, which is why this supposed “official story” is not sourced to any official Chinese media, but to an email, supposedly sent by the author’s anonymous friend, that contains information that was supposedly authorized by Beijing on the “official Chinese story” which nevertheless the PRC has not released through any of its many state controlled media outlets.
(It plausibly could have been authorized by Beijing for this exact use: divisive propaganda through multiple steps of deniable cutouts that has nothing to do with either the facts or China’s official public position. Or it could just be an invention of the author, or the author’s anonymous, unaccountable friend.)
I think the US misses the cold war and is trying its damn best to find a new adversary to compete against. It’s been said before, winning the cold war made the US arrogant and complacent.
Nb I’m talking about countries as if they were people, I do not mean that people in these countries are thinking these things.
Remind me when USS McCain collided with another ship in a busy channel [0]. Because of a UI issue, they couldn't figure out where throttle control was and ran into someone. Which is crazy to me.
I was going to say, that there probably a few dozen people that use submarine nav software, so it's hard to get a representative sample of usability...but then it occurred to me that airplane software has a fairly limited audience too.
What's the process for test for developing aircraft software? How is nav done in aircraft? Theoretically they have the same issues (like hitting the ground).
Fair enough, I suppose. The article author was comparing submarine nav software to phone nav software though and google says there are 5+ billion mobile users. That's another couple of order of magnitude more. That'd explain why mobile software is more polished. I guess any kind of mass market product would be higher quality. The same argument ("number of eyeballs") has been used with open source software vs closed source.
There are probably a few thousand users of submarine navigation software. But the willingness to pay *should* be quite high, which in most other markets would translate to a quality product. The tool should help submarines:
* Prevent groundings (loss of a $3B platform, 120+ lives in worst case)
* Do their missions better (increase the value of the platform)
The UI issue is real, and is a problem, but the root cause of the 7th Fleet's crashes during that time period is lack of training and inadequate leadership, due to an operational tempo that's Thenot sustainable given current funding and ships. Instead of building new cruisers, or taking the time to dry dock and repair these ships, the admiralty has been ok'ing "at sea" repairs, leading to situations like this where primary systems aren't functional and back up systems are run for far longer than intended. The admiralty has been looking for technical solutions to a human problem for about a decade now, becaise they'd rather buy a new set of carriers and the F-35 than build the ships they need to support the mission given to them by Congress. The result is burnout, and incidents like this.
The Navy as a whole has a severe manpower shortage, and in the incident report for the McCain collision I believe it came out that the officer on duty was 17 hours into their watch, and didn't have a full compliment in the watch house because one of the crew who was supposed to be there was off in the lower decks for an unstated purpose (anecdotal evidence from my Navy friends, probably catching up on sleep, or seconded to repair something while they had "non-critical" time).
The collision only happened because instead of being trained on seamanship as a whole, incoming officers are trained how to work the computer systems they're interfacing with. The Navy cut down the training periods as well - instead of training under a senior officer for a few months, to offset manpower shortages, incoming officers are put in charge immediately, and given a stack of CDs (wish I was kidding) to complete their training.
The surface Navy is in an incredibly dysfunctional place right now, and Congress/the admiralty have been paperig over leadership failures by spending more money, and blaming technology
"Because of a UI issue, they couldn't figure out where throttle control was and ran into someone."
That's happened more than once. NYC ferryboat allision.[1] It's another case of touchscreen mania. With ship controls, it's common to have more than one control station for basic helm and throttle. When docking, it's common to drive from a control station where you can see the dock. So which station has control is an issue. Some systems have physical feedback, so that the wheel and throttles at all stations move together. That avoids mode confusion.
The oldest aircraft navigational aids to avoid hitting the ground are fairly simple, and predate software (the radar altimeter is a good example, which in its most basic form just tells you your altitude above the ground and works really well in most flight regimes). Ground proximity warning systems are more along the lines of what you're thinking, and rely on the aircraft's flight computer to predict an intersecting flight path with its digital terrain model within a specified period of time (typically relies on GPS and/or INS data). As long as the software isn't integrated into aircraft flight controls (auto-GCAS in fly-by-wire military aircraft, for example) it doesn't necessarily need super-rigorous testing, although when it is connected to automated flight controls it should* have* (looking at you, Boeing...) an extremely rigorous testing process to ensure it behaves deterministically and as the pilot expects under all normal and emergency conditions. This generally involves a lot of bench testing, with a (potentially very large) number of test flights to ensure it works as designed in enough distinct conditions to have full confidence in the system.
TCAS (the family of systems aircraft use to avoid hitting other aircraft) is much simpler and doesn't rely as heavily on GPS/INS data, but generally only gives data on cooperative aircraft transmitting transponder or ADS-B data. A very simple version gives a traffic alert when another aircraft approaches within a specified distance of you, but may not give any other useful information (relative altitude/position, heading, etc.), and the most basic version I can think of just gives a range to a single cooperative aircraft.
I think you'll find that you're off by a few orders of magnitude on the number of submarine navigators out there, and there are few enough certified avionics systems that most are used by a substantial enough audience (and, more importantly, mandated by enough national aviation authorities) to be worth the R&D effort.
That said, military hardware is often decades behind the civilian world when it comes to many of these mandated safety features, so I don't find it surprising that military ships (often with proprietary radar and sonar systems designed primarily for combat, and not wanting to broadcast their location to potential adversaries) don't have good integration with commercial collision avoidance software designed to work in a collaborative environment with off-the-shelf hardware that may have only been installed as an afterthought, if at all.
Whoa... I had no idea that submarine software was this bad. Not just the lack of warnings but also "Waits for VMS to load the next screen, which can take minutes.". Why do you have to wait minutes to load a map?? And why is this running Windows XP?
I'm also surprised there's no contour lines between the depths (although perhaps this is done to not infer a knowledge of depths in the intermediate points where perhaps there is no such knowledge).
> I'm also surprised there's no contour lines between the depths (although perhaps this is done to not infer a knowledge of depths in the intermediate points where perhaps there is no such knowledge).
Yes, contour lines would imply accuracy that isn't there. The depth numbers indicate positions where the depth was actually measured. Any other location that doesn't have a number was not measured. Bear in mind that even if you have a depth number on your chart, it might be old and out of date. Safe navigation is never guaranteed. And subs never run depth-finder sonar when on patrol.
The broken assumption thee is that the ocean floor doesn't change. Things are changing all the time. Faster and faster as you get shallower and shallower.
Shipping channels and shallows need to be resurveyed constantly or you have no idea what you might encounter.
It's also worth noting that the waters where depth accuracy is most important to a submarine are also the places where the depth is more likely to change (estuaries, ports, especially new/expanding/busy ports).
Tides & currents moving the bottom (sand, etc.) around, mostly. But it's also possible for a coral reef to have grown taller. Or a volcano, I suppose. :)
NOAA's Chart No. 1 explains the symbols used on charts.
Crappy pieces of software like that cannot simply be wholly blamed on the vendor. It's up to navy leadership to decide how to distribute funds to vendors to develop software. I wouldn't be surprised if there is a high up navy officer who likes VMS, thinks that the missions planing process is fine the way it is, and doesn't want to allocate money for anything beyond bug fixes. Things like that happen all the time in government software contracting.
> It's unacceptable work from our vendors and procurement processes… It's as if our procurement process and the vendor collaborated to absolve themselves from any responsibility by serving us such an aggressively unhelpul[sic] tool.
If subs were companies, competition would solve this problem. Some enterprising engineer says to herself "I can build a better VMS" and does. Since it's 10x better than the existing VMS, some submarine crews adopt it, and pretty soon it's in widespread use across the fleet. Engineer profits, sub crews are more effective and probably it's cheaper too.
But it's the government, even worse it's defense. So regulations and secrecy (some reasonable, some not) muddy the waters until everyone's blind, including apparently the VMS.
> the navigational software on the $3B warship is far less capable any maps app on your phone. The software, called "Voyage Management System" (VMS), is the hub of all the ship's planning. But it can't even do basic safety-of-ship alerting.
My phone can do "safety-of-ship" alerting? I'm the first to shit on defense software, it's my background, but map software for a submarine is safety-critical. While submerged it's basically their eyes. It has to be more reliable and trustworthy than possibly any other map software. Not only this but navigation information would have to be fused together from GPS as well as INS (inertial nav).
My 2 cents. Background in defense but not submarines.
I've worked in defense as well. Older software seemed to be tested more, or otherwise more reliable. Sure, it could be outdated, but generally it was usable.
As they moved away from embedded to more networked and newer tech stacks things got terrible. The software world of today is not compatible with the needs of the defense industry.
Plus all the red tape and misdirection. The software need comes from an organizational budget that has to use money to justify receiving money. Then it funnels down into political buckets, who use the dollar amount given to determine needs/wants. Then it goes back up the chain to the government. Then to a contractor, then a flurry of subcontractors. Then finally a developer. Rarely is the warfighter who will actually use the system consulted. Even then, rarely will the programmer meet that person using the software.
I don't think all of those problems are unique to government software. Some (a lot?) enterprise software is atrocious and disliked by end users. That's because the people making the purchasing decisions != end users.
But it's flabbergasting just how bad VMS is considering it's the navigation system for these national assets. It's not like an HR system with poor UX--navigation is essential to the safety and effectiveness of the whole platform!
> Some (a lot?) enterprise software is atrocious and disliked by end users. That's because the people making the purchasing decisions != end users.
It's because the people making decisions care about putting money where it earns the most return and have more on their plate than they can address. Making software more pleasant for internal users rarely makes it to the top of the list.
> navigation is essential to the safety and effectiveness of the whole platform!
Subs crash very rarely, so the software seems to be sufficient.
> Subs crash very rarely, so the software seems to be sufficient.
Subs also operated for many decades without any kind of computer-assisted navigation, and training to handle the loss of such systems is routine, so your statement is pretty vacuous. The software at a minimum should allow sailors to operate as safely as they did without it, but one would assume that the entire point of software assistance is to improve safety and/or operational effectiveness.
I was a developer at a large contracter doing work for the Navy in the 1970s. Compared to today, there was almost zero code review, but an insane amount of testing, from the lowest module level to the highest integration level, both against the requirements and in simulation. We did not subcontract software. I often wished I could talk to the warfighter who was going to use my stuff but it never happened. Worse I never got any feedback on whether my stuff was even used. We did have quite a few ex-Navy people in our dev group and that did help.
Fucking bad from what I've read. It's a really bad problem still and the USN needs to correct it by having a tighter integration with the HW/SW people and the actual soldiers/sailors.
In a way it was awful. It was sort of like anti-agile. There was absolutely no dialog between the devs and the customer. If the requirements said the throttle had to be on the touchscreen (to use an example from another comment), that's what we did, even if we strongly suspected this was a really bad idea. I was too far down the food chain to know where these requirements came from, it was like they were handed down to Moses on stone tablets.
How fast could we develop? In addition to the requirements, we were also handed a schedule (a PERT chart, if anyone still knows what that is). It was laughably padded. Padded so much that it would have been impossible to fall behind schedule. I almost always finished my work for the day before lunch. Sometimes I would then go for a three martini lunch with the sales guys, or spend the afternoon in the library or flying the F-14 simulator. Sometimes I would spend the afternoon working on tools to make debugging easier. It was a fun job, but ultimately unsatisfying and I left after two years.
The only time I had contact with the end user as a defense contractor was when I was working on-site in an R&D shop, where we were creating software for users that were all in the same "integrated" team with us. That was the only job I've had in the industry I could describe as "fast-paced."
Twenty years ago, when VMS just got introduced, it behaved like this...
I can't believe that after all this time, it's still completely borked, in all the same ways.
Somebody at NAVSEA needs to be dragged by their nostrils out on a deployment, take notes, and go back to their office with their pride in a garbage bag.
Proud as hell to have served, and angry as hell that our current crews are still dealing with the same ---procurement--- failures.
That's from the time when everything was still (and everything still being planned for the replacements were also) big-bang releases. 5-10 year projects to replace the broken system that still lack the necessary capabilities. I've never worked on a Navy project, but I've seen several spectacular USAF failures of similar magnitude. The most hilarious (in an absurdist sense) was having 3 generations of a system running concurrently because none of them had all the necessary features, when I left they were working on number 4.
Mine would be shorter development cycles and incremental deployment of improvements as soon as basic functionality is achieved. Work in an accurate simulator with an experienced crew from day one would also help.
Don't plan projects out 5+ years and fail to revisit the plan. That is, don't do Waterfall.
Work with the actual user/operators (this I did see a lot of, but not on new systems, only on systems in "maintenance") to get regular feedback. One of the best jobs of this I saw brought in both current and retired operators. Current ones rotated through helping evaluate the system and the requirements, retired ones were hired on to be part of test/QA.
Switch from fixed contracts to more level of effort contracts.
Generally shift towards continuous delivery where possible (with information systems much easier than with embedded systems, but doable to an extent with embedded systems).
Fix the official release test phase which is often 6-24 months at the end, most of it waiting. This is part of the program's overall process which is very Waterfall in structure for most systems. I've seen work that was completed and put on a shelf for over a year before being evaluated for flight readiness. Well, it was useless to operators by that point [0] and delayed vital feedback for the next iteration. That's partly a logistics problem, but addressable.
Fix the lack of trust the operational test teams have for development teams. There was a complete lack of trust for the teams delivering the product to be tested, but the test plans for flight testing were often so bad that they were a joke (for the particular delivered systems, not flight test plans in general). If you don't have the trust, gain the trust. Take the existing operational test plans and back port them to your own test infrastructure and test efforts. Deliver that report along with the product, eventually they may trust your test reports and can start speeding things along.
As with all software, get as much testing done as early as you can. The longer you wait, the more costly it is to address discovered issues, particularly validation issues.
Finally, get experienced software engineers into program offices. Most of the time their "software engineers" are a recent college graduate, or someone from a totally unrelated field that wrote some Matlab code once. They lack sufficient experience to properly manage or guide the management of the software portion of a project. The worst I saw with this was that system I mentioned in my previous comment, the program office lead for the software portion was a newly pinned on 1st LT history major. Zero technical experience (had been in some finance role before), they trusted the contractors too much and made decisions more on their input than anyone actually using the system.
[0] For context, this is software that spent 2-4 years being developed and then would be shelved for 1-2 years before being tested. Which meant it still had 1-2 years for fielding. So from conception to release you're talking 4-8 years. That is an awful pace.
Your phone has Google Maps or Apple Maps, which will alert you when there are road closures or hazards ahead, yes. It even has a list of places where there are roads, and places where there are not roads, and will not (typically) direct you to go off-roading. The behavior of VMS is like punching in a street address and having Maps tell you to go straight there as the crow flies.
It's hard to redundantly guarantee correctness, if you wanted to rely on VMS to avoid hitting the seafloor that would indeed be difficult. But come on, how hard is it to offer a highlight for the shallowest points near your course, or a warning that says "you added an extra zero here"?
> Your phone has Google Maps or Apple Maps, which will alert you when there are road closures or hazards ahead, yes. It even has a list of places where there are roads, and places where there are not roads, and will not (typically) direct you to go off-roading.
Google's servers have this information, compiled in real time from countless sources including direct satellite cartography and all beamed to a phone acting as little more than a user interface. Take your phone a few hundred feet below the water where it is cut off from the outside world and even the best maps in the world aren't accurate and you're going to run into a lot of things.
You could have a local copy onboard. There should be enough rack space on the boat to keep a copy that gets updated when the boat gets connected to shore data. Also for sea data, the data set would be much smaller because it hardly changes, and you don't have as many variables(i.e. live traffic, construction, etc), especially under the sea.
I don't agree that the data set would be much smaller. Maps for driving may look complicated, but they're just weighted graphs. You might have a few different data points for MLK drive like length, average traffic, speed limit, class of road, etc, and these values might even be given for each short stretch of the road, but you don't have to have any knowledge of the actual topography, and all of these values can be safely taken as rough estimates. No one is going to die if you falsely classify a stretch of road as high traffic when it's really moderate.
For a submarine, you need to know the topography of the sea floor down to meter scales. Accurate maps are few and far between, and difficult to create. Changing currents, underwater landslides, silt from rivers, sunken wreckage and even just garbage can create and move obstacles large enough for a submarine to care about in relatively short timeframes. Of course submarines can and do navigate with maps prepared ahead of time, but it's tough, and every now and then you get a run in with a sea mount.
I agree the undersea landscape can change dynamically but there is no way to do undersea data transmissions of the size required to do live updates. I guess what I meant is a sub should be able to have a more modern solution onboard because it wouldn’t take up much space on board which is a massive consideration for things like this.
Even if the data set is huge, you should be able to fit the system and a redundant system in a full rack. When I was on a surface ship, our entire nav system fit on a single server with an additional server as a backup. Our system could be updated live because we had internet on board. Subs don’t have this luxury so they would need the full dataset on board.
This will not have the same feature set but the UI will let you know that this is operating with reduced data. Route planning is still very good offline. I had to use this feature because for some time part of my route home had no cell signal.
You might be misunderstanding. They parent may be saying that they download the maps and just search for a road and use it like a paper map.
Also, "GPS" in the United States colloquially refers what people in the UK would call "sat-nav" not to the satellites + protocol (what it actually means on paper).
> You might be misunderstanding. They parent may be saying that they download the maps and just search for a road and use it like a paper map.
Maybe? When hiking it makes some sense to forego GPS to save battery power. I didn't consider that possibility when I commented earlier, but in my defense the context of the comment is using maps without an internet connection.
> Also, "GPS" in the United States colloquially refers what people in the UK would call "sat-nav"
Sure, but sat-nav doesn't require internet service...
It certainly does. Pure inertial guidance with smartphone sensors is garbage. I must say I'm a bit startled by how many people evidently think that GPS is an internet service...
Cell phones use A-GPS which relies on cellular data service. It allows for faster position fixes using base station signals. Of course a cell phone with a view of the sky can still get a position fix entirely from satellites, it just takes a little longer.
I've used GPS navigation extensively on my phone with no internet service; I drove clear across Canada with my simcard pulled, it works fine.
If I had to guess, these conflations of cell service with GPS are a product of misleading UX created by Google. OSMAnd makes the nature of GPS clear, displaying a count of satellites it's managed to hear. Enough satellites to get a location good enough for car navigation almost always takes less than a minute.
Knowing where you are is very much the problem. If you are 100 meters east of where you think you are, the sea mount you think you are 100 meters west of is a big problem. Inertial navigation systems tell you your position relative to your last "known" location, but if that last point was inaccurate, or if too much error has accumulated since the last point, you can be significantly off from where you think you are.
Couple this with the lack of good maps of certain sections of the sea floor, and human error, and a collision every couple of years becomes probable.
This isn't what the website is referring to. You should go read it. They literally give an example of a sailor entering a proposed navigation track into VMS which is unsafe (it hits the seabed or comes close based on static data available to VMS) and yet VMS still doesn't warn about the unsafe track.
No one, least of all a qualified submarine officer, is proposing that VMS should somehow get a real-time feed of oceanographic surveys while deployed on active operations.
Yeah, and if I steer into a brick wall my phone doesn't tell me anything either.
I read the article, and I agree VMS could likely be better, but the map apps on your phone are not examples of navigation systems that have fixed VMS' problems.
The author isn't suggesting to replace VMS with Google Maps.
The author is suggesting to implement what VMS is meant to do with an application with the same level of usability, reliability and performance as what was put into Google Maps, and Apple Maps, or frankly any reasonably-popular mobile app that doesn't involve gaming.
Do not confuse VMS with a turn-by-turn navigation system, that isn't what it does, or what an actually-usable replacement would have to do. VMS is meant to help plan a voyage and ensure you're safely executing to that plan in transit, and it doesn't do a good job of that for all the reasons the author provided.
I do offline navigation with OSMAnd all the time; you have to think ahead a little (download the relevant maps when you have a connection available) but it works great. I even found out about a construction project under my home before the official notification.
Early in the Apple Maps days I took a road trip from Minneapolis to the west coast and back. Somewhere in southern Wyoming we were headed to the front range in Summit County (west of Denver) and maps took us on what I can only describe as a dirt road up a mountain complete with wildlife of goats or whatever terrestrial creatures stirred.
But the best part? Seeing all the other users of maps along the route! Barely enough room for two cars to pass. But we had each other. Everyone would hold up their iPhone and mouth “WTF?” with wide eyes.
Reminds me of Glen Quaich which I regulary cycle. Single track road, with switch backs and 12% gradients. Often I'll cycle by besumed tourist off the main road wondering where they are. Its a public road but not cleared or gritted in the winter. A couple visiting a nearby village last week were rescued by a farmer after Google sent them along this scenic route in a snow storm.
Lack of training killed them. The ship's command put a farm kid with barely four months in the navy at the controls of a warship in an area that is infamous for how congested and difficult it is to navigate. Not four months experience on the bridge. Four months from when he joined the navy.
> Bordeaux felt confident using the system to control the speed and heading of the ship. But there were many things he did not understand about the array of dials, arrows and data that filled the touch screen.
> “There was actually a lot of functions on there that I had no clue what on earth they did,” Bordeaux said of the system.
As for his boss:
> The chief petty officer had himself received less than an hour of instruction.
That's the guy in charge of training the bridge staff. Nobody knew how to use the system.
The fact you've worked defence and can't see how consumer devices do things submarines can't is the issue.
We all know a submarine is worth x billion, a drone much less. We understand about critical failure on each.
You job is to work out how to merge the two, but instead defence hides behind ideas like verifying software. Software verification should be a tool, not a wall for bureaucrats to hide behind.
> It has to be more reliable and trustworthy than possibly any other map software.
Did you read the detailed examples on the website? Because the point you make is the same point the website makes: VMS is crap, compared to the map application that comes with your phone by default.
It is less reliable, because it crashes all the time.
It is less trustworthy, because you can't even rely on it to do extremely basic checks on the safety of a proposed leg of your navigation plan.
I find the website disappointing for a different reason: the flaws they point out in VMS in 2021 are the same flaws I experienced with VMS from 2006 to 2009 during my own time in submarines. I should be astonished that we haven't made things better since, but I've seen enough of software in defense to honestly claim surprise.
A $3B warship costs less than what (I imagine) has been spent on Google Maps development.
I'm currently working on ship-alerting software, and all the usual "haha programmers suck at their job" memes apply... But then, so does the hardware it's running on. PLC/SCADA hardware that behaves unpredictably with zero support from the (global monopoly) vendor and PC's that are years out of date because getting new hardware approved is fucking torture.
VMS is used across submarine designs spanning all the way back to 2005.
Currently there are 67 submarines actively part of the battle fleet (https://www.nvr.navy.mil/NVRSHIPS/FLEETSIZE.HTML), let's say $3B per submarine, that's $200 *BILLION* dollars of capital expenditure. And it should go without saying that the reason we spend money on submarines is because the missions they go on are that important to the national defense.
I think Google has spent less than $200 billion on Google Maps.
Between the capital expense and the mission to perform, and the repeated underground collisions, I don't think it's too much to ask that the Navy apply some usability design to support one of the most critical functions of any warship, safe navigation.
Because I've used VMS myself and I can attest to everything the author of this article mentions, and it's far from being just a resourcing question: it's inherent to the way the Navy designs, implements and acquires software-based systems. This includes the stuff you mention about hardware (which, oddly, the Navy submarine force had managed to subvert with ARCI sonars, which use commercial servers and a ton of additional spares to meet operational availability needs).
Yes. It's a very similar problem to aviation terrain avoidance systems which are now so common, and such a "solved problem", that numerous popular smartphone apps for flying and gliding feature not only terrain warning but features like "will I be able to make it to that airport" determination (for gliders) which factors in a slew of real-time parameters and terrain data.
And, really, "is the plane going to hit terrain the way it's being flown right now?" is far more complex than the problem the author was describing, which "is what you're planning to do going to hit terrain." They commanded a dive to a depth below the ocean floor, and it wasn't like they were trying to run a canyon like Hunt For the Red October...from the sounds of it, nothing in the area was deep enough to permit that dive to happen safely.
This problem is also a problem the PC/console game development community solved, oh, around two decades ago. For quite some time games have simulated bullet physics while also determining if a shot hits a moving, deforming, 3d object, with checks happening in a matter of ~10ms or thereabouts. "Will the submarine pass within X feet of underwater terrain" is a walk in the park.
There's also the matter of the system not needing to assure a maneuver is safe, but merely to serve as an alert when something is obviously not safe. Given how much these things cost, as you point out, I'd say such a system is beyond warranted.
> Not only this but navigation information would have to be fused together from GPS as well as INS (inertial nav).
I'm going to guess that the Navy has figured out how to very precisely geolocate their submarines and has beyond-excellent seafloor map data.
What sort of "server farm" does a modern submarine have?
Do they need to be super hardened operation in a vehicle
that may be called to launch its missiles in a high radiation
zone?
In a worst-case scenario the sub my surface in the middle of or
end of a nuclear war. They probably want to ensure that the missiles
get underway even in such extreme conditions
Yes, your phone can alert you when you're traveling over the speed limit or if there are hazardous conditions on the road. VMS can't do anything like that.
When I saw the URL I assumed the article was going to reveal that modern submarines are still running VMS on DEC Alphas (or a VAX!). Honestly I was surprised when that wasn't the case.
I thought the same at first. I worked on the Air Force AWACS E3 (https://www.af.mil/About-Us/Fact-Sheets/Display/Article/1045...) program as a contractor in the 2000's. It had dual IBM-360 computers and wireframe-like graphics for their radar displays at the time. This was the Block 30/35 version. It looks like from the link that they may have completely transitioned to the Block 40/45 version which replaced the 360's. They were talking about this move when I worked there 16 years ago.
In the mid-2000's, I hired a recent college grad who was in the US Navy. Her job in the Navy was to administrate a MS Exchange server on a ship. It was kind of mind blowing to learn that each ship had a full MS back-end stack.
Still do. You'll call someone and ask for their email "Well right now I'm ashore, but next week I'll be on ship, so you need to email me at john.doe@{$shipname}.navy.mil, I won't have access to my john.doe@navy.mil account."
I would argue that software written under government contract is inherently awful and unusable, because...
- It is driven entirely by formal requirements and specifications
- These requirements are approved by "the customer," which is a set of people completely independent from "the actual users."
- A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance.
- The developers often pat themselves on the back for meeting the requirements.
- The customer has to accept the software and foist it on the users, because it meets the requirements.
...and...
- The competition is entirely about who gets the contract to build the software, and not for which software is actually the best.
I suspect some form of X-prize approach would be worth trying - seed out a large number of small ISVs for government software (from license management to submarine firing systems).
Spend the money not in the requirements (which as you say are usually written by a non developer with minimal experience of the problem - after all if they were an expert they would have other more useful things to do) and spend the money on building automated test rigs.
I know I sound trite, and this is not even the best way (which is to organically grow solutions to problems), but we have a small window - software is eating everything and we will need to write the first generation of software that covers all politics and I damn well want that to be open to everyone to read. The software that runs governments will essentially be law. We should be free to read our laws
> - It is driven entirely by formal requirements and specifications
Can you explain why this is a bad thing? I've found that formal requirements and specifications are almost always good unless they're just vague (in which case: they're not really formal)
> - These requirements are approved by "the customer," which is a set of people completely independent from "the actual users."
Well, yes. That is indeed a problem.
> - A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance.
I've found that very very few people actively request people to say "your UI sucks". Instead, they want "constructive criticism" and/or "describe why it sucks!". Which, is sort've fair. But it gets to be extremely tiring to explain why the UX doesn't "just suck" but is fundamentally flawed.
> - The developers often pat themselves on the back for meeting the requirements.
Nothing wrong with that either.
> - The customer has to accept the software and foist it on the users, because it meets the requirements.
The customer has to accept the software because that's how contracts are done. But they don't have to foist it on the users. They just want to show that they've been able to deliver on their promise of a software solution.
> - The competition is entirely about who gets the contract to build the software, and not for which software is actually the best.
> - It is driven entirely by formal requirements and specifications
Can you explain why this is a bad thing? I've found that formal requirements and specifications are almost always good unless they're just vague (in which case: they're not really formal)
I have been in various projects for government and enterprises (non military, mostly medical and banking fields) with formal requirements and some without. I can say that those without always had better GUI and people using them liked it better.
I think that one major reason is that most people can't really imagine application without actually using it. Only once they are using it they can give you useful feedback (as in this is important, this isn't, make that action default etc.)
Another reason is that people that are not using it are writing requirements. For instance in a lot of medical applications, people who will write specs and requirements are Business managers or doctors (or both), but not radiology technicians and nurses that will actually use the software. So they have no idea of day to day workflow - just desired outcome.
So software will suck 100% if based only on their requirements (in my personal experience).
The problem is the lack of a feedback loop. Formal requirements will never accurately reflect what is actually needed unless there is a feedback loop that makes it possible to improve/update the formal requirements as problems/issues are discovered during development. Changing a single UI element requested by astronauts apparently takes a year for NASA and a day for SpaceX. Guess which software works best?
The biggest issue with software written under government contract, firm fixed price contracts. The way these are handled is not a good way to handle software. The winning contractor has a set of requirements for the software they have to deliver. If the customer wants to change anything, there has to be a bidding process and either a new contract or an add-on contract is awarded. This makes the customer very hesitant the make changes to the requirements even in the face of user feedback.
There is also no way to get user feedback until after the final software is delivered. It would have made life so much easier when I was a contractor if we could have had a group of users come in and see the software and make recommendations for the UI.
> ...There is also no way to get user feedback until after the final software is delivered.
That's what seems so very puzzling in these stories. These shortcomings in the delivered software appear more like insufficiently tested requirements (of course, the execution could be the sole reason too).
I'm not sure if contractors are needed in order to test the requirements against the actual use-cases _before_ even initiating a bidding process for developing any systems/software.
After all the force probably wants to describe what's needed. Someone has to make sure the desired new capabilities align with actual existing and desired workflows.
Perhaps, in this navsystem case, the ability to efficiently analyse/visualise the region's depth profile could have been stated in concrete use-case form, including the response times, scaling etc. This would then become the basis to test at the acceptance stage.
I definitely agree that not being able to capture "UI/UX shouldn't suck" in a formal requirement is a problem. Developers have to be vigilant, or get a lot of help from QA (typically the latter).
In my experience, though, there is a bit of a feedback loop during government test events since those are often staffed by real end users. If the end user doesn't like the software they can just say it failed the test, even if it did meet the requirements as written. So at least there's a bit of an upside there.
It would be nice if that feedback with the end user could occur earlier in the process though.
The thing about this is the best software stack I've ever worked on was for a government system, driving geointelligence ground processing for the NRO. It is still light years ahead of anything I've ever seen in the commercial world, but it's driving automated systems, so there is no UI. Anything I've ever worked on in the IC or DoD that had a UI pretty much universally had a terrible UI, and I agree the root of the problem is the absolute firewall between development teams and end users. Beyond that, though, individual acquisition offices often seem quite hostile to their own users and don't make any attempt to acquire software they'll actually like using.
So one of the fundamental design elements of a electronic chart display information system(Ecdis) or warfare Ecdis is the use of the safety depth contour.
Anything inside the blue area would cause alarming on a traditional Ecdis.
The bigger issue is the data that is used to navigate on, I could write a very boring blog detailing why th systems work so badly...
A bit off-topic, but maybe some experts could answer a question?
I've recently re-read Clancy's "Red Storm Rising", the sections on submarine (and anti-) warfare are really interesting (I understand some of it may be simplified/fictional). E.g., how the Mark 48 torpedo can be set to and launched in "hunting mode", where it circles at a slow, undetectable speed, and only after acquiring a target it suddenly accelerates for a kill.
Let's consider this excerpt from [1]:
Terminal Homing is the final stage of the torpedo attack. (...) Terminal homing is an active sonar ping that retransmits on reception becoming more rapid as the range to target closes at maximum speed. (...) The target is alerted to the attack, but there is nothing it can do to defeat the weapon at this point. The weapon is too close and moving too fast to allow time for a countermeasure to be effective.
Now, I might have read too much David Weber ([2]), but wouldn't a small, cheap-ish counter-torpedo suffice? Put 10-20 of them in small automated launchers all around the hull, and let them crash head-on with the (now perfectly detectable) approaching boat-killer, still at a safe distance (which is.. I don't know, 100-200 m?)
From what I've seen on naval ships you'd launch it to the side that is incoming so you'd be behind the wall of Chaff. I think that would be significantly harder to triangulate because you'd mostly just see the noisy stuff up front and your original target would be behind the wall of chaff.
Chaff is also designed to reflect signals all over the place so that it's difficult to get accurate results back. This would make triangulating near impossible (if it's working as intended)
But if the torpedo has pinged, the sub knows something's afoot, and it could quickly scan in that direction with its own active sonar (giving up your position be damned, we're under attack already) to guide its interceptors. Plus, the attack torpedo is now rushing ahead - and loud.
Sword and shield indeed; it seems the submarine tactics people must have a lot of fun playing with these scenarios.
Kind of a sword vs shield thing as most things in the military.
There are sonar decoys. They aren't easy.
You also have to have it rigged ready to go with very little notice.
The other aspect is that these torpedoes can still be wired to the ship so you can continue to use the host sub's arguably better passive sonar systems and let the attacking torpedo get VERY close.
As with all things in submersible conflict the first person to be heard is dead.
The other aspect of your decoy system that you might not be thinking about is that you've
a) compromised the hull with holes
b) you are going to make a LOT of noise firing those off
c) your sonar signature might go up dramatically when the doors are opened etc.
The hull actually has something similar to stealth coating (but for sonar, so easier to develop cuz it's against sound waves) on the hull. You really don't want to mess with it too much.
Sub warfare is insane. There isn't really a strong counter to them in the open ocean. USN Carrier groups are especially vulnerable (at least from exercises I've read about).
Your idea isn't bad. Just make it a towed array that pops off a bunch of really loud shit 1000m behind you or something.
This would eventually turn into a cat/mouse game of who can make a better system for detecting decoys vs fooling torpedoes.
If you read up on china's new hypersonic missile system you can get a feeling for why this shit is terrifying sometimes. Fractional Orbital Bombardment System is new and very scary for the USA missile defense systems. They effectively shrink the "we can see it range" down to a very small amount of time to respond. Combine that with MIRV warheads and decoys and it's a nightmare.
Ah, good point about the structural issue. But as for giving your position away, I meant it to be the last resort, when you're detected and under attack already.
> The other aspect is that these torpedoes can still be wired to the ship so you can continue to use the host sub's arguably better passive sonar systems and let the attacking torpedo get VERY close.
I don't know if there is any public data about how long the guidance wires are, but tens of kilometers seems like a pretty safe bet. Classic wire-guided TOW missiles have 3+ km of wire and are much smaller than a Mk-48 (about 6" diameter, vs 21")
>Fractional Orbital Bombardment System is new and very scary for the USA missile defense systems.
It's actually a fairly old technology as these things go, developed in the '60s and deprecated in the '80s. My understanding of HGWs that are currently being developed/fielded is that their potential FOBS aspect isn't what's scary--it's that they're more maneuverable than MARVs on traditional ballistic missiles and may be able to evade many currently fielded ABM systems.
236 comments
[ 4.1 ms ] story [ 261 ms ] threadNitpick, but isn't that a lot like saying "this magazine carries enough bullets to kill a whole platoon of soldiers"? I mean, it technically does, but only if they're all lined up in front of you and you never miss, which is almost certainly not true in real-world conditions.
> This failure to intervene is probably the most egregious shortcoming of VMS. But it's notoriously awful along other dimensions. Here's some of what I remember, mixed in with conversations with folks more recently onboard:
It seems like the military really ought to give the users of systems like this the ability to say "fuck no" and send it back after doing some user testing. Some of the issue identified are egregious and maybe the kind of thing that could get a submarine that's actually fighting sunk. I mean, it sounds like it's so bad it nearly got a submarine that was just cruising around sunk.
They aren't, but I'm sure there are operational complications to using them that make the analogy work (e.g. countermeasures).
I would say a missile is more similar to a torpedo. We can look to the Falklands as to how dangerous missiles are against ships. This isn't your grandfathers WWII torpedo.
There is only one other case of an anti-ship missile I can think of off hand, in Desert Storm when a Silkworm was shot at a fleet and shot down with a SeaRAM(?) I think.
I am surprised at the downvotes, but I guess also not. Either way, the information is out there. I agree with the article in that military software is generally awful, but I'm guessing it is not easy to innovate.
The point of the analogy is that the enemy platoon / nuclear submarine force would need be to be located and behave in a way that allowed a single shooter to wipe them all out almost simultaneously. This is particularly unlikely for submarines, especially nuclear-armed ones.
I took "nuclear sub" to mean "nuclear powered" (as opposed to e.g. diesel-electric, which are still fairly common), which I think represents a somewhat larger set of submarines, outside the US, than just the set of all non-US "boomer" (nuclear-armed) subs. That is, attack subs without nuke-tipped missiles can still be nuclear subs because they have a nuke plant onboard for power.
I'm trying to relay that it's exceedingly deadly submarine. The best in the world. The envy of all other submarine classes.
I don't think there are fighter aircraft that carry enough missiles to down an entire country's bomber force.
The Seawolf was made to destroy other ships. It has all the stats and capabilities to do it. But the kicker is it has incredibly bad navigation software.
Sloppier would've been: "The Connecticut alone could destroy any other nation's entire nuclear submarine force."
Basically the Navy wanted a monster that go deep behind Soviet lines and tear things up before they made it out of the backyard.
"[Seawolf's] emphasis on fast tactical search speeds and a massive torpedo magazine were reflections of its design mission, which was to independently search for and kill Soviet submarines in the relatively confined and target rich northern waters of the Soviet Arctic littoral." [1]
[1] https://digital-commons.usnwc.edu/cgi/viewcontent.cgi?articl...
> The Connecticut alone carries enough torpedoes to destroy any other nation's entire nuclear submarine force.
The Connecticut uniquely carries enough torpedoes to destroy...
vs.
The Connecticut carries enough torpedoes to single-handedly destroy...
i called it a forum because readers in the military-world may be less familiar with "issues" in github ;)
Also, if you have the computer checking everything, then those 5 people that are supposed to be redundantly computing the navigation plan are highly likely to be less diligent. Human nature and all. Isn't that likely to result in a worse outcome?
Well the lack of situational awareness with EFIS (glass cockpit) systems is a known issue. Pilots tend to 'switch off' because of the low workload and then when something goes wrong they're not aware of the situation because they haven't been following along.
This has contributed so some incidents such as the AF 447 crash where the pilots were basically unaware of the actual situation of the plane and flew it straight into the ground (well, sea).
I can understand the Navy wants its crews to be more involved for that reason (and perhaps also because the enemy might deliberately instill confusion by messing with navaids etc), but I think there should be at least a warning if you try to do something that's known to be stupid.
You're probably on to something. When radar was first rolled out to all Navy ships to assist navigation (post WWII), accident rates actually increased.
My hunch is that Sailors drove ships riskier thinking that radar would save them. A bit like the findings of seat-belt safety laws: no impact on fatalities.
But I'm not agitating for full-blown computer reviews. It just feels like the software should have the computing capabilities of Excel lol
Discipline works until time pressure causes discipline to relax, and then the loosened discipline becomes the norm (normalization of deviance). There is no reliable way to restore discipline (in a timely fashion) after that happens, and then a collision would become inevitable. If you only rely on discipline, you're bound to fail. If you have means of relieving the reliance on discipline and don't use them, you're making a tragic mistake.
I'm not sure I've even seen a situation in practice where an additional safety check made the situation worse. Those same people that shirk their duties and half-ass their job under the assumption the computer will just find the problems generally make a plethora of other mistakes if a computer isn't there to double check.
Computer verification of work, usually done by applying rules and heuristics, is useful and when done well, and roughly analogous to an additional human checker IMO. If policies and expectations are set right, it's a better outcome.
This may or may not follow for the initial calculation being done by computer and then checked by a human. Some of the competitiveness of people to make sure they do the job well and don't need fixes from a computer/human checker go right out the window and perhaps that does lead to complacency.
If they half-ass, but follow the computer fixes, maybe nobody knows they were half-assing. If they half-ass and other people fix it, their half-assing is known and remediations are available.
This is surprisingly easy to fix. If the computer notices before the human, call that a failure. Say, if the computer spots terrain higher than the current depth within X radius (that wasn't intentionally planned for), that's a failure.
I assume the military already has a regime in place to handle "you dun goofed". You can string failsafes after goofed but before the wall.
At least, that's what it looked like when I saw it in '98. It doesn't sound like it's gotten any better.
It's 10x worse now. Now there are half-a-dozen different browser-based apps that all do the same thing, and that's BEFORE you mention the AI data fusion initiatives people want to integrate.
VMS, however, was horrible a decade ago, and I'm not surprised it's still horrible. We used paper charts rather than VMS back then because it was so horrible.
I accept that people have to make the judgement calls and sign-off, but if the maps are in fact accurate why couldn't the computer at least issue a warning / red flag or similar when there are obvious problems (requested depth within some threshold of the actual depth).
I came across a scenario editor for a land training simulator that didn't provide any way of testing intervisibility between two points. The course authors wasted vast amounts of time when assigning vehicle positions clicking around maps to see if potential targets were in fact visible to the trainees. An auto check would have allowed the course authors to use their expertise to do things that couldn't be automated, building better scenarios faster.
I'm not gonna complain about it too much, but man oh man, I think you and I could build better software than what I saw, and I don't even know you from Adam.
The Air Force has an initiative called Kessel Run [1] to embrace agile software development — that might be your best route to building better software for the DoD. I'm not sure if other branches have similar programs.
https://breakingdefense.com/2021/10/not-going-solo-air-force...
Other responses have mentioned some routes inside... but beware... make the incumbents look bad too much and you'll be bought out and shut down.
Pride takes a seriously distant back seat to maintaining the current procurement monopolies and relationships, and maximizing contract payments for the least effort.
I'll stop there before I start to incriminate myself or get on watch lists if I mention possible solutions.
So that means you'd basically have to do business development first with an organization like NUWC Newport or NUWC Keyport (the undersea warfare centers who do submarine R&D) to drum up interest so that the government can issue an actual RFP or similar, and then you could bid to work on it.
I'll be the first to admit it's super difficult but if you're interested you might also consider talking with a local NavalX Tech Bridge (see https://www.secnav.navy.mil/agility/Pages/tech_bridge.aspx)
That would require the spec to have been written to allow that kind of rejection. I strongly suspect the spec was not written that well.
HN dunked all over that agile vs. waterfall article from a few days ago, wondering whether or not waterfall wasn't just some boogeyman that a bunch of consultants had to invent to sell certificates, but I'm here to tell you waterfall is a thing and it's still alive and kicking in the Navy, even now.
At the moment lots of maritime crew have alarm fatigue, the system constantly warns them of danger so they learn to ignore alarms and when something super serious does happen, they can ignore it
He was there because they were asking for software to help them sift through the cacophony of constantly-firing alarms which were distracting all their staff playing whack-a-mole "disable" and ruining situational awareness.
I imagine it's similar here. Do you want the sub to move up automatically? To fire an alarm? To dissalow a maneuver? Absolutely not. Imagine a crew knowingly pushing their vehicle into potentially dangerous maneuvers and spending those critical moments fighting the vehicle or disabling alarms.
This is how the "stick pusher" causes crashes on airplanes.
The fault lies with whomever commanded the maneuver, not with the ship for doing a minor mutiny to prevent it.
Now, as a counterpoint, see the f-16 auto-maneuver (I think this is a representative link): https://apps.dtic.mil/sti/pdfs/ADA583778.pdf
These kind of systems typically have manual overrides. If the operator truly believes they know best (or are in an exceptional situation that the automated system cannot account for), they can override the automated system (including many, if not most, safeguards). That's design 101 when you're building critical systems.
What this makes me think of:
> Why test software? It's a culture problem, not a technical problem. Just write correct software.
As long as no one ever makes a mistake it's a totally valid approach...
And nobody announces their creds up-front, making for some lively discussions.
For docking simulation to the space station, SpaceX has a website for controlling the Dragon capsule's UI. That could be the UI ergonomy baseline for measuring the current submarine's software against. The Orion and Starliner capsules have their own different more hardware oriented UI. I would expect nextgen submariners to be digital first native fast twitch glass screen navigators, but a submarine taking damage will be a splashy environment as seen in the movies and touch screens won't be as reliable as physical toggles with redundant bypasses etc.
Maybe "Fat Leonard" contributed to the contracting process that put this software on the suboptimal submarine without proper human factors consideration.
https://metallicman.com/uss-connecticut-black-operations-sub...
https://www.youtube.com/watch?v=VeJLwUfLcEU
No. You take the losses, put a brave face and spin a story about navigation error. Then if you think you weren't in the wrong and they need to get a lesson you destroy something of theirs a while later.
Btw, I'm not saying that's what's happened. I'm just hypothesizing that in case it happened like that they wouldn't start WW3 over it.
Firstly, they didn't blow it up. If the Chinese story is true, they surgically disabled it. Either way, no American blood was shed.
Secondly, the modus operandi of the contemporary Pentagon is walking a fine line between a) inflating foreign threats to secure Congressional funding and b) deflating any challenges to the perception of American military supremacy. Defending Americans from actual threats is a distant follower.
> It was then ignited, and ended up causing serious damage to the bow of the boat > and a complete loss of sonar sensing ability.
Surgically disabled by blowing it up.
It is not “the Chinese story”; were it the actual official Chinese story we wouldn't be getting it by this circuitous route, we’d get it from Chinese state media, both in Chinese for domestic consumption and English (etc.) for international consumption.
There are many criticisms you can make of the PRC, but “they are incapable of assuring that their official position is heard clearly and loudly” is...not among them.
What an incredible claim. Americans think China is literally committing a Holocaust right now. Chinese/Russian media is soft/hard censored on the biggest Western social platforms and official narratives from those governments almost never make it to American/Western ears without massive amounts of spin from Western state/corporate media.
Besides, there is a strong explanation for why Beijing didn't broadcast this: they don't want to inflame tensions, especially in the runup to the Olympics.
Yes, but they aren't exactly unaware that China's official position is that they are not, and the awareness of this official position doesn't come through random minor internet sites reporting “official” accounts machine translated after being received from anonymous friends who got release that were authorized by Beijing.
Getting the official story heard loudly and clearly and getting it believed are too very different goals.
> Besides, there is a strong explanation for why Beijing didn't broadcast this: they don't want to inflame tensions, especially in the runup to the Olympics.
Yes, that's a very plausible reason why, even if this highly improbable story were true, it wouldn't be China's official story right now.
It's not, however, even a remotely plausible reason why it would be the official story and simultaneously completely absent from official media and yet still authorized for release via the channel supposedly used here.
The "true" story is really only relevant to the military planners on both sides. And presently it doesn't serve either of their interests to broadcast it publicly.
I’m not.
The claim in the article which provided the story is that it is the “official Chinese story”. The article carefully avoids claiming that the story is true, though it obviously wants people to conclude that.
> Beijing is happy, officially, to accept Washington's story that they clumsily crashed into a rock.
Right. So the simplest claim in the article about the story—that it is China’s official story—is simply false.
> The "true" story is really only relevant to the military planners on both sides. And presently it doesn't serve either of their interests to broadcast it publicly.
Or, maybe the true story is what is officially broadcast, and the one with the obvious lie about the nature of the story is false beyond just that obvious lie?
> What an incredible claim. Americans think China is literally committing a Holocaust right now.
You have conflated "heard" with "believed". The CCP is heard, not believed. Everybody knows the CCP denies those claims; the CCP has been heard.
If you don't hide it, you will be forced to retaliate. Do you start WW3 for material damages because your public opinion's pride has been hurt?
The Biden admin is growing cold to both China and Russia. They just announced they won't support the 2022 Olympics.
Cyber warfare and espionage are reaching new peaks.
Russia just blew up a satellite, which caused NASA astronauts to take shelter. Target practice for fog of war.
China demonstrated their orbital hypersonics and glide platform, which is hard to track and defend against. Nuclear MAD that defeats US countermeasures.
Russia is amassing forces to take over Ukraine and Georgia.
China is increasing incursions over Taiwanese airspace.
China is delisting from US exchanges.
The US pulled out of Afghanistan, freeing up personnel and logistics. The best reason to do this was to prepare for a two front war. They could have otherwise remained deployed indefinitely.
Australia and Japan are buffing their navies and warfare capabilities substantially.
The US is in the awkward period between upgrading existing systems and designing next generation weapons.
We might really go to war in 2022 if China and Russia think they can take Ukraine and Taiwan. A hot war.
> The Biden admin is growing cold to both China and Russia.
Washington has been cold to both nations for the better part of a decade/century depending on your perspective.
> They just announced they won't support the 2022 Olympics.
False. Virtually all American athletes are attending. Whether the Biden admin is diplomatically boycotting or wasn't even invited is a matter of perspective.
> Cyber warfare and espionage are reaching new peaks.
> Russia just blew up a satellite, which caused NASA astronauts to take shelter. Target practice for fog of war.
> China demonstrated their orbital hypersonics and glide platform, which is hard to track and defend against. Nuclear MAD that defeats US countermeasures.
> Russia is amassing forces to take over Ukraine and Georgia.
> China is increasing incursions over Taiwanese airspace.
When a historically passive person starts acting assertively, an unscrupulous observer might judge it as aggression. Russia and China are demonstrating that Washington is no longer the undisputed military superpower it once was, that it can't bully anyone it wants. This has critical geopolitical implications but does not necessarily point to an inevitable war.
The fact is that USA has hundreds of overseas military bases while Russia and China combined have less than 10. Many of those American bases are on the doorstep of both competitors. Until China is parking carriers in the Gulf of Mexico, it hasn't even begun to reciprocate American military assertiveness/aggression.
> China is delisting from US exchanges.
...and relisting on e.g. HKEX which is historically accessible to international investors from America and elsewhere. More likely, Chinese companies are hedging against the collapse of Wall St. (if the Fed raises rates) or the USD (if they don't).
> The US is in the awkward period between upgrading existing systems and designing next generation weapons.
Like the F35? Pretty sure that failure has nothing to do with "bad timing" and everything to do with the corrupt state of Washington and the Pentagon.
> We might really go to war in 2022 if China and Russia think they can take Ukraine and Taiwan. A hot war.
Why, though? Whose interests does it really serve?
> Like the F35? Pretty sure that failure has nothing to do with "bad timing" and everything to do with the corrupt state of Washington and the Pentagon.
IIRC this concern is mainly about attack sub capabilities, and the US navy will in fact enter a period of exceptionally poor preparedness for operating in the waters around Taiwan in the event that war breaks out, for a few years between about 2025 and 2030. This is due to procurement decisions made years and years ago, since there's huge lead-time on building new ships.
Whether this actually means anything—I don't know.
>Why, though? Whose interests does it really serve?
Not sure about Ukraine, but if Xi's perceived legitimacy falls further then he could invade Taiwan (and risk huge domestic backlash) as a gambit to hold onto power.
Don't forget that the CCP's raison d'etre is not to responsibly govern China but simply to accrue power. If that means sending 3 million Chinese youth into the Taiwan meat grinder, then that's a price he's willing to pay.
(I think a lot of people that don't keep up with Chinese news and politics are quite dismissive of both the public and the China watchers' fear of Xi, and I think a big part of this dismissal comes from trash-tier organisations like Sky News constantly publishing dumb "China Bad" pieces.
When you listen to the people on the ground, though, and see all kinds of major precedents being broken daily, it's clear that something profoundly unsettling is going on under Xi's leadership.)
Yeah, for the corrupt politicians in Washington and Canberra.
Shit's changed, man.
So please share them, or rebut others' posts. Maybe inject a bit of humour into it to lighten the mood somewhat.
The "smart" quips you're posting are just annoying, though.
China is a real place with real people, not one of your Marvel comic book settings.
It is not China’s official position, which is why this supposed “official story” is not sourced to any official Chinese media, but to an email, supposedly sent by the author’s anonymous friend, that contains information that was supposedly authorized by Beijing on the “official Chinese story” which nevertheless the PRC has not released through any of its many state controlled media outlets.
(It plausibly could have been authorized by Beijing for this exact use: divisive propaganda through multiple steps of deniable cutouts that has nothing to do with either the facts or China’s official public position. Or it could just be an invention of the author, or the author’s anonymous, unaccountable friend.)
Uhuh. Right there, a highly trustworthy source.
Nb I’m talking about countries as if they were people, I do not mean that people in these countries are thinking these things.
I was going to say, that there probably a few dozen people that use submarine nav software, so it's hard to get a representative sample of usability...but then it occurred to me that airplane software has a fairly limited audience too.
What's the process for test for developing aircraft software? How is nav done in aircraft? Theoretically they have the same issues (like hitting the ground).
[0]: https://arstechnica.com/information-technology/2017/11/uss-m...
From Wikipedia:
Los Angeles class submarines built: 62, entering service 1976.
Abus A350s built: 443, entering service 2015.
* Prevent groundings (loss of a $3B platform, 120+ lives in worst case) * Do their missions better (increase the value of the platform)
I've been in many a design meeting where a "must have" was pushed out to the next version because "the user can just do this manually for now".
The Navy as a whole has a severe manpower shortage, and in the incident report for the McCain collision I believe it came out that the officer on duty was 17 hours into their watch, and didn't have a full compliment in the watch house because one of the crew who was supposed to be there was off in the lower decks for an unstated purpose (anecdotal evidence from my Navy friends, probably catching up on sleep, or seconded to repair something while they had "non-critical" time).
The collision only happened because instead of being trained on seamanship as a whole, incoming officers are trained how to work the computer systems they're interfacing with. The Navy cut down the training periods as well - instead of training under a senior officer for a few months, to offset manpower shortages, incoming officers are put in charge immediately, and given a stack of CDs (wish I was kidding) to complete their training.
The surface Navy is in an incredibly dysfunctional place right now, and Congress/the admiralty have been paperig over leadership failures by spending more money, and blaming technology
That's happened more than once. NYC ferryboat allision.[1] It's another case of touchscreen mania. With ship controls, it's common to have more than one control station for basic helm and throttle. When docking, it's common to drive from a control station where you can see the dock. So which station has control is an issue. Some systems have physical feedback, so that the wheel and throttles at all stations move together. That avoids mode confusion.
Aircraft people get this, but few others seem to.
[1] https://www.workboat.com/passenger-vessels/seastreak-ferry-a...
TCAS (the family of systems aircraft use to avoid hitting other aircraft) is much simpler and doesn't rely as heavily on GPS/INS data, but generally only gives data on cooperative aircraft transmitting transponder or ADS-B data. A very simple version gives a traffic alert when another aircraft approaches within a specified distance of you, but may not give any other useful information (relative altitude/position, heading, etc.), and the most basic version I can think of just gives a range to a single cooperative aircraft.
I think you'll find that you're off by a few orders of magnitude on the number of submarine navigators out there, and there are few enough certified avionics systems that most are used by a substantial enough audience (and, more importantly, mandated by enough national aviation authorities) to be worth the R&D effort.
That said, military hardware is often decades behind the civilian world when it comes to many of these mandated safety features, so I don't find it surprising that military ships (often with proprietary radar and sonar systems designed primarily for combat, and not wanting to broadcast their location to potential adversaries) don't have good integration with commercial collision avoidance software designed to work in a collaborative environment with off-the-shelf hardware that may have only been installed as an afterthought, if at all.
I'm also surprised there's no contour lines between the depths (although perhaps this is done to not infer a knowledge of depths in the intermediate points where perhaps there is no such knowledge).
I suppose they do what we do in our factories at work. Airgapping and extremely strict firewalling where any access is needed.
Yes, contour lines would imply accuracy that isn't there. The depth numbers indicate positions where the depth was actually measured. Any other location that doesn't have a number was not measured. Bear in mind that even if you have a depth number on your chart, it might be old and out of date. Safe navigation is never guaranteed. And subs never run depth-finder sonar when on patrol.
Sedimentation?
Underwater volcano eruption?
Continental drift?
Shipping channels and shallows need to be resurveyed constantly or you have no idea what you might encounter.
NOAA's Chart No. 1 explains the symbols used on charts.
https://www.nauticalcharts.noaa.gov/publications/docs/us-cha...
If subs were companies, competition would solve this problem. Some enterprising engineer says to herself "I can build a better VMS" and does. Since it's 10x better than the existing VMS, some submarine crews adopt it, and pretty soon it's in widespread use across the fleet. Engineer profits, sub crews are more effective and probably it's cheaper too.
But it's the government, even worse it's defense. So regulations and secrecy (some reasonable, some not) muddy the waters until everyone's blind, including apparently the VMS.
My phone can do "safety-of-ship" alerting? I'm the first to shit on defense software, it's my background, but map software for a submarine is safety-critical. While submerged it's basically their eyes. It has to be more reliable and trustworthy than possibly any other map software. Not only this but navigation information would have to be fused together from GPS as well as INS (inertial nav).
My 2 cents. Background in defense but not submarines.
As they moved away from embedded to more networked and newer tech stacks things got terrible. The software world of today is not compatible with the needs of the defense industry.
Plus all the red tape and misdirection. The software need comes from an organizational budget that has to use money to justify receiving money. Then it funnels down into political buckets, who use the dollar amount given to determine needs/wants. Then it goes back up the chain to the government. Then to a contractor, then a flurry of subcontractors. Then finally a developer. Rarely is the warfighter who will actually use the system consulted. Even then, rarely will the programmer meet that person using the software.
Yet they all call themselves "agile" now.
But it's flabbergasting just how bad VMS is considering it's the navigation system for these national assets. It's not like an HR system with poor UX--navigation is essential to the safety and effectiveness of the whole platform!
It's because the people making decisions care about putting money where it earns the most return and have more on their plate than they can address. Making software more pleasant for internal users rarely makes it to the top of the list.
> navigation is essential to the safety and effectiveness of the whole platform!
Subs crash very rarely, so the software seems to be sufficient.
Subs also operated for many decades without any kind of computer-assisted navigation, and training to handle the loss of such systems is routine, so your statement is pretty vacuous. The software at a minimum should allow sailors to operate as safely as they did without it, but one would assume that the entire point of software assistance is to improve safety and/or operational effectiveness.
Fucking bad from what I've read. It's a really bad problem still and the USN needs to correct it by having a tighter integration with the HW/SW people and the actual soldiers/sailors.
How fast could we develop? In addition to the requirements, we were also handed a schedule (a PERT chart, if anyone still knows what that is). It was laughably padded. Padded so much that it would have been impossible to fall behind schedule. I almost always finished my work for the day before lunch. Sometimes I would then go for a three martini lunch with the sales guys, or spend the afternoon in the library or flying the F-14 simulator. Sometimes I would spend the afternoon working on tools to make debugging easier. It was a fun job, but ultimately unsatisfying and I left after two years.
I can't believe that after all this time, it's still completely borked, in all the same ways.
Somebody at NAVSEA needs to be dragged by their nostrils out on a deployment, take notes, and go back to their office with their pride in a garbage bag.
Proud as hell to have served, and angry as hell that our current crews are still dealing with the same ---procurement--- failures.
Work with the actual user/operators (this I did see a lot of, but not on new systems, only on systems in "maintenance") to get regular feedback. One of the best jobs of this I saw brought in both current and retired operators. Current ones rotated through helping evaluate the system and the requirements, retired ones were hired on to be part of test/QA.
Switch from fixed contracts to more level of effort contracts.
Generally shift towards continuous delivery where possible (with information systems much easier than with embedded systems, but doable to an extent with embedded systems).
Fix the official release test phase which is often 6-24 months at the end, most of it waiting. This is part of the program's overall process which is very Waterfall in structure for most systems. I've seen work that was completed and put on a shelf for over a year before being evaluated for flight readiness. Well, it was useless to operators by that point [0] and delayed vital feedback for the next iteration. That's partly a logistics problem, but addressable.
Fix the lack of trust the operational test teams have for development teams. There was a complete lack of trust for the teams delivering the product to be tested, but the test plans for flight testing were often so bad that they were a joke (for the particular delivered systems, not flight test plans in general). If you don't have the trust, gain the trust. Take the existing operational test plans and back port them to your own test infrastructure and test efforts. Deliver that report along with the product, eventually they may trust your test reports and can start speeding things along.
As with all software, get as much testing done as early as you can. The longer you wait, the more costly it is to address discovered issues, particularly validation issues.
Finally, get experienced software engineers into program offices. Most of the time their "software engineers" are a recent college graduate, or someone from a totally unrelated field that wrote some Matlab code once. They lack sufficient experience to properly manage or guide the management of the software portion of a project. The worst I saw with this was that system I mentioned in my previous comment, the program office lead for the software portion was a newly pinned on 1st LT history major. Zero technical experience (had been in some finance role before), they trusted the contractors too much and made decisions more on their input than anyone actually using the system.
[0] For context, this is software that spent 2-4 years being developed and then would be shelved for 1-2 years before being tested. Which meant it still had 1-2 years for fielding. So from conception to release you're talking 4-8 years. That is an awful pace.
Fortunately all the projects I have worked on aren't related to combat or anything where actual people could be hurt.
It's hard to redundantly guarantee correctness, if you wanted to rely on VMS to avoid hitting the seafloor that would indeed be difficult. But come on, how hard is it to offer a highlight for the shallowest points near your course, or a warning that says "you added an extra zero here"?
Google's servers have this information, compiled in real time from countless sources including direct satellite cartography and all beamed to a phone acting as little more than a user interface. Take your phone a few hundred feet below the water where it is cut off from the outside world and even the best maps in the world aren't accurate and you're going to run into a lot of things.
For a submarine, you need to know the topography of the sea floor down to meter scales. Accurate maps are few and far between, and difficult to create. Changing currents, underwater landslides, silt from rivers, sunken wreckage and even just garbage can create and move obstacles large enough for a submarine to care about in relatively short timeframes. Of course submarines can and do navigate with maps prepared ahead of time, but it's tough, and every now and then you get a run in with a sea mount.
Even if the data set is huge, you should be able to fit the system and a redundant system in a full rack. When I was on a surface ship, our entire nav system fit on a single server with an additional server as a backup. Our system could be updated live because we had internet on board. Subs don’t have this luxury so they would need the full dataset on board.
You can actually operate Google maps with no internet connection: https://support.google.com/maps/answer/6291838?hl=en&co=GENI...
This will not have the same feature set but the UI will let you know that this is operating with reduced data. Route planning is still very good offline. I had to use this feature because for some time part of my route home had no cell signal.
It is GPS.
Also, "GPS" in the United States colloquially refers what people in the UK would call "sat-nav" not to the satellites + protocol (what it actually means on paper).
Maybe? When hiking it makes some sense to forego GPS to save battery power. I didn't consider that possibility when I commented earlier, but in my defense the context of the comment is using maps without an internet connection.
> Also, "GPS" in the United States colloquially refers what people in the UK would call "sat-nav"
Sure, but sat-nav doesn't require internet service...
If I had to guess, these conflations of cell service with GPS are a product of misleading UX created by Google. OSMAnd makes the nature of GPS clear, displaying a count of satellites it's managed to hear. Enough satellites to get a location good enough for car navigation almost always takes less than a minute.
Couple that with point clouds of the sea floor, manual input from humans, etc, you can do quite well.
Couple this with the lack of good maps of certain sections of the sea floor, and human error, and a collision every couple of years becomes probable.
No one, least of all a qualified submarine officer, is proposing that VMS should somehow get a real-time feed of oceanographic surveys while deployed on active operations.
I read the article, and I agree VMS could likely be better, but the map apps on your phone are not examples of navigation systems that have fixed VMS' problems.
The author is suggesting to implement what VMS is meant to do with an application with the same level of usability, reliability and performance as what was put into Google Maps, and Apple Maps, or frankly any reasonably-popular mobile app that doesn't involve gaming.
Do not confuse VMS with a turn-by-turn navigation system, that isn't what it does, or what an actually-usable replacement would have to do. VMS is meant to help plan a voyage and ensure you're safely executing to that plan in transit, and it doesn't do a good job of that for all the reasons the author provided.
But the best part? Seeing all the other users of maps along the route! Barely enough room for two cars to pass. But we had each other. Everyone would hold up their iPhone and mouth “WTF?” with wide eyes.
https://features.propublica.org/navy-uss-mccain-crash/navy-i...
> Bordeaux felt confident using the system to control the speed and heading of the ship. But there were many things he did not understand about the array of dials, arrows and data that filled the touch screen.
> “There was actually a lot of functions on there that I had no clue what on earth they did,” Bordeaux said of the system.
As for his boss:
> The chief petty officer had himself received less than an hour of instruction.
That's the guy in charge of training the bridge staff. Nobody knew how to use the system.
Yes. Never controlled a drone from your phone?
The fact you've worked defence and can't see how consumer devices do things submarines can't is the issue.
We all know a submarine is worth x billion, a drone much less. We understand about critical failure on each.
You job is to work out how to merge the two, but instead defence hides behind ideas like verifying software. Software verification should be a tool, not a wall for bureaucrats to hide behind.
Did you read the detailed examples on the website? Because the point you make is the same point the website makes: VMS is crap, compared to the map application that comes with your phone by default.
It is less reliable, because it crashes all the time.
It is less trustworthy, because you can't even rely on it to do extremely basic checks on the safety of a proposed leg of your navigation plan.
I find the website disappointing for a different reason: the flaws they point out in VMS in 2021 are the same flaws I experienced with VMS from 2006 to 2009 during my own time in submarines. I should be astonished that we haven't made things better since, but I've seen enough of software in defense to honestly claim surprise.
I'm currently working on ship-alerting software, and all the usual "haha programmers suck at their job" memes apply... But then, so does the hardware it's running on. PLC/SCADA hardware that behaves unpredictably with zero support from the (global monopoly) vendor and PC's that are years out of date because getting new hardware approved is fucking torture.
Currently there are 67 submarines actively part of the battle fleet (https://www.nvr.navy.mil/NVRSHIPS/FLEETSIZE.HTML), let's say $3B per submarine, that's $200 *BILLION* dollars of capital expenditure. And it should go without saying that the reason we spend money on submarines is because the missions they go on are that important to the national defense.
I think Google has spent less than $200 billion on Google Maps.
Between the capital expense and the mission to perform, and the repeated underground collisions, I don't think it's too much to ask that the Navy apply some usability design to support one of the most critical functions of any warship, safe navigation.
Because I've used VMS myself and I can attest to everything the author of this article mentions, and it's far from being just a resourcing question: it's inherent to the way the Navy designs, implements and acquires software-based systems. This includes the stuff you mention about hardware (which, oddly, the Navy submarine force had managed to subvert with ARCI sonars, which use commercial servers and a ton of additional spares to meet operational availability needs).
Yes. It's a very similar problem to aviation terrain avoidance systems which are now so common, and such a "solved problem", that numerous popular smartphone apps for flying and gliding feature not only terrain warning but features like "will I be able to make it to that airport" determination (for gliders) which factors in a slew of real-time parameters and terrain data.
And, really, "is the plane going to hit terrain the way it's being flown right now?" is far more complex than the problem the author was describing, which "is what you're planning to do going to hit terrain." They commanded a dive to a depth below the ocean floor, and it wasn't like they were trying to run a canyon like Hunt For the Red October...from the sounds of it, nothing in the area was deep enough to permit that dive to happen safely.
This problem is also a problem the PC/console game development community solved, oh, around two decades ago. For quite some time games have simulated bullet physics while also determining if a shot hits a moving, deforming, 3d object, with checks happening in a matter of ~10ms or thereabouts. "Will the submarine pass within X feet of underwater terrain" is a walk in the park.
There's also the matter of the system not needing to assure a maneuver is safe, but merely to serve as an alert when something is obviously not safe. Given how much these things cost, as you point out, I'd say such a system is beyond warranted.
> Not only this but navigation information would have to be fused together from GPS as well as INS (inertial nav).
I'm going to guess that the Navy has figured out how to very precisely geolocate their submarines and has beyond-excellent seafloor map data.
What sort of "server farm" does a modern submarine have?
Do they need to be super hardened operation in a vehicle that may be called to launch its missiles in a high radiation zone?
In a worst-case scenario the sub my surface in the middle of or end of a nuclear war. They probably want to ensure that the missiles get underway even in such extreme conditions
but those are crazy stats! what would you suggest for newbies like me?
- It is driven entirely by formal requirements and specifications
- These requirements are approved by "the customer," which is a set of people completely independent from "the actual users."
- A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance.
- The developers often pat themselves on the back for meeting the requirements.
- The customer has to accept the software and foist it on the users, because it meets the requirements.
...and...
- The competition is entirely about who gets the contract to build the software, and not for which software is actually the best.
I suspect some form of X-prize approach would be worth trying - seed out a large number of small ISVs for government software (from license management to submarine firing systems).
Spend the money not in the requirements (which as you say are usually written by a non developer with minimal experience of the problem - after all if they were an expert they would have other more useful things to do) and spend the money on building automated test rigs.
I know I sound trite, and this is not even the best way (which is to organically grow solutions to problems), but we have a small window - software is eating everything and we will need to write the first generation of software that covers all politics and I damn well want that to be open to everyone to read. The software that runs governments will essentially be law. We should be free to read our laws
Can you explain why this is a bad thing? I've found that formal requirements and specifications are almost always good unless they're just vague (in which case: they're not really formal)
> - These requirements are approved by "the customer," which is a set of people completely independent from "the actual users."
Well, yes. That is indeed a problem.
> - A requirements document cannot easily capture "the UI/UX doesn't suck," because that sort of thing often tends to be more subjective or not well thought out in advance.
I've found that very very few people actively request people to say "your UI sucks". Instead, they want "constructive criticism" and/or "describe why it sucks!". Which, is sort've fair. But it gets to be extremely tiring to explain why the UX doesn't "just suck" but is fundamentally flawed.
> - The developers often pat themselves on the back for meeting the requirements.
Nothing wrong with that either.
> - The customer has to accept the software and foist it on the users, because it meets the requirements.
The customer has to accept the software because that's how contracts are done. But they don't have to foist it on the users. They just want to show that they've been able to deliver on their promise of a software solution.
> - The competition is entirely about who gets the contract to build the software, and not for which software is actually the best.
Well that's quite a problem.
I have been in various projects for government and enterprises (non military, mostly medical and banking fields) with formal requirements and some without. I can say that those without always had better GUI and people using them liked it better. I think that one major reason is that most people can't really imagine application without actually using it. Only once they are using it they can give you useful feedback (as in this is important, this isn't, make that action default etc.)
Another reason is that people that are not using it are writing requirements. For instance in a lot of medical applications, people who will write specs and requirements are Business managers or doctors (or both), but not radiology technicians and nurses that will actually use the software. So they have no idea of day to day workflow - just desired outcome. So software will suck 100% if based only on their requirements (in my personal experience).
There is also no way to get user feedback until after the final software is delivered. It would have made life so much easier when I was a contractor if we could have had a group of users come in and see the software and make recommendations for the UI.
That's what seems so very puzzling in these stories. These shortcomings in the delivered software appear more like insufficiently tested requirements (of course, the execution could be the sole reason too).
I'm not sure if contractors are needed in order to test the requirements against the actual use-cases _before_ even initiating a bidding process for developing any systems/software.
After all the force probably wants to describe what's needed. Someone has to make sure the desired new capabilities align with actual existing and desired workflows.
Perhaps, in this navsystem case, the ability to efficiently analyse/visualise the region's depth profile could have been stated in concrete use-case form, including the response times, scaling etc. This would then become the basis to test at the acceptance stage.
In my experience, though, there is a bit of a feedback loop during government test events since those are often staffed by real end users. If the end user doesn't like the software they can just say it failed the test, even if it did meet the requirements as written. So at least there's a bit of an upside there.
It would be nice if that feedback with the end user could occur earlier in the process though.
Many people have tried to fix that problem, few succeed.
I guess our industry is still ripe for disruption. Should someone figure out how make quality software cheap :)
Anything inside the blue area would cause alarming on a traditional Ecdis.
The bigger issue is the data that is used to navigate on, I could write a very boring blog detailing why th systems work so badly...
I've recently re-read Clancy's "Red Storm Rising", the sections on submarine (and anti-) warfare are really interesting (I understand some of it may be simplified/fictional). E.g., how the Mark 48 torpedo can be set to and launched in "hunting mode", where it circles at a slow, undetectable speed, and only after acquiring a target it suddenly accelerates for a kill.
Let's consider this excerpt from [1]:
Terminal Homing is the final stage of the torpedo attack. (...) Terminal homing is an active sonar ping that retransmits on reception becoming more rapid as the range to target closes at maximum speed. (...) The target is alerted to the attack, but there is nothing it can do to defeat the weapon at this point. The weapon is too close and moving too fast to allow time for a countermeasure to be effective.
Now, I might have read too much David Weber ([2]), but wouldn't a small, cheap-ish counter-torpedo suffice? Put 10-20 of them in small automated launchers all around the hull, and let them crash head-on with the (now perfectly detectable) approaching boat-killer, still at a safe distance (which is.. I don't know, 100-200 m?)
[1] https://www.thedrive.com/the-war-zone/33018/modern-submarine...
[2] https://en.wikipedia.org/wiki/Honorverse
https://www.defensenews.com/global/europe/2019/04/16/navies-...
I wonder if you could triangulate the launch point though.
[0]: https://en.wikipedia.org/wiki/Chaff_(countermeasure)
Chaff is also designed to reflect signals all over the place so that it's difficult to get accurate results back. This would make triangulating near impossible (if it's working as intended)
At that point, it already has enough information to get right up in the enemy's face.
Sword and shield indeed; it seems the submarine tactics people must have a lot of fun playing with these scenarios.
There are sonar decoys. They aren't easy.
You also have to have it rigged ready to go with very little notice.
The other aspect is that these torpedoes can still be wired to the ship so you can continue to use the host sub's arguably better passive sonar systems and let the attacking torpedo get VERY close.
As with all things in submersible conflict the first person to be heard is dead.
The other aspect of your decoy system that you might not be thinking about is that you've a) compromised the hull with holes b) you are going to make a LOT of noise firing those off c) your sonar signature might go up dramatically when the doors are opened etc.
The hull actually has something similar to stealth coating (but for sonar, so easier to develop cuz it's against sound waves) on the hull. You really don't want to mess with it too much.
Sub warfare is insane. There isn't really a strong counter to them in the open ocean. USN Carrier groups are especially vulnerable (at least from exercises I've read about).
Your idea isn't bad. Just make it a towed array that pops off a bunch of really loud shit 1000m behind you or something.
This would eventually turn into a cat/mouse game of who can make a better system for detecting decoys vs fooling torpedoes.
If you read up on china's new hypersonic missile system you can get a feeling for why this shit is terrifying sometimes. Fractional Orbital Bombardment System is new and very scary for the USA missile defense systems. They effectively shrink the "we can see it range" down to a very small amount of time to respond. Combine that with MIRV warheads and decoys and it's a nightmare.
I don't know if there is any public data about how long the guidance wires are, but tens of kilometers seems like a pretty safe bet. Classic wire-guided TOW missiles have 3+ km of wire and are much smaller than a Mk-48 (about 6" diameter, vs 21")
It's actually a fairly old technology as these things go, developed in the '60s and deprecated in the '80s. My understanding of HGWs that are currently being developed/fielded is that their potential FOBS aspect isn't what's scary--it's that they're more maneuverable than MARVs on traditional ballistic missiles and may be able to evade many currently fielded ABM systems.
That said, submarine warfare is indeed insane.