MiB: Engineering

There is only one thing in the world worse than being talked about, and that is not being talked about. When people profess their strong feelings about a software vendor or technology, it means they care, whatever those strong feelings are. Indifference is much worse, and lack of awareness is simply catastrophic.

There have been countless confrontations around DS, Siemens and PTC products, STEP and JT, and SysML over the years. Yet OSLC has garnered very few Will Smith moments. What is the next step for this noble attempt to create a real-time engineering life-cycle exchange standard?

Speaking of Will Smith, the original “Men in Black” aliens generally exposed their true forms only inside the MiB HQ – which incredibly also served as their intergalactic transportation hub. Otherwise they lived covertly on Earth inside human or animal containers, speaking relevant human languages as required. The MiB are reminiscent of a digital engineering team, as they mix slow and deliberate approach supporting technology progress on Earth with occasional bold action to ensure planetary survival.

The MiB continuously exchanged information and various products with all kinds of humans and aliens. Every interaction was a delicate balancing act. For example, losing a diamond containing an entire universe to a predatory bug could lead to an existential liability.

In our own galaxy of the early 1990s, STEP BREP was a collaborative effort between the CAD/CAM vendors and automotive, shipbuilding and aerospace OEMs to share 3D parts information. Then Boeing steamrolled STEP for machining, and it quickly became supported by all the NC tools. As aerospace OEMs pushed for 3D MBD and long-term archive capabilities, DS explicitly promoted STEP in 2000s to bypass the Siemens-originated JT.

Later on, AP242 superseded AP203/AP214 and added XML support. This allowed users to store product structure data in XML while keeping the geometry in the Part21 format.

PDF became a planet Earth-wide standard for legally binding information exchange because of its immense ubiquity, which in turn originated from its genius functionality, simplicity for end users, and Adobe timely opening it to third-party developers. PDF/A is riding the follow-up wave as a standard for long-term archiving of any electronic data.

A combination of PDF/A and STEP/JT overwhelmingly covers most 3D CAD information exchange for engineering and manufacturing compliance needs. Now, full life-cycle information exchange has become the new frontier.

OSLC wants to do it universally and in real time. It strives to eliminate the need to create and maintain individual connectors between each set of tools. It makes a lot of sense in theory, yet after 15 years of efforts it fails to gain traction, perhaps because it seems too complex and impractical to implement.

• DS with 3DXML and Siemens with PLMXML facilitate life-cycle information sharing within their respective ecosystems, and they provide proprietary APIs for external integrations. As multiple disparate code bases continue to expand and diverge, OSLC implementations lag behind, accumulating more technical debt.
• Lacking support from the major PLM vendors, there are other methods to achieve real time life-cycle data exchange at similar or lower cost, without unnecessary dependency on yet another standard. Specifically, REST API, Swagger, GraphQL, Kafka and Camel are well-tried tools for building enterprise integrations, and taken together with AP242 they seem to take even more wind out of the OSLC sails.

Still, productivity improvements via real-time life-cycle integration between the systems inside the corporate networks and across the supply chain are as relevant as ever. OSLC is a good candidate, if only because it was polished by some very smart people for over 15 years. However, there is apparently little motivation for the the digital thread vendors to enable too much collaboration with competing ecosystems.

In the past, intense OEMs coercion triggered STEP and JT mass adoption, and SysML was just another modeling language – that is, until the DoD became seriously committed to it. Perhaps the only way to make OSLC or its equivalents successful is pressure coming from the aliens, MiB or both.

In the meanwhile, we at Senticore are particularly interested in the creation of what we call “80% as good” automated life-cycle mapping and code generation mechanisms using a combination of multi-modal LLMs.

Want to know more? Please disclose your real shape and planet of origin, and we will be happy to talk in your language.