Why the U.S. Navy's new $362M ship broke down
businessinsider.com
businessinsider.com
It might have redundant systems, but if the same manufacturing fault existed in both then that doesn't really help you much. That's why there is something to be said from taking secondary components from different manufacturing runs or even entirely different manufacturers, so that failures aren't synchronized.
As an aside: Are ship engines not tested externally before installation into the hull?
https://news.ycombinator.com/item?id=6639097
Relevant portion applicable to your comment:
"The computer control systems were dual, meaning two independent computer boards. The boards were designed independently, had different CPU architectures on board, were programmed in different languages, were developed by different teams, the algorithms used were different, and a third group would check that there was no inadvertent similarity."
I realize that the liability fear of failure in commercial aircraft (or perhaps regulatory oversight) is probably a strong motivator, but you'd think that combat systems might be equally well-motivated toward redundancy given the nature of their purpose...
If this were to occur during a critical mission, they could continue, but at the cost of further damage and a lengthy dry dock afterwards.
This was probably caused by misalignment or a piece of debris (which would cause damage and thus create more debris) left in the system during the installation process, not by something inherently wrong with the design.
The Navy statement in the gCaptain article mentions locking the port shaft, so this not a problem with an engine (which can be decoupled from the shaft by a clutch).
[0] http://gcaptain.com/u-s-navys-new-lcs-towed-to-port-after-br...
(I'm a licensed marine engineer, now working in a different industry.)
A ship I was on had its shafts pulled during a dry dock evolution. When we went out to sea, we discovered that one of the shafts was off-center and moving the line shaft bearing around causing cracks in its foundation. We had to lock that shaft in place and continue underway on just the other shaft.
Having to lock the shaft in place isn't a normal occurance, but it is a contingency that is prepared for.
Reporting of a complete loss of propulsion [..] is
deeply alarming, particularly given this ship was
commissioned just 20 days ago
Or is the engine made from aluminum?
Also, you don't just turn this kind of thing off while you change the oil so a drain plug isn't a realistic option.
That said, this debris was probably more substantial than shavings.
Having a brand new model of a ship break down during an exercise is the 'best case' scenario for failure. There are important aspects of this that should be taken into account. First, nobody died. Second, the fault didn't occur during combat.
Yes, there are some projects that waste insane amounts of funding with underwhelming results like the Army's 5 billion UCP (Universal Camouflage Pattern) and Air Force's F35 programs. Cases like those usually occur due to personality-driven leadership.
Imagine you have an officer with a lifetime of domain-specific knowledge but little/no experience with product development. Give him an objective, a line of funding, and the responsibility to draft a contract to make it happen. This is the usual case.
Things can go south for a few reasons. The officers in charge don't reach out for outside feedback/advice, and default to relying solely on the advice of the contractors. Poor assumptions are made or requirements are overlooked, delaying production. The procurement process takes such a ridiculously amount of time that COTS equipment goes obsolete and/or can't be sourced by the time it's required for implementation.
To make matters worse, contracting guidelines dictate that projects follow a waterfall design model. The specification process all happens up-front. Lots of bureaucracy, lots of documentation, lots of steps where mistakes and bad assumptions can/will be made on a tight time schedule. There are exceptions to the rule but generally field testing doesn't take place until after launch.
People wonder why the military spends billions of dollars training and 'playing war' every year. They do it to iron out the kinks in their equipment, organization, and processes. If the services do their job (which most do very well) they will identify, report, and correct problems before they're put to the test in a wartime environment.
In software development terms, prototype with a waterfall and iterate over time. The difference being, on software projects iterations happen on the scale of weeks/months. On military projects, iterations happen on a scale of years (ex 3 or 5).
The news will jump on any sign of weakness chanting 'muh taxpayer dollars'; oldschool politicians like McCain will sponge up the public attention calling for 'the good old days of big iron' (aka sitting ducks); and, none of that matters because war changes and the tools of war need to adapt to overcome those changes.
All I can say is, I respect the fortitude of the service members who do this type of work. It's truly a miserable, thankless job, fraught with unbelievable obstacles and little support.
Source: I used to work on a contract under MARCORSYSCOM, which is basically the product development division of the US Marines.