Complex, software driven systems

Over the past decades, ship systems have become increasingly complex, software-driven and integrated. Moreover, systems and equipment are typically delivered by a range of different OEMs for any one ship, without the presence of a strong system integrator as we see in e.g. aviation and automotive. This has led to a number of steadily increasing challenges in designing, building, operating, maintaining and assuring these systems. Referring to Figure 1, our accumulated experience and customer feedback shows that:

  • It is increasingly difficult to design and optimize the integrated ship systems, since the overall system performance depends on the interplay between systems and software from different sources, and their actual behaviour cannot be predicted without actually simulating or observing them in operation together.
  • It is difficult to assess whether the system is safe and fit-for-purpose, and even after it is put into operation only a small ratio the possible scenarios the system should be able to handle can feasibly by tested.
  • With systems and software from many OEMs, commissioning and integrating them as one system onboard the ship is challenging, especially since there is no system integrator having the full overview and insight into the various parts of the system.
  • In addition to complex systems, we are also dealing with complex operations and complex human-machine interaction, further increasing the challenge.
  • Change management – both during construction and in operation – is increasingly difficult, since it is not possible to predict the consequences of a change in one software system on the other, connected systems and the ship systems as a whole. There are numerous stories about apparently simple system updates/patches gone wrong, since integration suddenly was broken unintended.
  • With increasing connectivity and following increasing external cybersecurity threats, there is an increasing need to update and patch the onboard systems. These more frequent updates increase the risk of system malfunctions due to lacking change management, and challenge ship owners and operators in balancing cybersecurity and system safety.
Figure 1: Challenges of complex systems

Figure 1: Challenges of complex systems

The Open Simulation Platform JIP

The Open Simulation Platform (OSP) initiative emerges from these challenges, with a short- to medium-term vision of:

  • Enabling collaborative digital twin simulations to solve challenges with designing, commissioning, operating and assuring complex, integrated systems.

and a long-term grand vision of:

  • Establish an ecosystem for collaborative digital twin simulations to solve challenges with designing, commissioning, operating and assuring complex, integrated systems.

The OSP was initiated through a MoU signed in 2017 and confirmed in 2018 by a partner agreement between DNV GL, Kongsberg Maritime, SINTEF, NTNU. To ensure a wider anchoring across the maritime industry, increase funding and assure the relevance and timeliness of the initiative, a JIP was launched in Q2 2018 and formally started with 20 additional partners in Q3 2018, see Figure 2. The JIP closed as planned in Q2 2020 after two years of collaborative development.

Figure 2: OSP JIP partners

Key principles

The OSP JIP was founded on a set of key principles that remained intact through the 2-year project, as shown in Figure 3.

Model re-use: Simulation models and digital twin components are increasingly used by individual OEMs in their internal working processes, but typically not made available to other stakeholders. To achieve scale and efficiency in building digital twin systems and assets we need to re-use these individual digital twin components also in other contexts.

Protection of IPR: In order to share and re-use digital twin components, it is a prerequisite that no IPR contained in the component is exposed to other parties without the IPR owner consent. This requires black-boxing the individual components, and also making sure they cannot easily be reverse engineered. Critical IPR in a digital twin component would typically be the physics model of the equipment and its performance, and the control system software including HMIs. Various ways of black-boxing are discussed in [REF Cabos and Prostep IVIP], and not further elaborated here.

Co-simulation: A major challenge is to enable integration and orchestration of individual models and digital twin components originating from different stakeholders, simulation tools and platforms. Co-simulation solves this by decoupling the system simulation in its individual components, with each component containing a solver and executing independently of each other, synchronizing and exchanging information only at fixed intervals determined by the co-simulation engine.

Common standards: To enable efficient construction of large co-simulations from a range of individual components, interoperability and common standards are needed. This pertains to both run-time requirements and component interfaces We have set out to build on established standards wherever possible, only adapting and expanding on these when necessary for our maritime context.

Open source:  In order to drive standardization, ensure interoperability between stakeholders and tools, and enable common working processes, we strongly believe that a common, open-source software for co-simulation is needed. The idea is that any stakeholder can integrate the open-source software in their own working processes and tools, thereby simplifying cooperation and ensuring a common ownership and further development of the software.

Collaboration: The challenge of complex systems is too big to be taken on by any individual stakeholder or tool. Therefore, the OSP focuses on collaboration and interoperability between tools, platforms and stakeholders.

Key principles of the Open Simulation Platform

Figure 3: Key principles of the Open Simulation Platform

OSP JIP Deliverables

The OSP JIP had the following main deliverables, all can be accessed through the project website, where also more details can be found:

OSP LibCosim: The OSP LibCosim is an open source software for co-simulation, built on a combination of technical solutions from the OSP initiators and other established industrial solutions, in particular the Functional Mockup Interface (FMI) standard from the Modelica Association. FMI has been driven primarily from the automotive industry, where they have similar challenges with complex, integrated systems and software. The number of modelling/simulation tools that support FMI export is already large and increasing, enabling generation of so-called Functional Mockup Units (FMUs) that adhere to the FMI standard for co-simulation. The key working principle has been to use the best available technology and knowledge to meet the requirements for the OSP to efficiently serve its purpose. The LibCosim source code is available on GitHub, free of charge, through the MPL 2.0 open source licence.

OSP Interface Specification: Since we want to avoid re-inventing the wheel in any way, building on the FMI standard, and a growing number of sister standards from Modelica, appears to be a good choice. However, there are maritime specific needs that must be addressed. The first goal of the OSP interface specification is to reduce the effort required to construct a simulator and hence make it cheaper and more affordable, which can open up for a more widespread use of simulators in existing and new applications. The second goal is to make the connections between the simulator and a control system easier. Finally, we want to make models more available. The OSP interface specification is published free of charge under the CC-BY-SA license, with the ambition of maturing this into an established industry standard. A software tool for verification of model interfaces per the defined specification is also available.

OSP Reference Models: This is a set of reference models including some of the most common marine systems and ship dynamics, adhering to the modelling guidelines and interface standards in the OSP Interface Specification. The reference models may be freely used and further developed by other parties, free of charge, and is available on GitHub together with OSP LibCosim through the MPL 2.0 open source licence.

Use Cases: Three use cases, together spanning across the ship lifecycle, have been developed together with the JIP partners to test and verify the OSP software deliverables and standards, to explore value creation from the use of OSP, and to investigate possible business models:

  • Design of a hybrid power and propulsion system for a pendulum ferry
  • Virtual commissioning and integration testing of a DP ship with equipment from several manufacturers
  • Planning of a subsea crane operation with the NTNU research vessel Gunnerus, involving a large number of models and a visualization solution deliver by OSC.

HIL, SIL and Digital Twin components

Figure 4 shows a conceptual sketch of a component or system including some physical equipment (on the right) and a control system (on the left), as it works in real life during operation. The control system consists of some software running on some native hardware, and some physical input/output (I/O). The control system sends control signals to the actuators, which perform some action and influences the system dynamics, which again are picked up by sensors and sent back as measurements to the control system.

In a Hardware-In-the-Loop (HIL) setup, the physical equipment is replaced by a HIL simulator, which models the real actuators, dynamics and sensors, see Figure 5. The control system, still running on native hardware including operator stations and other HMI’s, networks, etc, now sends control signals to the simulated equipment, and receives simulated measurements back. In a good HIL simulator, the controls system does not notice the difference between being connected to the real equipment and the simulated equipment, enabling thorough testing of functionality, robustness and performance in a lab setup. This has been proven to work well in many industries. However, there’s one major drawback, and that is the reliance on the control system hardware (the H in HIL). This means you rely on a lab setup where the correct hardware is made available for testing. For individual systems, this can work well, especially for a newbuild project where e.g. the FAT can be used for extended simulator-based testing. However, for a ship in operation, the necessary hardware may not be so readily available. Moreover, and more importantly, the reliance on hardware means that integration testing between several systems only can happen if the hardware from all involved manufacturers are collected and connected in one location. For a ship, this is usually not the case until at the shipyard, close to vessel delivery.

The next step is, therefore, to virtualize also the control system hardware, as illustrated in Figure 6, leading to what we call a Software-In-the-Loop (SIL) setup. Now only the control system software remains unchanged (since this is already software), but it is running on emulated and virtualized hardware. This could be e.g. a soft-PLC or a virtual Windows or Linux PC. Also the operator stations and other user interfaces must be virtualized.

Since this complete setup now consists only of software, it can be viewed as a digital twin component, containing both the physics models of the equipment and the control system running it.

Physical control system and physical equipment under control

Figure 4: Physical control system and physical equipment under control

Physical control system and simulated equipment in a HIL setup

Figure 5: Physical control system and simulated equipment in a HIL setup

Virtualized control system and simulated equipment in a SIL setup, comprising a digital twin component

Figure 6: Virtualized control system and simulated equipment in a SIL setup, comprising a digital twin component

OSP co-simulation architecture

Based on the concept of digital twin components discussed above, Figure 7 shows the OSP co-simulation architecture with a standard interface built around the FMI standard.

The co-simulation algorithm and interface enables digital twin components from different OEMs or other providers to be connected in one simulation, as long as they all follow the OSP model specification. The key idea here is, as outlined above, that these digital twin components contain both physics models and control system software. We can also add pure SW systems such as a monitoring and control system, and pure simulation models such as e.g. a hull model and environmental loads. Finally, the OSP LibCosim includes a remote interface, enabling distributed execution of models. That is, some models may be executed on a different hardware or cloud solution, and connected using the remote interface.

In this architecture, since we no longer rely on the control system hardware, digital twin components from different OEMs can be connected and integrated without shipping equipment around the world. The simulation can in principle be run anywhere with sufficient computing power: on a regular PC, on a local server park, or in the cloud.

Additional benefits are e.g. that time potentially can be accelerated in simulation, meaning test cases can be run faster, and that simulations can be parallelized and orchestrated to further increase test efficiency.

OSP co-simulation architecture

Figure 7: OSP co-simulation architecture

Overarching idea: virtualize the system lifecycle

The overaching ambition of the OSP initiative is to enable a virtualization of the working processes with complex systems and software, leading to new working processes and reduced risk. The lower part of Figure 8 shows the typical timeline for traditional ship design, construction and operation:

  • Design is typically done using static, simplified tools and considerations, not accounting for system dynamics and integration
  • Equipment and systems from all OEMs and sub-suppliers are delivered to the yard after going through some simple Factory Acceptance Tests (FAT)
  • At the very end of the construction phase, when all equipment and systems have been mounted, powered and connected, commissioning, system integration and testing can commence – in practice this is often right on the critical timeline before the vessel is being delivered.
  • The vessel then goes into operation, with its systems having been subject to a very limited set of tests and scenarios, both due to time constraints and feasibility of testing.

The upper part of Figure 8 shows how the OSP enables the industry to “shift left” – that is, move systems related activities to the digital twin, enabling them to happen earlier and support the physical builiding process:

  • Use proper dynamic models and simulations to improve system designs and lay the ground for as “systems digital twin”, which encapsulates system dynamics and software behaviour
  • When the design has been frozen and OEMs selected, they can deliver digital twin (virtual) components and systems to the systems digital twin, where virtual system integration, commissioning and testing can happen long before the physical vessel is built.
  • With the systems digital twin established and commissioned, it can be used to support the physical integration and commissioning process onboard the real vessel, both for troubleshooting and to increase the test scope. But most importantly, most of the verification can be done independently of the critical construction timeline, saving time and reducing risk both during commissioning and sea trials.
  • The same systems digital twin can now follow the real twin into operation, enabling a range of use cases supporting the operation of the real asset, such as change management and training.
  • For example, if one OEM needs to update/patch their control software, this can be done on the systems digital twin first, verifying functionality and performance, and checking for any unintended consequences towards the other ship systems, before the update is rolled out on the physical ship.
Timeline for traditional ship design, construction and operation (lower part) and the OSP vision of moving system related activities to the digital twin ship (upper part)

Figure 8: Timeline for traditional ship design, construction and operation (lower part) and the OSP vision of moving system related activities to the digital twin ship (upper part)

Scroll to top