Engineering seamless ship integration with CUBEDIN

Mission-based modularity is a concept that is attracting increased interest from navies and maritime security agencies who see adaptable and reconfigurable multirole vessels as a cost-effective way to match finite budgets with multiplying requirements.

As well as enabling greater flexibility in asset tasking, and potentially unlocking higher levels of interoperability and interchangeability between allies and partners, decoupling mission systems from platforms also opens up new and more efficient logistics and support models.

However, there are a number of constraints and dependencies that manifest as ship platform and mission payload come together – the idea of ‘plug and play’ should not underplay the complexity of engineering a smart, seamless and transparent integration between vessels and containerised modules.

As Danny Ingemann, chief executive officer of CUBEDIN A/S explains, “Different modules have different requirements, and different platforms have different constraints,” he says. “So containers by themselves are not a solution.”

The answer is to implement infrastructure and interfaces that allow a ship to become a fully reconfigurable ‘open architecture’ able to accept and integrate modules from different original equipment manufacturers (OEMs) with its own embedded platform and combat systems. “The vessel must communicate with the payloads just as if they were built into the ship,” says Danny. “And there needs to be an understanding of how modules integrate from both functional and physical perspective.

So how does CUBEDIN tackle this problem?

Drawing on lessons learned from the Royal Danish Navy’s modular Standard Flex concept, and capitalising on the proven software core of Systematic’s widely sold SitaWare C4ISR software product, the company has come up with an integrated data-driven solution founded on three software-based components that perform key functions of configuration management, ship-wide interconnection, and health/status monitoring.

The first of these components is the CUBEDIN Configurator. This is a smart software tool that allows the user to manage the integration of certified modules on a ship according to the planned tasking, but also taking into account the specific characteristics or constraints of that vessel.

According to Danny, the characteristics and requirements of each module are contained in a payload store. The Configurator then evaluates and advises compatibility based on the embedded rules for each vessel type or ship class.

“The Configurator software is there to ensure that the module, or modules, are embarked to locations in the ship appropriate to their purpose,” he says, “So a module containing unmanned aerial vehicles needs to be open to air, whereas a sonar installation requires that its launch and recovery mechanism is open to water.

“And then we must think about the ship service requirements of that module – power, data, cooling, and any more specific inputs such as fuel or air.”

In addition, the CUBEDIN Configurator also provides the command with an automated planning tool to ensure the ship is configured such that it is safe to sail. “It means there is an immediate reference to check ship stability margins, deck loadings, power balance, cooling capacity and so on,” Danny says. “Standard power, data and utility Interfaces ensures that modules and ship systems operate seamlessly.”

While initially developed to manage module integration at a single ship level, there is already thought to using the Configurator as a tool to support fleet planning. “As well as meeting a national need at single-ship or task group level, this could be used to support an alliance/coalition operation with different levels of functionality configured for each level,” Danny points out.

Enabling connections across the ship

Next comes the CUBEDIN Gateway, which enables the interconnection of the module into the host ship. This is achieved using a software plug-in – or Application Programming Interface (API) - that serves as a communication mechanism between the equipment module and the systems embedded in the host ship.

“We have to think about how we enable any system from any equipment manufacturer to ’talk’ to the ship systems,” says Martin Andersen, CUBEDIN’s lead software architect. “So we use the CUBEDIN Gateway to function as a digital interface between payloads and both the integrated platform management system [IPMS] and the combat management system [CMS]. It is there to translate proprietary languages from different systems and different OEMs into a common language within the CUBEDIN data platform.”

“We can envisage this type of standardised interconnection enabling NATO partners and allies to have the ability to seamlessly interchange different modules. So it is it is not just a question of physical compatibility – that same module will also be able to communicate regardless of whether it is on a Danish frigate, or later moved across to a ship from another NATO nation. 

“And it should be able to do that regardless of whether those ships have different IPMS or CMS systems.”

It is important to understand that the Gateway does not interfere with, or intrude on, kill chain processes ‘hardwired’ from the payload to the CMS. “We talk about red [classified] and black [unclassified] data,” Martin explains. “What we seek to do is take that black data – which is typically that concerned with equipment health and status - and make it available to technical/engineering personnel on board in order that they can identify and rectify any defects or degradation in weapon and sensor payloads.”

Now you see it…

The third and final component is the CUBEDIN Unified Front End. In broad terms, this is the functionality that enables all embarked modules to share and display their own data in a ‘shared’ front end in order that it can be monitored and interrogated by ship’s staff.  This means that technicians on board have exactly the same visibility of the health, diagnostics and fault indications status of a modular payload as they would for a permanent equipment installation.

“The transparency of this data can reduce overall crew requirements, and improve the availability of critical modular mission systems,” Martin points out. “The Unified Front End is perhaps better described as the ship monitor - it is enabling the display of payload data from a mission module in the ship management systems, and so informs task planning, mission tasking, operational support, and intra-module situational awareness.”

An important part of the CUBEDIN offer is the foundation offered by SitaWare as a proven COTS product. SitaWare has been iterated and evolved to function as a scalable C4ISR software suite able to share mission essential information, correlate and fuse multi-source data, organise collaborative planning, and enable visualisation of planning from multiple users.

Danny expands: “We have signed an agreement with Systematic to utilise a subset of SitaWare adapted to serve the specific needs of CUBEDIN.  It means that we can leverage the development undertaken over these past 15 years for our plug-ins.

“We are going to utilise a lot of SitaWare functionality in areas such as payload handling, configuration management, mission planning, logistics planning and functional integration. The big difference is that it will be implemented using SitaWare in a CUBEDIN environment.”