The complexity of maintaining and upgrading existing vessels and the need to build and integrate new vessels into the fleet has forced the US Navy to implement a single, unified product information and digital engineering strategy. In this case, the product refers to configuration-managed models and technical data for ships and weapon systems.
The situation the US Navy, NAVSEA, and US Navy shipbuilders faced has many challenges. Namely, there is an urgent and increasing need to deliver more vessels more quickly and upgrade existing vessels with more advanced systems at an increasing rate. There are no existing standards on asset data types and interfaces, and numerous software packages commonly in use across the larger naval ecosystem are nearing the end of their lives.
Shipyards play a pivotal role as they generate, and in many cases own, the information that is key to program management. Through our work with defense shipbuilders in the US and the US Navy, we have identified and initiated the technical steps required to create a trusted and reliable method to communicate vessel requirements from the Navy to shipbuilders and systems models in the reverse direction.
Shipyards are choosing an information platform that integrates seamlessly with the Navy’s PLM system. This approach eliminates a significant portion of the implementation work that the shipyard would otherwise need to take on. In effect, the effort of examining what data needs to be mapped, how it will be exchanged, and building this exchange is short-circuited.
Managing vessel and program requirements
Examining vessel requirements provides an illustrative example of this approach in action. US Navy master program requirements and system model originate in Cameo. This level acts as the source information for the builder.
These requirements are connected and replicated for the class environment at the shipyard. In the case of our clients, this occurs within SSI ShipbuildingPLM. Functional design, detail design, and change management within the class environment are coordinated and connected with the SWBS. Relationships link requirements to the functional design to catalog and 3D model parts. Configuration control is handled by the ShipbuildingPLM system.
The production environment for each hull brings together navy and class requirements while also supporting specific site or vessel requirements. Combined with the shipyard’s engineering solution (in the case of our clients, this is ShipConstructor), this is where the 3D model for the specific vessel comes together, and information is fed to the shop floor. Any changes to the model are captured, and the delta is fed back to ShipbuildingPLM to complete the configuration control feedback loop and validate changes prior to release.
With such an architecture and workflow, the US Navy and shipbuilders have a clear line of sight across the program, with a digital thread from requirements to production. Change is tracked from the beginning of the process and can be used for studies and work assignments. In the end, unknown change is eliminated, and the cost impacts of rework are mitigated. Further, because MBSE was considered from the beginning, there is a clear path from the Navy to the shipyard using a standardized approach, supporting through-life improvements and upgrades downstream.
US Navy shipyards will eventually be contractually obligated to provide information Model-Based Product Support (MBPS) environment to support MRO/Sustainment. Ensuring that today’s programs, as well as future programs like FFG(x), DDG(x), and EMS, have information stored in a way that can feed those requirements will ensure significant cost savings for both shipyard and Navy.
Navy and Defence shipyard project conversions
One of the realities of defense programs is the need to perform data and model conversion. For older vessels, this is often because the legacy systems used as part of the original design are either unavailable or unsuitable for use in repair/refit work. In the case of new vessels, designs may originate from a CAD system that is not in use at the shipyard responsible for building the program, or multiple shipyards are building the same vessel but have different technology infrastructures. In both cases, the need to convert data quickly and in a way that reduces conversion costs (both in terms of time and post-processing requirements) is a core requirement.
SSI’s experience supporting US Navy sustainment and MRO
There is a major benefit when organizations performing sustainment activities are using the same systems as the original designer and the US Navy standard. Having worked with major defense shipyards and design agencies as a partner on numerous sustainment and conversion projects, SSI’s team has revealed the high cost and time savings of converting existing information into ShipConstructor rather than spending labor hours on additional detailed design work to support MRO activity.
In the case of one large US Navy shipbuilder and defense contractor, SSI led the contract and execution of translating data for two US Navy Class programs. In these cases, the originating information was in the form of DIM3, CSDDS5, SPADES, CALMA, Intergraph Data, AutoCAD solids, and solid geometry. The information affected all disciplines, including hull, structure, pipe, HVAC, equipment, structural foundations, and electrical. In total, several hundred thousand parts were translated across all design disciplines. The end cost savings were calculated at over US$160 million in detail design labor hours across the programs. Similar initiatives with other clients have resulted in further millions in savings and future-proofed shipyards against solution deprecation or software incompatibility.