Impact Statement
The purpose of this article is to de-mystify digital twins in the maritime environment and outline the importance of requirements management to create a lean digital twin with real business benefits. Despite being discussed and talked about for years, digital twins have not been widely implemented in the maritime industry. Looking at the hype curve of implementation, the technology is currently in a trough following an initial hype peak. This is due to over promised expectations and high implementation costs, this article seeks to outline a path through the hype using benefits and requirements management.
The key take-aways from the article are:
-
- There is a need for clarity in terms and definitions for digital twins.
-
- It is vital to use requirements management in the digital twin creation in order to ensure the original purpose is met and increase the likelihood of a swift return on investment.
-
- Lean digital twins using this requirements management is leading to a second hype spike for digital twins (Team Defence Information, 2021).
-
- With cheaper sensing technology, data storage and high-performance computing, implementation is now more feasible from a technical and commercial perspective.
1. Introduction
1.1. What is a digital twin?
“Digital twins” have become a common buzzword in engineering (Gautier, Reference Gautier2020), used to describe everything from computer-aided design (CAD) models to predictive maintenance techniques. This can sometimes mean the phrase is over-used and used to support over promised product solutions. However with the global sector expected to be worth $86 billion by 2028 (Grand View Research, 2022), there is some value within the hype.
Digital twins can sometimes mean different things to different people; a useful definition that is widely used within the maritime industry is “a virtual representation of physical assets, processes, people or systems that can be used to support decision making when fed or provided with real-world data” (Mansfield and Rigby, Reference Mansfeild and Rigby2020). Further clarity can be added by including the definitions broadly adopted the United States of America (US) Department of Defence’s definitions of digital engineering (DE; which are now also adopted by UK MOD) as: “an integrated digital approach that uses authoritative sources of systems’ data and models as a continuum across disciplines to support lifecycle activities from concept through disposal” (Defense Acquisition University [DAU], 2022). Under DE, there are three definitions of digital products:
-
• Digital artifacts (including digital models): Standalone digital representations of conceptual or physical systems or effect. For example, CAD models that are taken at a snapshot in time or listed bills of materials.
-
• Digital shadows: Digital artifacts that are fed and optimized by real-word data from conceptual or physical systems. For example, these could take the form of updated system information databases that are updated on a regular basis but are not able to provide a live feed or feedback directly.
-
• Digital twins: Digital shadows that then feed results and information back to the real-world conceptual or physical systems.
To be a true digital twin, the system needs to operate in a closed loop as depicted in Figure 1. The figure shows how the physical asset provides a constant live or near live data or validation feed into the digital twin, which in turn is feeding back simulations, calculations or predictions that can be used to make operational decisions on the asset. These full digital twins receive regular data input from the relevant physical system, thus providing intelligent support for operational decisions. Twins are, first and foremost, learning systems driven by data that are collected from sensors in real time. This means that sets of complex digital models can adapt to mirror every element of a product, process, or service.
1.2. Benefits of digital twins in the maritime domain
The introduction of digital twins can provide some powerful core benefits as outlined below. For the maritime sector specifically where operational and through life costs are key performance drivers, the benefits have been split into the proposed distinction of operational benefits and future technology insertion planning for clarity.
Core benefits:
-
• Operations optimization
-
○ Health monitoring and predictive maintenance analysis
-
○ Anomaly detection and fault isolation
-
○ Efficient training and skills refresh
-
-
• Technology insertion planning
-
○ Option analysis and “what if”s
-
○ Minimize out of service time and cost
-
○ Right first time upgrades
-
Main blockers:
-
• Upfront cost
-
• Infrastructure
-
• Data/connectivity
-
• Security implications
-
• Adoption by all end-to-end stakeholders
They come in two main areas, first of all in the operations optimization, making sure that the asset is running as efficiently as possible; either in terms of training, anomaly fault detection, or with maintenance scheduling to ensure maximum utilization. This is especially important in the low margin environment of the maritime sector where small efficiency gains can make the difference between profit and loss.
Second, is around technology insertion and planning. The implementation of configuration control and configuration management enables the user to know exactly what is happening on that platform at any time. Although many ships will be built within a single “class” and have similar design traits, the exact equipment fit, wear and tear and equipment layout can vary slightly between vessels; every ship has a different life and development process. Configuration management allows the user to track these changes and establish a ship specific “twin” with all the required information. This means that when looking ahead to future capability improvements, the user can easily provide some options analysis and “what if” scenarios; effectively left shifting the risk of implementing new upgrades. Once again, this is especially important for the maritime sector where vessels are often designed for a life of between 25 and 50 years.
However, these benefits do come with some downsides and blockers, some generic, but most specific to the maritime sector. First of all, there are the initial upfront costs, especially when placing lots of sensors on board. Additionally, there is an infrastructure requirement to tie in the information that is generated from the sensors into the wider network. This provides some connectivity issues, especially when looking at a ship in the middle of the ocean. As always with transmitting information, there will also be some security implications of sharing or not sharing that information with wider parties. There are options for workaround solutions, such as one used in the aeronautical industry where information is saved offline in a local storage device and then later synchronized with the digital twin. This provides a “near real-time” solution providing most of the benefits without the security and connectivity restrictions. Lean digital twins also offer the added value of being much faster to run than other high-fidelity 3D digital models, which provides the capability to be able to run on these on onboard small computing devices. This then becomes what is sometimes referred to as an executable digital twin (xDT) that provides constant live feedback to on-vessel command reporting and decision-making platforms.
Finally, in order to get the full benefit of a digital twin, the user will need to have the full supply chain in the digital twin itself. If it is not adopted by all users end to end across the supply chain, then the full benefit will not be realized, and therefore, the user might not see the full return on investment possible. It is, however, important to note that value can be extracted at all levels of digital twin maturity—simple twins can provide simple value, then grow to full supply chain integration in time.
Looking at wider industry, luckily, there is a potential solution to the problem of wider supply chain integration issues by creating a lean digital twin. This utilizes the 20%–80% rule, using the minimum amount of effort in order to obtain the majority of the results rather than looking at creating a complete and final solution. The term “lean digital twins” originally spurred from the “lean start up methodology” outlined by Eric Ries (Reference Ries2011) has been seen throughout the industry in the last 5 years (Marmolejo-Saucedo et al., Reference Marmolejo-Saucedo, Rodríguez, Cruz-Mejia, Saucedo and Hurtado-Hernandez2020; de Silva and Gonçalves, Reference da Silva and Gonçalves2022), but has been specifically referenced in conferences for the wider maritime industry showing technology transfer (Rigby, Reference Rigby2021; McMaster, Reference McMaster2022). Although widely discussed digital twin technology in the maritime sector has either been slow to take off (Ibrion, Reference Ibrion, Paltrinieri and Nejad2019) or kept as business trade secrets as the technology develops.
The process of creating a lean digital twin has four core stages, each of which can be supported by requirements management—the process of ensuring that the capabilities of a product or service conform to the needs of customers and stakeholders:
Step 1 – What do we want to achieve?
It is vital to start with the end in mind, understanding exactly what efficiency savings or information the user is looking to extract. Using a requirements management system to ensure the proposed solution is matched to the requirements and is cost effective.
Step 2 – What sensors are required?
The next step, again linked to requirements management, is to understand exactly what sensors are required in order to generate the intelligence outlined in Step 1. There are a range of possible methods to intelligently identify expected optimal data requirements (e.g., sensor placement), such as the use of experimental design and value of information analysis.
Step 3 – Digital twin complexity level
The complexity level of the digital twin also needs to be considered (Figure 2); is it looking at an individual component or the full system? It is often the case that the full benefits are only obtained through full system and multi-system level twins, however, utilizing existing in-platform systems such as integrated platform management systems is also key for cost efficiency. For example, the existing integrated platform management system could be used as a rudimental sensor data collection system, providing some key benefits without an additional cost.
Step 4 – Use system allowing data twin to mature.
Putting the system into practice and allowing the overall system and prediction models to mature over time and as baseline data are collected.
2. How to approach the problem and requirements management?
It is important to discuss some of the principles and topics that might need to be considered by requirements managers when they are trying to write requirements for future technologies such as digital twins.
Anything is possible in the digital world, and care must be taken to ensure not to become fixated on the art of the possible. A phrase often used is the “art of the practical.” Not everything that can be done in a digital world will be worthwhile or generate tangible benefits. It is therefore recommended that a benefits centered approach is adopted to the development and reprioritization of requirements. Applying this to a maritime example, it means rather than attaching sensors and remote control systems to every single aspect of the ship, instead look at where real benefits could be gained such as reducing the maintenance burden or removing the need for regular manual equipment dial/display checks.
In order to identify the benefits of a proposed digital twin, it is important to first identify the features that are able to generate a quick return on investment. For digital twins to grow and interlink with other systems, it is important that the foundations are built in a robust and repeatable way. Putting the responsibility in the hands of the software vendors to ensure data architectures are in line with industry standards and utilize open-architectures with as much commercial off the shelf (COTS) functionality as possible. Working backwards using software systems engineering techniques, such as satisfaction arguments, would facilitate transforming benefits into requirements whilst also developing scenarios and vignettes (Attwood et al., Reference Attwood, Kelly and McDermid2004). Taking time and care to construct architectural models and binary diagrams for systems to deliver well thought out and properly constructed requirements for the digital twin environment. This kind of approach could help support the inclusion of other techniques/methodologies including for digital engineering and model-based systems engineering. Both these paradigms and lean digital twins, rely on robust interfaces between different digital artifacts and software packages. There are many cases of end-users moving from bespoke-written software tools, which work well once but do not scale well, to COTS software; examples include fast maritime craft (Haynes, Reference Haynes2014) and naval helicopter solutions (Gansler and Lucyshyn, Reference Gansler and Lucyshyn2008). This moves the responsibility for interface maintenance to the software vendor and marine engineering companies can focus back on their core business.
It is important to remember that there are two perspectives for the digital twin. First, the requirements specify the equipment that has to work with the digital twin, feeding it information and receiving information from the digital twin. Second, there is the digital twin itself; the platform has a system that will manage all of the data, complete the analysis reporting and the configuration control as well as create backups of all the information. It is therefore imperative to ensure that both the digital twin itself along with the equipment and facilities systems that work within it have been considered and represented in the requirements set.
Standards are yet to be firmly established for digital twins in the maritime sector, something that must be reflected in the requirements setting. Flexibility is also important to allow certain standards to be adopted in the beginning, but then enable a transition to new and better standards in the future. Whilst there are many generalized standards and guidance documents out there (DT Hub, 2023), there is limited maritime specific content meaning that a common structure and or taxonomy has yet to be defined. For example, there has been extensive work to standardize and create frameworks for the build environment “building information model” digital twins (UK BIM Framework, 2023) and although a National Digital Twin Hub was created as part of the Centre for Digital Built Britain (DT Hub, 2023), much of the content is targeted again toward this built environment context or to fixed critical national infrastructure assets. For the maritime industry to be properly supported, a common framework and taxonomy specifically built for the complex systems of systems on board a ship just like the BIM resources (UK BIM Framework, 2023) is required. This could possibly aligned to the US Navy Work Breakdown Structure (Wan Abd Rahman et al., Reference Wan Abd Rahman, Mohd Zaki and Abu Husain2019), although this structure is navy focused, it is can be used as a breakdown of components and design work on board a vessel.
Preparation must be made to invest where it is known that a certain direction is the best one to take. Conversely, steps must be taken to ensure that the long-term vision for the digital twin is not forgotten or compromised by the choices set in the requirements early in the program. Open architectures should be mandated to prevent suppliers locking customers into their particular technology. Additionally, open architectures are necessary to allow future technologies to be inserted and exploited, whenever it is appropriate to do so.
Similarly, with the prioritization of needs, if capability can be compartmentalized into areas that will facilitate plugins and extensions and allow certain plugins to be replaced with better ones in the future, as again technology develops and improves.
An example of how digital twins can be adopted into new ship designs is the Ellida™ design project. Ellida™ (BMT, 2023) is a future multi-role auxiliary support vessel concept design (shown in Figure 3) that has been used to test out how a digital twin can be integrated into the design from day 1. The digital twin is born and grows with the project every step of the way through life. However, if simulation tools can be effectively integrated the digital twin can be more than just a data store and can be one step ahead, making predictions on how aspects can be improved.
One example of this is that during the design phase, Naval Architects are optimizing the design and testing the requirements and making sure they align. During manufacturing, a further example is making sure that the manufacturing is right first time without the need for any rework. When it moves into the operations and in-service stage, the digital twin supports maintenance and again optimizes the complete maintenance and upkeep regime. In short, the digital twin will always strive to remain one step ahead, but will also continue to grow and develop following experience in service. It is important to continue to preform checks and monitoring on the system to ensure the system is still working as intended and the expected benefits are being realized.
To effectively manage requirements, it is recommended that they are incorporated from the concept stage. It is therefore suggested that the project management requirements lead the way rather than the actual requirements for the digital twin. The project management requirements will stipulate how information needs to be generated, how it is going to be validated and managed digitally at every step in the product lifecycle.
These requirements must cascade down throughout the whole building supply chain to ensure that all involved parties contribute to the digital twin in a coherent and consistent way. In addition, it is beneficial to understand the infrastructure already in existence, what can be developed, what needs to be replaced, and what changes need to be made in the short, medium, and long term across all the lines of development. In order to successfully achieve both, a new mind-set will be required facilitated by rapid responsiveness. For instance, training requirements will need to evolve alongside the processes. All new requirements will need to be robust and enduring but must also have flexibility running throughout, so they can be adapted and developed to suit new ways of working that the digital twin has optimized for the future.
3. How can the right software tools support customers to manage requirements more effectively and quicker than before?
For the third and final part of the article, we will look at software tools available to support the process and how software vendors can support marine companies to do this more effectively and quicker than before. This is where we can introduce COTS packages as a solution to turn requirements management for a traditionally isolated and static process to be embedded into the digital twin to help turn a document centric approach into a data-centric view to support the continuous updates being fed back into the life models.
The methodology for delivering the capability that we have discussed in this article is to list out the key physical components in a requirements management system and show the link to the digital models that are representing those aspects. For example, if a fueling system measures fuel flow rate compared to speed, and the digital model shows fuel rate and predicts speed, then the link between those systems should be included in the requirements.
Figure 4 shows the link between physical systems and processes on-vessel, and the digital representations of them. From left to right the images show, how fuel usage and tank levels are tracked and monitored, how electrical and power systems are controlled through central switchboards, how weather data are imported online from metrological societies, how maintenance data are tracked and controlled on a database, how optimal route planning can incorporate latest tide, wind, and chart data, and finally how the status of the ship as a whole can be captured and used for simulation and training purposes.
In addition, there could be links between physical systems and sub-systems, and further links between different digital models. These links can easily be modeled and managed within a requirements management system. This also then facilitates impact assessment studies to see what will be affected, and what will have to change, if any part of the physical or digital systems is changed (see Figure 5).
Finally, and critically, the state of the physical systems through its lifecycle needs to be checked against the digital models, to make sure they are constantly updated, and the right versions are being used. This avoids a state of digital twin which is sometimes referred to as a digital zombie: a digital representation of a physical system that is somewhat similar but no longer predicts true behavior of the physical system.
The three key areas to consider are:
-
• Software capabilities,
-
• Integrations, and
-
• Support and development.
3.1. Software capabilities
In considering the capabilities and functionalities required to support a requirements management approach to digital twins, it is important to identify the MoSCoW prioritization technique for managing requirements where the acronym identifies the key areas: must-have, should-have, could-have, and will not-have, or will not have right now. The latter is quite important, as software moves fast, and the final category can actually identify what could be needed in the long-term.
3.2. Integrations
The second key area is in the integrations between the requirements management system and the tools used to create the digital models that form part of the digital twin. This allows the extraction of key parametric values directly from the digital models, and mapping to the appropriate key parameters in the requirements management system. This removes the worry about data-entry errors (provided the systems are functioning correctly) and enables automatic reporting to check physical and digital systems are aligned.
3.3. Support and development
The final area of software implementation for lean digital twins is in the ongoing support and development. As with all digital systems, nothing is ever a “fit-and-forget” package. There are lots of moving parts in the overall system that need to be managed and updated: networking, storage, infrastructure, operating systems, security patches, as well as the external integrations discussed in the previous section. When one item updates, it often triggers a need to update something else. Most modern businesses are looking to software-as-a-service platforms and COTS software, using out-of-the-box (OOTB) functionality to move the burden of this systems management from their own companies over to software vendors or systems integrators (SIs). This allows, for example, naval architecture businesses to focus on the core marine issues, and not worry about high-tech aspects of software integration.
With respect to using OOTB functionality versus bespoke custom-written or heavily customized software platforms, most companies are moving to the former as much as possible. There are many older systems in use at a lot of companies that are completely customized to the original customer requirement, often with little knowledge still in the company that understands how it was configured or even why it was done in that way. This makes it very hard to support or develop, and hard for new users to adopt because they fit specific customer processes, not industry best-practice. When selecting new systems, it is better to use as much OOTB functionality as possible, including standard integrations between third party packages. When using a particular bespoke piece of software for one part of the process in digital twins, it should be considered whether the best value is in writing a bespoke integration, replacing the bespoke software with a COTS package, or even whether it is better to just use the requirements management platform to trigger a manual check, and manual transfer of data between digital models.
4. Conclusion
In conclusion, throughout all the hype, digital twins can mean different things to different people; a useful definition that is widely used within the maritime industry is “a virtual representation of physical assets, processes, people or systems that can be used to support decision making when fed or provided with real-world data” (Mansfield and Rigby, Reference Mansfeild and Rigby2020). This means that equipment monitoring sensors fitted to the vessel are fed back in real time or near real time to change how the vessel is maintained or operated.
However, despite the technology being around for many years implementation has been slow due unclear risks and benefit assessments, in order to resolve this a new methodology of “lean digital twins” has been introduced. Lean digital twins involve the integration of rigorous and effective requirements management processes to bring around the second peak and true exploitation of digital twins (Team Defence Information, 2021). Digital twins are a key vehicle for business improvement, providing greater insights, reducing unnecessary activities and saving costs in both the design and operation.
With cheaper sensing technology, data storage and high-performance computing, implementation is now more feasible from a technical and commercial perspective. However, there are still some obstacles to overcome. For instance, there is a pressing need for clarity in terms and definitions/taxonomies for digital twins and a need to ensure the effective implementation of requirements management.
Cost requirements and data management are key to the successful implementation of digital twins. Digital twins do not come fully formed out of the box (unlike some of the software components), but they should be tuned and will grow and mature in parallel with the systems themselves. Requirements management will get the project going, but it is the data that keeps it alive. Finally, the important message is that the solutions and the tools are available today and ready and waiting to turn your digitalization aspirations into reality.
Data availability statement
No data was used in the creation of this report.
Acknowledgments
BMT and Siemens would like to thank all those who supported the production of this report and all our customers; without their support none of this would be possible.
Author contribution
Introduction: J.R. How to approach the problem and requirements management?: B.J. How can the right software tools support customers to manage requirements more effectively and quicker than before?: J.R. Conclusions: J.R. All authors approved the final submitted draft.
Funding statement
This research conducted as part of self-funded work by both organizations.
Ethical standard
The research meets all ethical guidelines, including adherence to the legal requirements of the study country.
Competing interest
The authors declare none.
Comments
No Comments have been published for this article.