A submarine's weakness: its software?
fixvms.com
fixvms.com
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.
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
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.
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.
- 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.
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...
https://www.defensenews.com/global/europe/2019/04/16/navies-...
I wonder if you could triangulate the launch point though.
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.
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.
Having said all that, the author is placing way too much blame on the technology. It should be an aid and much less of an impediment, but there is no chance that the crew was operating correctly.
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.
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...
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 called it a forum because readers in the military-world may be less familiar with "issues" in github ;)
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...
I remember that the NAVSEA rules were that you had to recover from a crash in less than 30 secs. The NAWCTSD rules under Ahlers were that you were not allowed to crash.
Big contractors with big budgets ruled the roost and delivered poor results. I wish that the NAWCTSD "More with less" ideas had lasted.
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
GPS is not as good as most people think. Especially in Southern Hemisphere. It makes interesting reading.
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.
but those are crazy stats! what would you suggest for newbies like me?
https://metallicman.com/uss-connecticut-black-operations-sub...
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.
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.