Digital Mockup…..: A Collaboration and Configuration Management Challenge

In this post I would like to introduce an all embracing view regarding the purpose of a Digital Mockup or DMU. When you research the topic there are different opinions what a DMU is. It depends where you come from. The AutoVue’s view is that the DMU is the lightweight product representation derived from a 3D CAD model. If you are a vendor of 3D CAD, then DMU is the source product representation created with the CAD application. Wikipedia I believe is pretty close: Digital MockUp or DMU is a concept that allows the description of a product, usually in 3D…. although what is meant with ‘concept’.

A DMU is also a product configuration, consolidating other DMUs, such as structural details, purchased and standard items that are part of the construction in accordance with design specifications. Most publications state that a DMU is a mechanism to create a Digital prototype (or Virtual) and that a DMU allows engineers to design and configure products and validate designs without ‘ever needing’ to build a physical model… well the word ‘ever’ means; until you really need a prototype to for example test fly a plane.

So, a DMU is a 3D digital product representation. It represents the ‘real thing’ i.e. it is what engineers work on and ‘release’ to produce. It may comprise a derived and synchronized lightweight representation to support information consumers that do not have or need a native 3D CAD application or to exchange designs with an external party without having to worry about intellectual property. Although it is not the original 3D CAD application; still, it lets users visualize, animate, check dimensions and tolerances, manipulate, explode, fly through, cut away, and check clearance and interference of parts and assemblies… oh and lastly it is also the source for product documentation for example, part catalogs or product operating manual.

So this pretty well sums it up where we start from… the virtual prototype in 3D CAD that may have dependent representations.

Consulting with several clients in Automotive and Aerospace on the topic Digital Mockup and the purpose of it in the engineering process we talked about several topics and their challenges:

• Collaboration between an organization’s internal teams and external partners.
• Work-in-progress management and the establishment of (Allocated) Baselines.
• Managing different configurations, you may call these product platforms and its derived variants.
• The dynamics of updating, configuration management, design reviews against major schedule management Gates, etc.

Let me home in on each of them.

What I meant with this Collaboration topic is the sharing of the engineering task among teams within an enterprise but also with external partners. These external partners also use 3D CAD and in the extreme case not even the same version or even a different CAD vendor labels. With today’s technology you can overcome data exchange challenges, what remains is the collaboration principles and best practices.

Some of the companies I worked with, stressed the point that the fundamentals of the DMU are the same as with a physical prototype. You cannot just change and replace things. With each change you need to validate its fit for purpose. Also you need to baseline a configuration when you do your virtual tests and record what improvements you applied for your next baseline.

In Aerospace the configuration management plan typically calls for the role of a DMU manager. A person or entity that secures the state and status of the virtual product. This implies, and this is consistent with Automotive, that your Work in Progress, i.e. the engineering WIP, is conducted outside from what is contained in the DMU. Call it a WIP area. To receive into and to move completed work from the WIP back into the DMU is a formal process. Renault for example operates the so called DMDR process and corresponding gate review. DMDR stands for Digital Mockup and Design Review. DMU synchronization is a prerequisite for the gated design review.

To prepare for a ‘change’ to be worked on, any areas in the surrounding ‘assembly’ envelop you need to ‘check out’ or for example the work that you want submit to an ‘external’ party. Once changes are edited or additions are received, validated, verified and proofed you can ‘check in’ these items back into the DMU. Again this is a formal process as there could be several disciplines involved.

When engineering divides its work following a ‘system’ product breakdown and also following a top-down design approach it would reduce team interference challenges. The WIP is what is being worked on i.e. the status working. Automotive is very successful working in this manner and this is proven by today’s relatively short car development cycles, see Wikipedia for car systems example at: http://tinyurl.com/nrawmk. (make sure you press the show button).

In addition to the WIP area there is also an DMZ collaboration area, i.e. the place to collaborate with external partners. Partners would upload contract deliverables here and also download the essential material from the OEM. See my post on Collaboration and the discussion surrounding Sharepoint. The vendor material uploaded would be received in the DMU WIP. Here the correctness and fit can be validated, the same as you would do with a physical prototype. Once all the procedures are completed the vendor material can be loaded into the DMU. In Aerospace these procedures basically is a certification, for insiders almost like a First Article Inspection or a kind of PPAP as with Automotive.

Continuing with the topic Managing Different Configurations, how can Engineering be effective if it does not have capabilities to set a specific Engineering context. It would mean an engineer would not be able to load a specific ‘view’ of the product. If working with a base platform that supports different models then you would not need to maintain different product definition copies for each model. You realize that a Engineering context capability would make the DMU WIP validation and verification more efficient.

Nearing the end of the post, the DMU and the ‘system’ product decomposition would be driven from the Schedule Manager as can be found in my blog category Business Activity Management. So, the Schedule follows the same breakdown as your product. Each of the deliverables would be defined against the car systems example (see Wikipedia link). Many Automotive Automotive OEM still have a challenge to manage the various Design Review gates specifically collecting all the deliverables and freezing the DMU is THE challenge. A frozen DMU implies that certain financial commitments are made and budgets are released and this would mean that from this freezing point going forward all changes must follow a formal change process and each ‘check out’ into WIP can only be accomplished by a formal authorization.

So, with the DMU in a different context, you appreciate that it is more than just a 3D digital model of a product. The processes in support of the DMU are complex and challenging and must be thought through and planned for carefully. More companies are exploring DMU capabilities how it can used to bring bottom line value increasing engineering effectiveness overall.