Getting in deeper with Tom Gill

CIMdata defines a bill of information as:

“A bill of information is a superset of a bill-of-material (BOM). It includes all the item-to-item (parts, documents, process definitions, etc.) relationships and structure important to defining a product’s components and related processes. The BOI includes all relationships among the product’s various components—that is, all mechanical, electrical, software, documentation, formulaic, physics-based, and process-related aspects. It also includes all requirements, quality, test, validation, PMI, and other information associated with the product and related processes. The bill of information is a core part of a product lifecycle management environment.”

And the digital twin as:

“A virtual representation (i.e., digital surrogate) of a physical asset or collection of physical assets (i.e., physical twin) that exploits data flow to/from the associated physical asset(s).”

A digital twin is based on the concept of a bill of information (i.e., you need a bill of information to create a digital twin). In the most formal sense, a digital twin must have a physical instance. Furthermore, a digital twin is also able to simulate the product’s physical behavior completely whether driven from simulation input or operational data from the field.

A bill of information can describe a superset of products and many different product configurations can be derived from a single BOI. A BOI is a virtual representation of a product that CAN have a physical instance, but does not have to since it starts its life well before the physical item comes into existence.

The critical point is for businesses to have a strategy to manage the complete product definition to help produce and support products more effectively.

There are many dimensions of complexity growth that could be discussed but given the time available I’ll focus on two.

As complexity grows its impact is often a non-linear increase in resource requirements, mainly people. Adding people adds cost in wages, and often impacts the productivity of existing staff as they provide on the job training that increases organizational stress and adds risk especially to timelines.

Design anywhere, Build Anywhere—Distributed production and supply chains are common in most production environments. In the case of internal multi-site manufacturing, factories are almost always different. When a new factory is configured, it is designed to leverage current theories, technologies, and equipment. Even simple differences like overhead crane capacity, or pick and place equipment can cause production differences. Factories may be in different countries that have different hazardous material regulations and different supply chain configurations (i.e., different suppliers for the same commodity component). Each site may have a unique manufacturing process plan and may require different components. Compare this situation with a vertically integrated single site manufacturer, the complexity is much greater for the former.

With the rapid growth of IoT, and continuous growth in competitive pressure, CIMdata has seen a growing interest in service and after sales-revenue. To improve customer satisfaction, the OEM has to execute well as they are often trying to take business from established providers. Furthermore, the risk from customers being shut down longer than necessary can degrade the customer relationship. A key enabler for service is keeping the as-maintained configuration current. Often circuit boards in industrial equipment are serialized, calibrated, and in regulated environments validated items. When a change is proposed, the impact on parts depots and in-service configurations has to be understood to effectively approve and implement a change. This is obviously much more complex than connecting an EBOM to an As-planned and As-shipped MBOM.

These types of complexity exist throughout product lifecycles from requirements management, the different design disciplines such as software, mechanical, electrical, electronic, etc., and the various functional domains within companies from marketing, sales, and finance through engineering, manufacturing, and service.

The key to reducing impact is integrated data. Ideally the data is on a platform that improves data accessibility, but legacy point-to-point or enterprise service bus-type integrations also work fine, albeit potentially with less robustness. The integration needs to start from the component supplier or distributer where they publish appropriate meta-data about the product’s lifecycle state. Key lifecycle states include “superseded by” and “end-of-life.” The company’s enterprise IT solution environment, and usually its PLM solution, need to consume notifications and compare the change against as-designed, as-planned, as-shipped, and as-maintained BOMs, as well as released components in both PLM and in physical inventory.

With the impact of component changes identified as they happen, companies are able to systematize their component obsolescence strategy. Automated problem reports and change requests can be initiated with due dates set to critical supply change dates published by the supplier. The changes can then be processed by the appropriate staff. This systematization and automation will minimize the elapsed time to address component obsolescence and since the change dates are well known, escalation rules can be applied to ensure that critical issues get appropriate attention thus minimizing negative impacts.

There are a wide variety of use cases where virtual and physical structures of products affect software. Again, given the time available I’ll focus on one, ensuring that the correct version of embedded software will work on a specific product configuration.

Within industrial companies, CIMdata often sees ECAD/EDA environments run as silos. The embedded software groups are small and develop programs using low-level languages and only loosely follow a software development lifecycle. The software is developed in a silo, and an executable is added as an item in a BOM, sometimes tied to an EPROM item. In many cases software code is copied and edited for each variant, making validation testing difficult, if not impossible, especially as electronic components on a board evolve over time. Unfortunately, equivalent components aren’t always truly fully equivalent leading to differing signals that can cause embedded software to behave differently. Being able to simulate and test the variations of software and hardware is critical to successful change execution.

When a proper XBOM environment is put in place to track all critical information structures, the exact configuration of hardware and software is known, and dependencies identified. Appropriate software developers will be included on change requests and they can determine the level of software testing needed to assess if existing software needs to be re-tested and/or changed. This is much more efficient than finding out the software will not work when it is loaded on the updated PCB or product.