The Future of Electromechanical Design

Examine most products today and you’ll likely find both electrical and mechanical components. The cell-phone and automobile industries are at the forefront of this trend, with other industries such as medical, industrial, and aerospace close behind.

That sophisticated electronics are being included in ever-more-complex mechanical form factors dictates that the two formerly separate design disciplines — electronic CAD (ECAD) and mechanical CAD (MCAD) — should become more harmonized and the line between each should become blurrier.

It is no longer acceptable or affordable to perform the design and simulation of different domains in isolation from one another. In addition to considering the core design of the physical PCB and the mechanical package itself, designers must also study the downstream effects of the environment in which the final product will operate.

ECAD-MCAD collaboration
Although there has been collaboration in some form between ECAD and MCAD for many years, different media, formats, and standards have blunted its effectiveness. During the early days of electronic design, most collaboration was through paper, whether formally — such as an ANSI-compliant drawing — or informally, as with notes and sketches passed between engineers.

This method progressed to that of exchanging electronic data formats, such as DXF, which facilitated the transfer of 2D data between ECAD and MCAD. The biggest limitation here is that DXF is simply a dump of nonintelligent and graphical data of little use in the other domain. Thus, the DXF format offers little collaborative value.

The next step in collaboration came with the advent of the intermediate data format (IDF). During the early-to-mid 90s, David Kehmeier, with Mentor Graphics at the time, realized that a more-intelligent data format was necessary to preserve the integrity of design data. IDF (1.0, 2.0, and 3.0) progressively improved the amount of data that could be transferred back and forth between ECAD and MCAD.

These improvements meant, for example, that ECAD and MCAD could share board-level objects such as board outline, mounting holes, and route-and-placement keep-outs, along with part-placement attributes such as X-Y location, rotation, and the side of the board on which attributes were placed.

Through IDF, the mechanical engineer could predetermine the board outline and send it to the ECAD system as the starting point for the PCB designer. After placing the components on the PCB, the MCAD designer could move the electrical parts if necessary. Multiple iterations could take place until both designers agreed upon the initial boundary conditions. This approach ensured that connectors and other electromechanical parts such as switches and LEDs were correctly aligned with the mechanical package.

Additionally, the MCAD designer could visualize the ECAD intent with regard to electrical-part placement in relation to the mechanical-design data. This collaboration allows the substitution of 2D electrical parts with more complex assemblies created in the MCAD application.

For all these improvements, though, a significant limitation still remained in that the data was nonincremental. A file was just a data dump, and reading an IDF file usually resulted in throwing away everything previously created in the design and replacing it with the full content of the IDF file. This might have been acceptable at the early stages of the electromechanical definition but it became impractical as soon as the PCB design contained routing data. Consider having to remove all the copper traces that had been painstakingly routed by hand to ensure signal integrity and then starting over again because the mechanical profile had changed to satisfy a new pricing and packaging constraint.

The next logical step for ECAD-MCAD collaboration was for PCB designers to view the mechanical data, not as 2D, but as a full 3D representation at the same time they placed and routed the PCB. More recently, some ECAD vendors developed their own 3D “viewers” so that either IDF data could be represented in 3D, or as in Mentor Graphics’ case, a 3D view of the PCB could be generated automatically from the PCB database itself.

The 3D viewer also supports the import of complex MCAD models for both the electrical parts and the mechanical-packaging data itself. Thus, the PCB designer can affect 2D placement based on real-time 3D visualization and collision checking. However, this scenario is still not true ECAD-MCAD collaboration. Data may be read from one direction for improved visualization, but ultimately the host application cannot exchange design intent based on the changes made as a result of visualizations.

Conversely, the MCAD designer can also benefit by having a better view into the electronic PCB through a viewer. The same limitations apply though. The MCAD user can make better decisions, yet is unable to communicate them effectively to ECAD teams.

Addressing collaboration challenges
What was needed was a truly collaborative and innovative product-development process between electrical and mechanical design so engineers could communicate incremental change(s) at any time during the (shortened) design cycle. Also needed: Teams must be able to collaborate when a problem is identified (such as having to change the mechanical profile during PCB placement and routing), rather than at design hand-off.

So, what things do new collaboration processes entail? They include:

Incremental data exchange, which means that domains should only communicate proposals for objects that have changed and affect the other discipline. Don’t force an entire database exchange. In addition, let the designers determine the objects for collaboration.

Propose the changes; don’t enforce them. Empower the design-domain experts to make the final decision. For example, an MCAD designer has limited knowledge about signal and power-integrity constraints and thermal characteristics of the PCB. And a PCB designer does not understand how proposed changes to the enclosure can affect its manufacturability.

Record changes. Track the history and description of what changed, when, and who initiated the change.

Support both synchronous and asynchronous communication, for instance, real-time messaging and file-based transfer. Designers might be on the same shift in the same country or different shifts in different parts of the world.

These proposals cannot be implemented in isolation. So Parametric Technology Corp. (PTC), Needham, Mass., and Mentor Graphics, Wilsonville, Oreg., partnered to develop software supporting the methods. One goal was to support an open standard so any ECAD or MCAD developer or OEM could develop their own collaboration around it.

The ProSTEP iViP Association sponsored the process of defining a new ECAD-MCAD collaboration format. The format, officially titled “PS5 ECAD/MCAD Collaboration” borrowed heavily from existing STEP standards such as AP210 (Application Protocol for Electronic Assembly, Interconnect and Packaging Design) and AP214 (Application Protocol: Core data for automotive mechanical design processes).

In the Spring of 2008, Version 1.0 of the ProSTEP ECAD-MCAD Collaboration schema was published. Shortly afterwards, PTC and Mentor released products that used the schema and supplied the industry’s first incremental collaboration capability to their mutual customers. Additional ECAD and MCAD suppliers will follow suit. Version 1.2 was published in April 2009.

Highlights of the schema besides supporting incremental data exchange include:

A flexible and extensible XML data model.

A baseline to establish a collaboration session.

Objects referenced by unique IDs (UIDs) include ownership status, thus supporting true collaboration on objects such as regions and mechanical holes.

A communication protocol for all collaboration objects.

In detail, the schema facilitates the proposal of changes, which can be initiated from either the ECAD or MCAD domain. Either the PCB or mechanical designer can decide what changes to accept, reject, or counterpropose based on their domain expertise. When they agree on a change, all databases can be synced so everyone is working on databases that reflect real-time decisions.

A collaboration example
Consider a scenario in which a PCB designer has a thermal-analysis tool to analyze the heat management of the PCB by itself. The designer can do an initial analysis of component placement to avoid an obvious heat-buildup situation. However, analysis of the PCB(s) in the full product enclosure, including fans and heat sinks, is typically a task for the mechanical designer using computational fluid dynamics (CFD) to analyze air flow. This method results in an obvious disconnect.

In contrast, an approach called concurrent CFD lets engineers perform CFD without leaving the MCAD software, using interfaces native to the MCAD software. An example is Mentor’s FloEFD product, which can be embedded in PTC’s Pro/Engineer. The approach uses several of the industry standards described above.

Here, in the initial stages of product design, the PCB designer might use an en-masse data-transfer standard such as IDF to send the complete new-component placement information to the MCAD system. Later in the process, the PCB designer could propose a part placement or a component number change. This type of incremental collaboration requires the use of the ProSTEP EDMD standard to initiate a bidirectional negotiation between the disciplines prior to accepting the change.

The result is a full analysis of the product, including the proposed-component location change to the PCB. If the change is acceptable to the mechanical engineer, then the ECAD-MCAD collaborator communicates the okay back to the PCB designer and the change gets reflected in the respective databases.

The future of collaboration
Version 2.0 of the ProSTEP ECAD-MCAD Collaboration schema will be published in the first quarter of 2010. It supports additional collaboration objects such as copper shapes, component identifications, and general annotations. In the future, the format will evolve as advances in industry technologies dictate. Already identified for inclusion are bond wires, support for cavities, and stacked and buried components.

Over the next years, the focus of ProSTEP will be, among other things, to support an “Implementer Forum” to provide tools to help more vendors and OEMs adopt the standard. Tools will include:

An Implementer Guide for software programmers of the ECAD/MCAD-Collaboration schema. The guide will provide essential information on how to effectively implement the schema.

Certification Guidelines. These are schema validation tools that provide a vendor-independent validation environment, tests for verification, and a neutral platform for interoperability testing.