There are pros and cons to the proposed centralised system, but I'm not convinced that it is a good idea on a warship.
Pros:
- Easy upgrades and is easily scalable. As processing power increases or increased power is desired, it is a matter of adding additional processing unit to the rack or replacing units with new technology. Likewise, the software being run is more easily upgraded to a new version. While it is easy to concentrate on the processing power of the blade servers, electrical and I/O connections are more difficult to upgrade later.
- More reliable. If you have redundant processing units (or even whole racks), utilisation can be switched instantly in the event of failure. Hopefully users won't even notice an interruption.
- Easier maintenance. At sea, a faulty unit could be disconnected and the workload redistributed and the unit replaced easily and quickly in port. The virtualized system is easily monitored for failures.
- Clients (operator consoles) can be generic or flexible, meaning the functionality of the console can change according to operational, upgrade or maintenance requirements.
- Data processing can produce lots of heat, and having all this heat produced at a single location makes it easier to manage.
Cons:
- It will be surprisingly complex to develop and implement, and it will require careful supervision and management in service. Don't think that it will be a matter of flipping a switch on/off, because with data constantly in motion and loads changing from moment to moment, it is a dynamic system that will change.
- Because it is shared system it will require careful communication and co-ordination across all users, departments and disciplines to avoid software or resource conflicts.
- It is a single point of failure. The failure not only could be physical (power and data connections, combat damage, operator error) but virtual (bugs, software clashes, operator error, security breaches) as well. If the central server goes down, you'll be left with nothing. No sensors, no weapons, no data links and probably only local communications. All situational information gathered is no longer available and can no longer be displayed.
- Do you also virtualize other control systems? What about engineering or environmental systems? Navigation? What happens if these go down as well?
- It is a single point of failure. This is such a crucial point I think it deserves a second entry.
The fact that it isn't likely to fail totally because of system redundancies, doesn't mean it can't/won't. A search will show plenty of examples of bank systems breaking down.
I would also be careful of holding banks up as a good example. You'd be surprised at how hacked together their systems are, given the amount of legacy/ancient software and processes that have to be accommodated!
I'd be wary of tying in the failures of the banking *software* to the problems posed by a warship - that's not even oranges and apples, it's *eggs* and apples.
The thing that they're getting from the hardware is (from what I can see) is the very resilient and failure tolerant nature of the servers used in banking and share dealing. By virtualising large chunks of system features and running it off a blade chassis, you can very easily (and if you wish, automatically) load balance. Run it on VM ware and you can drag and drop a running application from one blade to another while it's still processing real time requests.
The servers themselves are self contained packaged units that can be configured to automatically build themselves as a particular type of server if inserted in a particular slot, meaning that even the delivery guy from FedEx could effectively replace and begin building a new server. That means if you get a hardware failure which would otherwise take hours to fix, the application that was running on it can fail over to a completely new node and the only hint the users get is when someone walks past them with an antistatic bag with a new blade in it.
I don't think it's adding so much in terms of complexity as adding in layers of resilience. Hang a lot of the critical systems off a controlled area network and you get a lot of resilience added in terms of "oh, cable run cut someplace, no trouble, there's still a network running, that packet I tagged for the missile system will get there anyway"
You also get some possibilities for virtual backup workstations - just sign in as an engineer ID and voila, you're running the engines, doesn't matter where in the ship you are.
Hell, you can cluster the servers across two widely separated data enclosures, missile comes through the window and clears out the CIC, the surviving node takes over, surviving crew shift ops to other spaces and the ship continues to operate, albeit at a lowered effectiveness.
What it's doing is offering higher uptimes, better and more graceful degradation, lower parts count, less expertise required for fixing stuff (I've swapped an entire motherboard on a racked server of a traditional configuration and it wasn't a lot of fun when folk were getting excitable, an entire blade could have been popped out in under a minute)
Yes stuff can go wrong but I think the gist of what they're talking about is a smart thing to do.
:
