ECAD-MCAD Collaboration - Bridging the Communication Gap
Table of Contents
Let’s face it, there are things that we do the same way every day, simply because ‘we have always done them that way’ and we are used to them. Due to schedule pressures and outside demands, there is rarely time to think about how to make these things better, never mind try to actually implement something new. This makes the motivation to invest in exploring different methodologies challenging.
Our general tendencies lean more toward continuing to work with what we have and avoiding risk vs. looking at new ways that could lead to more productivity, less manual intervention, and faster time-to-product.
ECAD-MCAD Collaboration falls squarely into that bucket. The main reasons this process tends to suffer is, quite frankly, a general lack of information regarding what options are available, the perceived amount of work it would take to implement and/or coordinate processes and acceptance across two typically separate product domains—which can make the task seem near impossible.
The saying ‘The journey of a thousand miles begins with one step’ (Lao Tzu) readily applies here, as defining a targeted, phased approach, knowing where to focus, and keeping the end in mind will help you yield measurable benefits in the end.
The need to easily share and validate data between design teams, wherever they reside, is becoming much more important than it was in the past. Long gone are the days when the person or team you worked with sat across the hall or even in the same building. As a result, looking at a better, more reliable and efficient way of ECAD-MCAD collaboration is going to be important in helping to bridge that divide.
Let’s take a look at some information, current methodologies, and alternatives that may help with the day-to-day data exchange while also addressing issues such as quality-of-results, reduced prototype spins, and better overall communication.
Statistics show that design verification is 60%-80% of the overall design cycle time due to the manual communication of engineering changes during the review process.
In addition, more than half of today’s complex designs must be redesigned because of errors found after prototype designs are built and verified.
Most companies rely on IDF, DXF or STEP files for data exchange today.
While these methods have been in use for some time and do work, they also require that the entire database, along with associated README files and marked-up PPT’s or PDF’s explaining what was changed and where, be sent back-and-forth during each proposal. Since these files are disassociated from the actual data that is being shared, information is frequently missed, and errors often can and do occur.
Other issues include:
The design process generally continues while waiting for feedback on the proposed updates, i.e., the design may be outdated immediately after changes are sent
Questions regarding proposed changes are typically communicated via email, voice or direct interaction and are generally not documented or retained
Lack of full traceability regarding who, what, why and when the changes were done
With no way to clearly validate and compare both the MCAD and ECAD databases prior to fabrication and assembly, critical issues can easily be missed.
In 2006, there was a new standard that was developed to address the issues that were associated with the existing methodologies. Named EDMD (Electronic Design Mechanical Design), it was formed as a part of the ProSTEP iViP committee and is a standards and process-based, STEP affiliated collaboration methodology using the ‘.idx’ file format.
The benefit this brings over IDF, STEP and DXF files is that it enables incremental data exchange, i.e., the ability to collaborate on only what was added, changed or deleted vs. exchanging the entire database each time. By assigning unique IDs to each item contained in the design, such as the board outline, slots, holes, components, heatsinks etc., the .idx file is able to track associated updates and enable traceability of those individual objects.
The information is displayed to the receiving end in an easy to read format that then enables you to:
Collaborate on only database objects that have changed
Visualize the ‘as-is’ state vs. the ‘to-be’ proposal prior to implementation in the database
Electronically Accept/Reject updates
Communicate, retain collaboration history and traceability directly from within the .idx file regarding who proposed what change, when, and why
Figure 1. Example of incremental part exchange
In addition to part interference checking, copper traces, silkscreen, solder mask, and ‘other’ board layers can be communicated to MCAD for hole-to-copper clearance verification, and allow for full thermal, stress and various other simulations that are typically done in that domain.
Part mapping is done either via a standardized ECAD-MCAD part name or via a mapping file that relates one to the other. You do not, however, need to have full, detailed MCAD models in order for this process to work. You can choose to either use the default ECAD length, width and height for all of your parts, model ‘critical’ components (connectors, heat sinks, etc., and leave ‘generic’ parts (SOICs, discretes etc.) undefined or, fully define every part if you require a more accurate representation.
Figure 2. Three examples of part mapping detail options
It is also important to ensure your ECAD library parts and MCAD part models are developed and aligned from both an orientation and origin perspective, e.g., if MCAD uses center of gravity for a connector and ECAD uses Pin 1, then alignment issues will occur.
All that said, EDMD data exchange while better, is not perfect. The one important thing to note in order for it to work properly, is to understand that it is a process that requires process definition and training on both the ECAD and MCAD sides to guarantee success.
While EDMD seems to be gaining in popularity, people who adopted it have started asking ‘Why do we need to rely on and manage the ECAD-MCAD collaboration process via a file-based transfer method?’
Good question! As products and processes become more interconnected, companies like Altium are leading the way by looking at more seamless ways to collaborate. By providing a dedicated environment that lives in the MCAD realm, the board and 3D mechanical assembly can be linked as one holistic database and data exchanged via a ‘Push/Pull’ process, eliminating the need for file-based transfers.
Figure 3. Example of integrated ECAD-MCAD Design Environment
Since PCBs are now core components of almost all mechatronic assemblies, they need to be designed as a part of the whole product context and not in their own, isolated environment.
Regardless of where you are now and what direction you want to go in, keep in mind that:
Existing data exchange methodologies will be supported for the foreseeable future
While change is disruptive and takes time to implement, it could provide greater long-term benefits
You must have both a fully documented implementation and roll-out plan to ensure full adoption and success
Whatever you decide, be sure to investigate and evaluate what would work best for your particular organization and situation, as what works well for one may not work for another.
You need design software that unifies ECAD and MCAD features, making collaboration easy. Only Altium Designer® integrates these critical features into a single design platform. Have more questions? Call an expert at Altium.