Digital Twins for As-Maintained Configuration Management

Configuration ManagementCMsights
Written By Tom Tesmer

In this month’s CMsights we asked Configuration Management practitioner, standards influencer, trainer, and author Kim Robertson to help us distill all the hype about digital twins and digital threads so we can understand their impact on as-maintained configuration management for long-life aerospace & defense equipment.

Kim Robertson has over 39 years of experience in the A&D sector and is a co-author of “Configuration Management: Theory, Practice and Application” which is being used as the text for a graduate level course in C&DM at the Technical University of Eindhoven. He holds a CMPIC Configuration Management Principles and Implementation certification and is a National Defense Industrial Association (NDIA) Certified Configuration Data Manager (CCDM). Kim is a member of the SAE International G-33 committee for CM Standards and worked on Revision C of SAE/EIA-649.

Digital This, That and Everything…

Digitalization, digital transformation, digital twins, virtual digital models, digital threads, MBE, MBSE, IoT, big data and the list of all things digital goes on and on these days. Let’s start with a few basic definitions.

  • Big Data - Large data sets that may be analyzed using algorithms to reveal patterns, trends, and associations.

  • Small Data - Data that can be comprehended by a single individual as it is in a format that makes the information actionable. It pre-supposes that the data is accessible.

  • Digitized Data - Data that has been converted into a digital format like a historical document scanned to pdf.

  • Digital Data - Data that has always existed in some kind of digital format.

  • Digital Fabric - The linking of all the various digital threads so they make sense.

  • Digital Thread - The linking of items to establish a relationship. For example the drawing to the thing it builds to the test procedure that tests it to the as-run test procedure to the test report. Another digital thread would be the linking of each of these items to the CDRL they are delivered under.

  • Digital Twin - A virtual model representation of a physical object that is correlated with physical object measured results.

  • Model Based - The information is modeled so that some kind of prediction can be made from it.

  • Model Based Engineering - The model is for an engineering field like design, structures, thermal, systems, etc.

  • Model Based Systems Engineering - Systems requirements model tracking requirements to their allocation and fulfillment via validation and verification activities.

  • Internet of Things - Internet connected computing devices embedded in everyday objects often called smart technologies. Often controllable via a phone, tablet or laptop.

And one final definition just for those who have bought into the hype without a clear understanding of their business requirements or strategy options:

Digital Rats Nest (DRN)

Digital Rats Nest (DRN) - Unlike a Gordian knot where there is one thread, the Digital Rats Nest (DRN) is encumbered with so many unnecessary digital relationships that actually finding a piece of information is impeded. Our apologies to rodents.

An exact definition of a digital twin is offered by Ben Hicks, Professor of Mechanical Engineering at The University of Bristol in this article on “Industry 4.0 and Digital Twins: Key Lessons From NASA” at https://www.thefuturefactory.com/blog/24:

 

“A Digital Twin is an appropriately synchronised body of useful information (structure, function, and behaviour) of a physical entity in virtual space, with flows of information that enable convergence between the physical and virtual states. The Digital Twin can exist at any stage of the life-cycle and aims leverage aspects of the virtual environment (high-fidelity, multi-physics, external data sources, etc.), computational techniques (virtual testing, optimisation, prediction, etc.), and aspects of the physical environment (historical performance, customer feedback, cost, etc.) to improve elements of the product (performance, function, behaviour, manufacturability, etc.) over the life-cycle.”

 

Notice the early emphasis on “appropriately synchronised body of useful information”. This definition sounds eerily like yet another repositioning of Product Lifecycle Management (PLM). Many PLM research firms are indeed speaking of the role of digital twins in enabling PLM as an enterprise IT strategy. Some industry followers have even championed the idea that investigating and investing in digital twins and digital threads is a better alternative to that of PLM. To learn more on what others are saying about digital twins, and hear different perspectives as to the advantages, challenges, and state of maturity consider these industry references:

Digital Twins for As-Maintained Configuration Management: A Destination or Detour?

Digital Twins are being promoted by some solution providers as a panacea for everything from systems requirements verification to maintenance of deployed systems.  A few are endorsing the idea of creating and then managing a digital twin over the lifecycle of each deployed as-built unit. That may be attractive to those who have never been involved with day-to-day Operations and Maintenance (O&M) activities in the field, but the practicality of it isn’t something that will really help those performing the maintenance operations.

Yet some believe, myself included, that investing the time and effort into manufacturing and managing a fleet of physical products and then having to create and manage exact digital replicas is at this time unrealistic for many reasons. As example, I have yet to see a company that can tell you the heritage of every component used in a product with extensive use of electronics. Part substitutions, either from a program designated substitution list or a company supply chain designated list, in most cases are rarely tracked. Don’t get me wrong, many firms do a great job of saying what the as-built parts list is; however few can tell you the exact placement of the same component on a board by lot date code especially if lots are mixed.

Industry analysts like Marc Halpern with Gartner are also equally cautious as he shared in this article at https://www.engineering.com/PLMERP/ArticleID/16272/Digital-Twins-Beware-of-Naive-Faith-in-Simplicity.aspx where he comments “It will take longer and will be more resource-consuming than anyone can imagine to get these solutions in place.”

A more fundamental challenge is that the way digital twins and virtual models are envisioned to be used very much depends on which organization you talk to.

  • For systems engineering a digital twin is something that pulls data from the CAD, PDM and ERP systems to assure that all of the validation and verification is documented proving that you have met the functional requirements. In many cases the systems digital twin vision is some sort of requirements management system on steroids that often overlooks some of the ”-ility” needs of the product such as those for producibility, manufacturability, reliability, maintainability, etc. It is a somewhat myopic view as many systems engineers often see their job as basically over after product acceptance and completion of functional configuration audit (FCA) and physical configuration audit (PCA).

  • For hardware design engineering a digital twin is the model of the item in the CAD system where they can noodle around with component placement, component interfaces, mechanism interaction with static components (e.g., focus mechanisms, rack and pinion systems, gimbals, etc.). While branching and merging of mechanical components are as critical as branching and merging of software, firmware, cabling, and computers there is an obsolete mindset that “these things are simply stuff that is applied to our hardware.” I’ve seen ever so few instances where branching and merging in the hardware includes branching and merging of all of the needed elements coming into the design from harnessing, electrical CAD, SW, etc.

  • For software engineering the digital twin may include thermal characteristics of the components but for the most part these engineers and programmers are trying to make something where there are no absolutes. Electrical systems design is akin to fluid dynamics except in fluid dynamics when you buy a flow restrictor, dump tank, fluid storage container, etc. you know that they are all the same. With electronics your components are all subject to the plus or minus criteria of + or – 5%/1%/0.1% etc., of the stated value.

  • For structural and thermal engineers the idea of the digital twin is discipline specific and at present tend to be component or subsystem specific. Yet in the real world we have all experienced cascading failures when faced with things like auto maintenance. One example is when you find you have a worn out water hose and replace it only to find that the next weakest hose develops a leak because now more pressure is being placed on it. Fix that one and the next weakest hose fails which is one reason that the maintenance people say to replace all the hoses at the same time.

  • For maintenance, repair and operations (MRO) engineers a digital twin model may be created for a specific repair or maintenance operation. Some MRO engineers make a good case that “digital twinning” is not that new of a concept as MRO providers have been performing a version of this for some time as referenced in this article at https://www.mro-network.com/emerging-technology/what-s-so-new-about-digital-twinning.

The Multiverse of Digital Twins Requires Not Just a Digital Thread But a Digital Fabric

Any of the multiverse of digital twins described above will fail without accurate configuration data from test, analysis, inspection, and repair records. What is critical is the entirety of the digital fabric woven from those threads so that you maximize the search success rate and minimize inaccuracies throughout the entire product lifecycle. Test, analysis, demonstration and inspection results are simply data points. They are meaningless until woven together to give an overall picture of what is going on.

CAD based digital twins give you the as-designed models, but without an ERP module they can’t give you the as-built information. ERP based digital twins give you the as-built information but have to be linked to the as-designed data with an import module to provide traceability to CAD models. Systems based digital twins generally center around system performance rather than as-designed, as-built, as-delivered, or as-maintained information. I have not seen a proposed solution for a digital twin that seamlessly encompasses everything they need to.

I’m not alone as Marc Halpern also recently made the point that only 5% of companies are at the level of maintaining a digital thread and many will never need to get there.  His point is important to understand. If the contractual obligation is to meet your hardware, software and data delivery requirements and you can do that without carrying the overhead associated with a digital twin multiverse, why would you invest in one?

What If We Could Build a Master Digital Twin?

Let’s assume we can build an all-inclusive digital twin that meets everyone’s desirements. Let’s also assume that we have the funding, talent, tools, and the capacity to make one of these twins for every deliverable serial number. Further let’s assume that we have the information services infrastructure to house and protect the twin(s) because housing the digital twin(s) and associated intelligence has to be local and twins are notoriously data hungry. We still have to ask the question, “how does such a digital twin benefit the enterprise or the customer?”

Dr. Karl Popp states in https://www.drkarlpopp.com/revenuemodelssoftwareindustry that the relationship between business model and revenue model is based on causality. The main revenue source is maintenance and support. This is also mentioned by Aditya Ambadipudi et al in the article on industrial aftermarket services at https://www.mckinsey.com/industries/advanced-electronics/our-insights/industrial-aftermarket-services-growing-the-core where it is stated “Despite the rise of digital initiatives, core aftermarket services—the provision of parts, repair, and maintenance—are also critical to success.”

Government program offices and industry contractors have to then ask themselves, Are we ready for a world where what we build has a possible end of life some 3-4 generations from now? Perhaps we are already there looking at these examples.

  • The Minuteman III, developed for a 10 year life span, was first deployed 17 April 1970. It is now expected have a 70-80 year service life.

  • The first B-52 entered service in 1955 and some believe the B-52 may now have a 100 year service life.

  • The first Boeing 707 entered service in 1957 and as of 2019, a handful of 707s still remain in operation acting as military aircraft for aerial refueling, transport, and AWACS missions with a possible end service life of 80 years.

  • The HMS Trincomalee built in Bombay, India has been in service since 1817 with a possible end service life of 230 years.

  • The Queen Elizabeth 2 (QE2) operated from 1969 through 2008 as an ocean liner and since 2018 as a floating hotel in Dubai with a possible end service life of 90 years.

  • Hubble Space Telescope (HST or Hubble) was launched in 1990 and is still operational. During its life is was upgraded or repaired with five shuttle missions. There are ongoing discussions of additional servicing missions in 2020 and beyond for an operational life that may exceed 50 years.

They have only been able to remain operational due to comprehensive tracking of as-maintained information. The U.S. Coast Guard document DepCOMDTINST M4140.1 on Cost Guidance Principles at https://media.defense.gov/2017/Mar/28/2001722979/-1/-1/0/CIM_4140_1.PDF states:

“The up-front cost of an acquisition may be as small as 5 to 20 percent of its lifecycle costs – and yet the lifecycle cost is determined by many of the events and much of the planning which take place during acquisition. From the life-cycle cost perspective, a significant part of the TOC of an asset is determined by these O&M costs.”

This equates to between 80 and 95% of the cost of any fielded system existing in the downstream operations and maintenance activities. At the end of the day traceability and maintainability issues related to O&M cause the most headaches for the downstream data user far removed from the early life cycle phases preceding acceptance. Traceability issues because recalls/maintenance due to suspect parts need to be identified against all fielded and in process end items. Maintainability issues due to the various levels of operations and maintenance activities taking place throughout the serviceable life of delivered items.

It gets even more complicated once the end item goes out of production and the service life is extended beyond the initial design criteria. Reliable metrics regarding spare or service part inventory sizing and impacts due to shortages are rarely captured for older systems.

Digital Threads Needed to Connect PLM, PDM, and CM Data

I recently went through a rush exercise to define the Parts Identification List (PIL), As-Designed Parts List (ADPL) and As-Built Parts List (ABPL) for an earth imaging instrument. It had used spare components in it that were excess to the last contractual build of a detector. As is often the case in A&D programs, excess components from contract 1 were moved to and consumed by contract 2. The as-built Electrical, Electronic, and Electromechanical (EEE) parts list for those components by serial number were on a server and not captured in the PDM system.

Instead of performing a quick search of the PDM data we spent almost a day looking for them. We lucked out because the only person who knew where they were on a file server got back to me hours before he left on a 2-week vacation. Not capturing the supplier SDRL submittals in the PDM system created a break in the digital thread downward from the CDRL requirement to the data associated with it.  This break in building the digital fabric from the CDRL to the supplier to the supplier SDRLs to the vendor report almost made us miss the prime contract CDRL delivery date which would have been a hit to Award fee. Read more about CDRL / SDRL data management solutions at Contract Deliverables Data Management (CDDM) Solutions.

It wasn’t a failure of the CM tools, PDM software, or overall PLM strategy, it was a failure in implementing the requirements of the CM Plan within these connected systems that could support a continuous digital thread. Had it been architected properly you should always be able to answer these questions in less than two hours:

  • What is the current as-maintained configuration of each fielded unit?

  • Have all modifications been incorporated, if not which units still have to be modified and where are they in the upgrade cycle?

  • What is the maintenance schedule for fielded units?

  • What fielded products are impacted by maintenance or upgrade activities?

  • What is the projected run-out date for inventoried spares or upgrade kits?

  • What is the criticality level of upgrades, how many units have been upgraded and how many remain?

  • What is the cost of delay (time, dollars, vulnerability)?

  • Do service and operations manuals need to be modified as a result of upgrades?

  • What is the training impact?

If you can’t quickly find these answers then the digital threads in your CM software implementation are not properly woven together. This robustness gives you the information you need to tie together scheduled maintenance, spares inventory, unplanned repairs, and provide insight into the impact of proposed changes. It also assures that change impact can be sorted out and incorporated in all units.

Weaving the Threads into a Digital Fabric

One example of the critical role of the digital fabric is the linking of all of the supplier SDRL submittals to the Statement of Work for the supplier, linking that in turn to the specification, contract, and the delivered supplier end product, then cross linking those SDRL submittals to the various prime contract CDRLs and then to the next higher assembly. This is the only way you have to answer certain questions for a supplier item. They include reliability, EEE parts list, safety, As Built, etc. These link to the produced item which is consumed by a next higher assembly. But you also have reliability, EEE parts list, safety, As Built, etc. requirements at the next higher level and so you link the lower level results to that level as well. You also have CDRLs of your own that rely on vendor results, so you make another linkage from the SDRLs to the CDRLs that rely on them.

Thread by thread you weave the digital fabric from the bottom up to assure that all system and non-system requirements are captured and can be evaluated. A single digital thread, like a fishing line is only good at hooking one fish/flowdown at a time. Once you weave the threads together you have a net that can maximize your total yield and give you a good sense of the health of your program’s ecology.

Let me close by putting this all into perspective. Gentry Lee Chief Engineer from the Jet Propulsion Laboratory in his 2005 presentation “So You Want to Be a Systems Engineer” at https://www.youtube.com/watch?v=E6U_Ap2bDaE states “the role of systems engineering is to understand the partial derivative of everything with respect to everything else.” While it works conceptually from a systems standpoint it doesn’t work at all where the real cost of a fielded system resides. I believe that unless you are operating in a purely paper system that some digital threads or shreds will exist. This means that perhaps most enterprises will never have all the data connections promised by an all-encompassing digital twin to meet the systems dream of  if they don’t have to.

To reach the needed ROI from the up-front cost of an acquisition and reduce the 80 to 95% hit in the O&M phase requires that at a minimum all involved with the acquisition need to focus on the down-stream users of all that digital stuff and assure that as-tested, as-delivered, as-fielded and as-maintained data is available when and where it is needed. Above all information needs to be easy to find and in a useful format. This structured approach to “small data” makes all the difference, yet it is all too often overlooked and can result in the dreaded DRN. That alone in my view is not something that  investment in creating a digital twin for every as-built and as-maintained configuration will ever be able to mitigate.

Next Up

Thanks to Kim for this comprehensive and provocative discussion on the use of digital twins for as-maintained configuration management. In the next post of this CMsights series we will address the more practical issues of using configuration management software like EPOCH CM or PDMPlus for tracking the as-configured data of deployed assets and their digital twins that are long removed from the OEM’s original PLM database. Subscribe to CMsights at the top right of this page.

Until then tell us what you think by leaving a comment below on whether you believe it is currently realistic to use digital twins to help manage the maintenance of in-service A&D systems?

Receive CMsights

Subscribe to CMsights News for the latest updates from CMstat on Configuration Management, Data Management, EPOCH CM, and EPOCH DM.

Request a Demo

See how EPOCH CM and EPOCH DM support industry standards and best practices in Configuration Management and Data Management.

Follow CMstat

Recent Posts

CMsight Topics

Tom Tesmer
Previous

A Configuration Management Guide for Aerospace & Defense Project Managers
Next

Ten Configuration Management Truths