We all know that technology does not need regulatory help to boldly enable new use cases. But every so often, regulations identify a use case that provides great focus for the technology providers and implementers, and the Military Right to Repair is a perfect example of that.

At Aras, we’ve been watching the Right to Repair trend for a long time since it affects the civilian push for sustainability, supply chain resilience, and digital sovereignty. A good example of it are the Massachusetts and California Right to Repair Acts. We believe that the Right to Repair in any industry directly impacts the strategy of PLM-managed digital threads and how digital twins are derived from them at every stage of the product’s lifecycle.

US Right to Repair bill

The proposed Servicemember Right-to-Repair Act of 2024 (H. R. 1040) states: “The head of an agency may not enter into a contract for the procurement of goods or services unless the contractor agrees in writing to provide the Department of Defense fair and reasonable access to all the repair materials, including parts, tools, and information, used by the manufacturer or provider or their authorized repair providers to diagnose, maintain, or repair the good or service.”

This initiative is a logical consequence of the DoD 5000.97 Digital Engineering instruction. However, while 5000.97 is more of a DoD strategic guidance, the Right-to-Repair Act is a very specific use case critical to US military field operations. And, without the Act saying so, it is obvious that digital engineering and the related concepts of digital thread and digital twin are central to it. That is a significant challenge to DoD and to the tool vendors because it implies the existence of tool-agnostic data repositories with open APIs, standardized and extendable semantics frameworks, and backed by lifecycle configuration management services that are accessible to military servicemembers anywhere, anytime. But more about that la ter.

Why is it essential to the US Military?

The Right to Repair is destined to improve the military’s field readiness and self-reliance dramatically. It also promises to save the Pentagon and the US Government lots of money. Today, a significant part of the military equipment owned by DoD must be maintained by OEMs or other third-party organizations. OEMs often contractually limit DoD’s access to replacement parts, repair manuals, and technical training information. In addition, broken equipment frequently must be shipped from the military field of operations to third-party repair depots that are far away, or third-party technicians must be flown to the equipment in the field.

According to the US Government Accountability Office: “Operating and support (O&S) costs historically account for approximately 70 percent of a weapon system’s total life-cycle cost—costs to operate and sustain the weapon system from initial operations through the end of its life—and include costs for repair parts, depot and field maintenance, contract services, engineering support, and personnel, among other things cost, this inefficiency has a big impact.”

And the inability of the DoD to handle the repairs internally has a lot to do with it.

H.R. 1040 helps solve this challenge for the DoD by breaking OEM monopolies on spare parts, firmware, software updates, and repair handling, leveling the playing field for the US Armed Forces maintenance operations. It also encourages knowledge transfer within the DoD by allowing the military to internally document and disseminate repair procedures.

But are digital engineering tool vendors ready for it?

The impact on the Digital Thread

A digital thread maintains traceability of product information across multiple domains and throughout the product lifecycle to provide contextual relationships between a product’s digital assets. It is key to identifying relationships between the digital artifacts of a product, but the devil is in the formality of the “contextual relationship”. We discussed that recently with my colleagues at Aras, Josh Epstein and Jason Kasper, and identified three traceability characteristics that categorize the formality of contextual relationships. That was very helpful when analyzing the implications of specific use cases like Right to Repair:

1. Traceability for general investigation

Important, but not relevant to the Right to Repair. This is where you investigate any relationship between digital artifacts without the context of a specific system, product, or behavior. An investigation of what’s possible that does not require future reference to what was found via digital thread.

2. Traceability for gaining insight regarding a specific design target

Important, but not relevant to the Right to Repair. This is where you investigate relationships in the context of a system, product, or behavior. Investigation in a specific context may require a degree of reference to what was found via the digital thread.

3. Traceability as a system of record

Key to the Right to Repair. This is where you investigate or create relationships in the context of a particular system, product, or behavior you are designing. All referenced or created relationships must be very formal in terms of configuration, versions, and lifecycle state of the things they relate to.

All three traceability characteristics are critical to the overall success of digital engineering strategies. However, the system of record characteristic is particularly relevant to the Right to Repair use case:

  • Relationships must be specific to configurations and operational contexts. Assemblies, variants, and versions must be explicit because they are not necessarily interchangeable when repairing specific equipment.
  • Relationships and related items must be tool agnostic and can’t involve access to the original authoring tools. According to the Heritage Foundation, the AH-64E Apache helicopter platform is designed to remain a viable combat multiplier beyond 2050. By this time, most, if not all, authoring tools used today will no longer exist.
  • Reliance on highly distributed networks of multiple data repositories is likely not the best choice. This is because of the worldwide communication realities of military deployments and disruptions resulting from active conflicts.

The impact on Digital Twins

This brings us to the specifics of digital twins. A digital twin is a virtual representation of a physical product or system, allowing for testing, monitoring, and improvement by simulating real-world conditions. It uses a digital thread to feed data continuously, enhancing predictive capabilities and optimizing asset performance. In the case of Right to Repair, each type of repair will require a different one.

  • If a mechanical part fails, I will need an interactive 3D model to analyze the problem, including assembly and disassembly.
  • If I need to replace a mechanical part with an alternate created using a 3D printer, I may need a simulation model of the original part to verify and record the part’s mechanical integrity for future reference.
  • If I need to replace an electronic assembly with a functionally equivalent but different alternative, I may need a timing or signal integrity model of the control signal to verify and record system behavior for future reference.
  • I may also need access to a behavioral model of the overall system to verify and record that the repairs do not affect the software’s behavior.
  • and so on…

Each item above calls for a different digital twin that must reflect specific variants, versions, and maintenance history of the equipment under repair. Given the longevity of military systems, platform upgrades and modernizations, system-of-systems interdependencies, and others, it is evident that generating all these types and multiplicities of digital twins a priori is impossible. This is why access to a formal system of record is critical to the Right to Repair use case: it must generate the right digital twin at the right time. The same digital thread must be able to reflect any repairs that were done so that the future digital twins reflect them.

Closing thoughts

Fortunately, PLM and digital thread industry thought leaders are actively discussing the future of the digital thread, which may provide a basis for use cases like the Right to Repair. For example, LinkedIn recently had a fascinating exchange about the “Digital Thread as a Service” (DTaaS). See Dr. Martin Eigner’s excellent and thought-provoking post introducing the concept here. It is a critical discussion, but it fails to address the question of contextual relationships as outlined above. And that question is fundamental when considering specific use cases like the Right to Repair.

If you are a DoD contractor or a digital engineering tool vendor, you should probably pay attention to the Military Right to Repair initiative because, otherwise, over time, you may find yourself on the outside looking in. I don’t pretend to know all the implications, but I firmly believe that what I outlined above is critical and must be addressed in the not-so-distant future.

What do you think? Is the success of the Right to Repair initiative heavily dependent on the proper and complete implementation of digital thread traceability and the formality of relationships? I invite you to share your thoughts in the comments below.

 

Category:
Digital Engineering Digital Thread Digital Twin