Electro-mechanical design team collaboration: new tools help global design teams meet time-to-market constraints.

Regardless of the industry segment, today's consumer products nearly universally follow the trend of greater complexity in a smaller package. In this scenario, the electronics must not only meet the electrical guidelines, but also must meet specifications driven by usability and appearance. Design is no longer a single team task. Global design teams are part of the footrace to reach market windows on time. Parallel design activities are key to winning the competition in a world of products with ever-shorter lifecycles. Adding external design partners as well as outsourcing services for production requires new ways of design collaboration. True collaboration removes compartmentalization of responsibilities and enables cross-domain cooperation as the new business model.

However, this new design methodology is not really reflected in current CAD design systems. Currently, CAD systems are segregated between electronic design and mechanical design. ECAD defines the design process for PCBs, and MCAD defines the enclosure design in which this PCB is mounted.

As both design domains have become more sophisticated and specialized, systems have been developed for each, and the gap between the two disciplines has widened instead of narrowed. This has led to increasing design team communication problems and inefficiencies during product development that cannot be addressed with either existing interface standards or paper. The problem only gets worse with today's trend toward the globalization of companies and the increase in design and manufacturing outsourcing. The most used collaboration method for fast results is still a common meeting where the recognized problem gets pointed out.

Explaining by pointing a forefinger at a display or drawing is the most common method of cross-discipline communication. During this process, those involved are moving from one system to the other, and each designer shows possible solutions using his system, and is influenced to try other options by the cross-domain partner. Working in a CAD environment is preferred since it allows recognition of issues that can arise due to poor decisions in the process. This process is possible if both partners are working in the same building or site, but for a global team, travel cost and time restrictions in many cases prevent this approach.

Moving the Manual Methodology Toward More Automation

Mark-up and red-lining is one way the industry has addressed this problem. But it does not provide direct feedback for the intended change. Synchronization of changes requires strict workflow guidance. But still, inconsistencies are discovered too late in the process in many cases. The result is that each partner works for some time on the assumption the requested change will be executed, and that can cost additional time.

Another option is working with one system that represents both domains. But significant interdisciplinary training is needed to ensure that such a system is fully utilized in both domains and inadvertent changes are prevented. Even by adding cross-domain knowledge, the wall between the domains is not significantly lowered unless the corporate organization is altered to support the cross-function model.

CAD tool designs have further opened the void by becoming more specialized. Today, ECAD and MCAD systems are designed to give the highest performance and handle all aspects of the specialized application. Therefore, unneeded information used for the other domain has been eliminated, and the systems are subjects of totally changed design paradigms. In simple words, MCAD design tools cannot be used to represent and show electrical functions, and ECAD design tools do not allow the design of mechanical elements and assemblies.

However, connectors still must be designed onto PCBs so they do not mechanically interfere with other components or traces. Applied clearance models for interference checks and electrical isolation insurance are not really compatible and can be better solved in the native CAD environments, which are specialized to perform either the mechanical or electrical inspection.

While the current ECAD and MCAD systems have higher performance and richer feature sets, collaboration between both worlds has been treated like the ugly stepchild and is reduced to bills of material (BOM) integration and limited or restricted to file transfer. For data exchange, interfaces like DXF, IGES, EDI or IDF are used, but they don't allow design updates in a selective or incremental way, nor do they identify the selected objects by name or owner. Specific design elements such as mounting holes in some systems cannot be distinguished from each other. For shared CAD objects, synchronization mechanisms are completely missing. Unintended changes in one system because of an incorrect grouping or an accidental "include" in a movement operation are sometimes only recognized once a prototype has been built. The solution to these limitations is an interface standard.

[FIGURE 1 OMITTED]

STEP Combines Interface Standards

The standardization process is widely used in the industry. The non-profit German ProStep iViP association offers a platform allowing the collection of a set of basic requirements and processing guidelines for collaboration from its members, as well as from other invited mechatronic companies. Under the leadership of Mentor Graphics and the ProStep umbrella, a workgroup has been established with members representing users, consulting partners and vendors. In a series of workshops, the idea of a new data model that eliminates well known limitations and rebuilds the traditional way of collaboration in a new service-oriented environment has received strong support and attraction. Many companies contributed with user cases and process scenarios to ensure all aspects of collaboration were covered. The main requirements were related to ownership, network architecture, team organization, IP protection and usability of applications built using this collaboration data model.

The question of which standard to use was one of the first issues. STEP (Standard for the Exchange of Product Model Data) interfaces have been actively implemented to access layout and design systems for board and harness design. STEP complies with AP203 (mechanical design exchange), AP210 (PCB data exchange), AP212 (electric systems), AP214 (mechatronic structural data exchange) and AP233 (configuration management) models that, in combination, can reproduce most of the design objects and give lifecycle support for release and change processes. Furthermore, STEP has been introduced in manufacturing, aerospace and automotive industries with high acceptance.

To avoid "reinventing the wheel," STEP AP214 has been identified as the guideline for implementation of a new collaboration model at a high-level definition. Instead of exchanging all design data, a common collaboration space for MCAD and ECAD has been defined with some additional extensions from AP 210 (PCB). This collaboration space uses the terminology of the existing mechanical, as well as electronic design tools, and has been transferred in an XML collaboration model. Only a common standardized XML data model allows the flexible development of new collaboration applications in tight integration with the native design tools. The XML model and messaging connects two different domains, but does not hinder development activities nor narrow the feature sets of the native CAD tools. The model supports the process with workflow methods and contains all required information about the collaboration objects. Other electronic design process steps also can be integrated using this communication method.

[FIGURE 2 OMITTED]

Every domain is responsible for ownership of the function and integrity of its design and, therefore, for the release steps. Even if changes are proposed, acceptance and implementation must be made by its owner. That means collaboration technology must foster an ownership model that prevents unauthorized changes but allows "what-if" scenarios. Design proposals from both domains should not be limited by the ownership model, as long as test and validation happens in a sandbox and doesn't have influence on real designs. Definition of boundary conditions, tolerances and solution spaces is helpful to allow independent activities based on given guidelines.

The sandbox has to provide feedback to the users about applicability of changes and is connected to the native CAD model of both domains. Only by acceptance of both domains' business processes can the ECR/ECO (engineering change request/order) or direct takeover of changes transpire. How changes will occur depends on the established company policies and workflows. Especially for all CAD elements that are shared or required to make decisions about modifications, the collaboration module must be based on a living data model. This model must be aware of the differences and histories, must generate the notifications from one system to the other and must synchronize the changes after acceptance or revision. Such a model enables the protection of IP. This model does not fully open the system's data set, but filters the requests to provide only those elements really necessary to fix a problem. Furthermore, the application can represent the system in a way that is commensurate with the user's experience level.