Bridging the ECAD-MCAD gap
New tools and standards encourage communication between the electrical and mechanical domains, says Pawel Chadzynski.
Most major electronics companies have separate electrical (ECAD) and mechanical (MCAD) design organizations. Efficient collaboration between these teams throughout the PCB design process can significantly reduce cycle times, lower the risk of re-spins, and improve quality.
The first challenge to creating an effective collaborative framework between the ECAD and MCAD domains lies in the differences between the tools and methodologies that each uses. They have evolved separately over 40 years by focusing on the design issues and customer requirements specific to each area. Consequently, the two worlds have databases and design object representations that are very specifically tuned for their respective domains. These differences make design transfers between ECAD and MCAD difficult and disruptive to the design process.
Secondly, there is the challenge of enabling collaboration by presenting information in a form familiar to the users. Forcing designers to adopt new, unfamiliar GUIs and different languages just to use collaboration tools will significantly increase the training required and thus reduce the adoption rate. Only widespread use encouraged by ease-of-adoption will produce the desired rise in productivity.
Lastly, there is the challenge of managing and tracking the collaborative data. The proposals/counterproposals, associated user comments, and references to the individuals involved in each collaborative exchange constitute a very valuable part of the design’s intellectual property.
Legacy limitations
Whenever parties communicate and exchange data, collaboration happens, even if it is not particularly efficient.
One example of such limited collaboration is the IDF exchange format. IDF files are typically used at two specific points in the PCB design process. At the outset, IDF is used to communicate PCB mechanical details from an MCAD tool to a PCB layout tool. At the end, IDF is used to communicate the final component placements from a PCB layout tool back to an MCAD tool.
The format is effectively used as a full data dump since there is no way to identify incremental design changes–with the exception of the component placement. As a result, IDF-based collaboration requires additional clarifications in the form of handwritten notes, emails, and phone calls. This is time-consuming and error-prone.
Cross-domain viewers are another example of limited collaboration. MCAD viewers allow electrical engineers to view PCB assembly in a 3D enclosure designed in a MCAD tool. ECAD viewers allow mechanical engineers to see the location of vias, routes and planes just as they appear in a PCB layout tool. This gives designers an opportunity to spot obvious errors visually. However there is no opportunity for a more interactive and incremental data exchange between the disciplines.
Specifying a standard
Given this backdrop, 2005 saw a group of suppliers and users partner with the ProSTEP iVIP Association to develop standards for formal ECAD-MCAD collaboration capabilities, based on the concept of incremental change.
The first step was to address incompatibilities between the ECAD and MCAD data models. Instead of modifying the underlying models within the existing ECAD and MCAD tools, the partners prioritized a subset of objects that were most likely to be changed during concurrent design of an enclosure and a PCB (e.g., mounting holes, board outline). Each object’s name, properties, and constructs were specified in a mutually agreed and tool-agnostic form so that both domains could fully understand them. The resulting Electrical Design-Mechanical Design (EDMD) schema was the first true interchange format to represent incremental design changes (one object or one attribute of an object at a time) that both domains could not only view, but also test and update in their existing databases. It formed the beginnings of a common ‘conversational’ language covering the most important collaboration objects.
The partners also settled on a collaboration interaction protocol; the standard use cases; and the relationship of the collaboration tools to the native ECAD and MCAD tools (e.g., who owns an object, what constitutes an ‘accept’ or a ‘reject’ for a change). This was approved in Spring 2008 as a ‘go forward standard’ (ProSTEP iViP Recommendation ECAD/MCAD, PSI 5), open to all ECAD and MCAD suppliers. The related documents can be accessed on the Internet at http://www.prostep.org/en/downloads/recommendations-standards.html in the section titled ‘PSI 5 – ECAD/MCAD Collaboration’.
Delivering the standard
Two suppliers, PTC and Mentor Graphics, have developed and delivered the first ECAD-MCAD collaboration capabilities in line with the specification. These tools address collaboration objects judged by the partners as having the highest priority with respect to the specified use cases and domain-friendly designer interaction.
Given the global nature of electronics design, where ECAD and MCAD organizations are often geographically dispersed, the use cases address both synchronous and asynchronous collaboration modes.
During synchronous collaboration, it is assumed that both designers are online and can immediately respond to change proposals. An analogy here is communication in an Internet chat room.
For asynchronous collaboration, the changes are stored persistently and presented to the collaboration partner at the appropriate time. The obvious analogy here is communication by email.
In the future, a typical one-to-one use case should also allow one-to-several, and several-to-several use cases (i.e., more than two participants).
Collaboration is not an event but a process. Seldom does a designer propose a change that is accepted without comment. More often, a change is proposed and either rejected outright or a counterproposal made, beginning a negotiation. To facilitate this process, the PTC and Mentor collaboration tools have the capability to ‘sandbox’ proposals (allowing a temporary instantiation of a proposed change). Any change is only permanently made in the database when the negotiation process is complete.
Another feature of the collaboration tools created by PTC and Mentor is that each maintains interface characteristics that are similar to those in the already available software for each domain. Graphics, options, and menus use familiar terms from other tools so users do not have to learn entire new languages or interfaces. For example, Figure 2 shows how one collaboration tool retains a similar appearance and framework to Mentor’s Expedition Enterprise software. Figure 3 shows the equivalent environment within PTC’s Pro/ENGINEER family. Retaining such familiarity will improve the adoption rate.
Finally, PTC and Mentor collaboration tools allow details of the collaboration to be tracked, saved and referenced by anybody within the organization during the active design and after it is completed. This provides enterprise-wide access to what changes were proposed, what comments were provided, and who approved what, when and in which domain.
Reaping the benefits
True collaboration across all disciplines involved in product development can greatly improve design efficiency, boost productivity, reduce errors and cut time to market. Capabilities now exist in the PCB space that enable collaboration between electronic and mechanical designers beyond the IDF-based exchange of a complete design and beyond what has been offered by standalone viewers.
These capabilities provide for a bi-directional communication of incremental changes through a new industry standard data format and communication protocol, all achieved in a way that preserves the competitive freedom of the respective design tools.
Based on users’ initial responses, other ECAD and MCAD suppliers are expected to adopt this open standard, thus benefiting the entire electronics industry.
Pawel Z. Chadzynski is vice president, Product Management at PTC. More information on the company’s Pro/ENGINEER Wildfire 4.0 ECAD-MCAD Collaboration Extension is available here.
