As industry moves toward Model-Based Definition (MBD) and the Model-Based Enterprise (MBE), what will hold us back? The digital tools of CAD/CAM/CAE/PLM are continually improving. But what about the ways that we connect product geometry and Product Manufacturing Information (PMI) to the “highway” that goes from design to manufacturing to inspection and back again? Specifically, as we become model-based, how will the rich details embedded in CAD systems speak to our production environment?
Well, we’ll need standards such as STEP 242 and its subsets so that there are pathways of general agreement on how digital vendors configure their authoring systems to send machine-readable Semantic PMI downstream. Most do a good job of setting up Semantic PMI in their native CAD for internal applications such as CNC programming.
In properly managing and controlling their design creations, however, these different vendors generate model outputs in file formats that are “flavored” to send what they “make” in the way that is best written for their systems—not by how different programs across the supply chain might want to receive or be able to interpret that data. This is one area where the vision of fully automated processes still hits a rope bridge and needs manual intervention.
Weak points in the data thread
I grew up in a manufacturing environment, running machine tools as a young man then moving into CNC programming and transitioning into a manufacturing engineer doing manufacturing and design engineering. Looking at the needs of manufacturing folk, one recognizes that their daily work centers on following standards and methods. Yet we didn’t always follow standards explicitly, and many still don’t. We used the parts of the standards that made sense: those that didn’t cost extra money. If something in a standard adds needless cost to their product cycle, they’ll often ignore it. There are even aspects of STEP 242—a very good standard—that will be disregarded because CAD systems evolve, improve and innovate separately from each other as well as industry standards. Codes and PMI descriptions can only try to bind them through a uniform language.
Between cost-based shortcuts taken on the factory floor, flavored STEP, and the organic challenges of writing standards to fast-changing CAD innovations, neutral third-party interoperability platforms now play an important role in negotiating automation for the MBE. The best of these platforms take the Application Programming Interface (API) from each CAD vendor and ensure that individual models developed in the supply chain conform to final Master Model requirements. This neutral-platform approach can also check for PMI conformance and help turn those rope bridges into digital connectivity, necessitating less manual oversight.
One machined through-hole, different digital expressions
I had a translation situation where a design required 24 complex, counter-bored holes. Each had a clearance hole and clearance counter-bore holes and sizes, depths and quantities to communicate. The originating CAD system could not put the complete text for those operations in its PMI automatically. In a related project, two vendor CAD systems had different ways of expressing cylinders and seams. Each half of the cylinder design needed to have associativity added manually to the PMI.
In achieving design-to-production automation, we need to avoid remodeling at the CNC stage and in other production domains. The “as-designed” model needs to be the same as the “as-manufactured” product. The MBD initiative is meant to foster a Digital Twin for each production example that is a unique customer offering. Digital twins reflect a single truth for the shared models used in design, analysis and production. Remodeling away from the original—for toolpath generation or to better interpret design intent, or influence manufacturability—causes profound problems for production repeatability and archiving.
Remodeling or manually re-adapting geometry to interpret Semantic PMI for machine use is a critical problem for industry today and a barrier to the model-based enterprise. Too often, Semantic PMI—the text, symbols and color-coded instructions inside CAD that machines read—is not fully associated with its related geometry. In cases where the machining instructions are moving between different CAD platforms, all similarly dimensioned holes, for example, may turn out in actuality not to be the same. The operational context of what PMI is supposed to mean and communicate in these instances is not the same either. Here, a manufacturing engineer intercedes and decides what has to be done to machine that hole according to what the design team defined as requirements.
Universally readable, machine-ready PMI that is fully associated to it geometry is the key to automation.
This last statement does not mean that the PMI functionality we have today can’t or shouldn’t be used yet. It is in use. There is enough value in what exists today to be reused by humans when setting up work cells and the process definitions needed for inspection systems. I know that the value of Semantic PMI will continue to grow until a part or assembly will contain and communicate all required process definitions from within it.
Currently, we have pockets of automation available to industry—and usable software routines for automation are continually being created and tested by the government, software companies and universities. Some of those standards, as I indicated, are ahead of today’s software functionality. Other times existing standards will need some modification as software development finds new and better paths.
Third-party, neutral platform translations and repair
Although standards like STEP are supposed to provide unambiguous directions to their use, we as humans who create and interpret these standards still manage to create software code that disallows complete interchangeability between CAD systems. In time this will improve. Above and below are examples of how designs need interpretation and correction for both production and translation within the supply chain.
Image 1 shows a “Visual Semantic” relationship between PMI and associated geometry. The associated geometry is the two holes (in green) separated by a void within the part. This is the reason for the designation of “Continuous Feature.” I was creating a translation test that looked at using a dimensioning and tolerancing symbol for “Continuous Feature,” or CF, inside a Diamond shape [Image 2]:
It was not possible to make the diamond shape in the CAD system that was in use. Instead, I spelled it out in text. A human will understand Continuous Feature and complete the operation even if the phrase was misspelled. Nonetheless, this edit represents a break in the automation path.
As far as Semantic “Meaning”:
- The callout Diameter .313 +.002/-.001 THRU; the text “THRU” was typed in by the designer, therefore not guaranteed to have meaning on the typed-in portion.
- The text “(CONTINOUS FEATURE)” was also typed in by me. There should be a symbol CF embedded inside a diamond shape. This symbol should have been entered based on a menu selection.
Associativity of Geometry to PMI
When you create PMI, you select one or more entities to get semantic size-definition. After that creation, you might need to associate more geometry to the PMI for a proper Visual Semantic relationship.
This is done in CAD A by editing the Annotation Feature and defining the relationship of geometry to the PMI callout [Image 3]. (My nickname for this is the “Bucket of Associativity.” Other PMI items can be manually associated with their geometry here.) The issue with using this Bucket of Associativity is that a user can drop anything into it, so it could be error-prone.
Different CAD systems can define geometry and operations in individual ways. The geometry in “CAD A” [Image 4] for example, highlights ½ half of a hole. CAD A’s definition of a simple hole is two ½ cylinders.
In CAD B [Image 5], when selecting a hole surface for PMI creation, the entire cylinder highlights. In CAD B a simple hole consists of one cylinder. The Associativity Bucket in CAD B is within the selection dialog “Associated Objects.” More entities can be added to this bucket, like the other hole for the continuous feature.
In Image 6 you can see the associativity between PMI and geometry completed (I used the Associativity Bucket to complete this):
- The Hole size and tolerance is machine readable
- The Through (Two Walls) could be machine readable if the machine could understand that typed-in text.
- The FCF (Feature Control Frame) should also be machine readable.
Also illustrated in this picture is another way to define a hole through two surfaces: here defined as “Through (Two Walls).” This begins to show the flexibility a designer has to define the same condition two different ways—illustrating the need for standard methods across CAD systems and designers.
Third-party interoperability & translation is improving the bridge to automation
Since the 1990s, when a new generation of “associative” CAD modelers emerged, vendors of digital authoring systems knew that their native environments were the best way for them to create uniform, connected toolsets for the multi-disciplinary engineers who worked apart in design, analysis and manufacturing. They forged ahead with better and better integrations between CAD/CAE and CAM. Today, the digital uniformity achieved under the term PLM is very strong. But there exists considerable parity between vendors, and manufacturers and buyers of PLM continue to choose what they feel is the best-in-class software from a field of innovators. This creates issues of product definition and model transfer for OEMs and their supply chains that MBD and STEP are designed to reduce.
Third-party interoperability and translation companies, when working with direct CAD APIs, can referee in a marketplace of competition, change and differences. Interoperability platforms can recognize that CAD A creates its cylinder geometry without seams, while CAD B and CAD C companies use seams. A translation from one system to another can know that the OEMs target model requires associative seams and provide that feature automatically. Faulty or missing Semantic PMI can be identified and often fixed automatically or called out for the manufacturing engineer, as my examples have shown. Neutral, end-to-end Product Data Quality (PDQ) platforms manage a great range of solutions tailored to OEMs, much like the PLM environment that they sit within.
There are currently pockets of automation between design, analysis, production and inspection. Codes and links are customized in manufacturing specific to projects and equipment. Experts intercede at various informal points in an ad hoc collaboration. They institute feedback and review loops differently in each company but are aided by lightweight viewable formats such as 3DPDF, JT or HTML5—at home within PLM. These are the tools of MBD.
Direct, machine-readability inside today’s modeling approaches is essential to helping automate the design-to-production highway. Neutral interoperability software suites are working with STEP and other protocols—and deeply inside PLM—to firm up the bridges to a model-based enterprise that will deliver quality, speed, cost benefits and customer satisfaction.