In today’s worldwide market, designers are frustrated with the barriers created by outdated ideas of discrete design disciplines. They simply want to design superior products that beat the competition.
And they want a solution that is easy to use, and that allows them to focus on designing the intelligence in their products.
The pressure to create the next generation of electronics products in less time is forcing designers to critically reassess the overall product development process - from concept right through to manufacture. Fuelled by the ongoing evolution of electronics technology, the pressure to produce smaller, smarter, more connected products that deliver a competitive edge in the market now means considering all parts of the product design process as a whole.
The mechanical and electronic design attributes that differentiate a product from its competitors have traditionally been considered within their separate domains, then forced to work together as an overall product. And it is the combined distinctiveness of those elements that create today's unique, connected products. It also raises the questions of how products should be connected to deliver unique benefits to those that use and service a device or machine.
What is now needed is to view the bigger picture of the design process, with all elements working together, across all design disciplines.
An increasingly important need in product development is dynamic interaction between the electronic and mechanical aspects of a design, where the incessant need for smaller and more functional packaging forces the two to be intimately connected - in both the physical sense and in their development.
Board assemblies now typically hold all of the external hardware such as connectors, keypads and displays while the product case assembly neatly exposes these to the user. This physical interface is also where the product's design intelligence inside the box meets the user.
The two domains are inescapably linked. It has been a long time since an electronic product's case was designed to conform to the physical properties of the electronic assembly it houses. Today, the relationship between a product's electronic and mechanical design has matured to the point where the situation is pretty much reversed - the electronic assemblies are now designed to physically comply with the intended case format.
What has changed is that today's competitive products - those that are different because they are remarkable, or desirable, or perhaps first - are more than ever defined by the user experience, which can be described by that product's form and function. This critical connection between the product and user is defined by factors such as aesthetics, ergonomics and its functional behaviour, which are in turn established by the mechanical (MCAD) and electrical (ECAD) design of that product.
As designs become more sophisticated, intelligent and connected, the concept of high level design has emerged in the form of system designers in the ECAD world and industrial designers in the MCAD domain. Together, they determine how device intelligence, design, function and form combine and work together to create the products we all use.
The mechanical aspects of designs now profoundly influence the electronic design more than ever, influencing or defining board shape, size and component positioning, but in many cases also determining the type of components used and even how the software behaves. This trend makes the interaction between the domains more important than ever, since the competitive success of a product can now hinge on the effectiveness of that ECAD-MCAD cooperation. We need processes that work together, rather than just connect together.
25 years of relationship trouble
In practice, the need for ECAD and MCAD design data transfer has been addressed at a simple level by the use of common file formats that pass basic dimensional information between the design applications in each domain. The development of 3D MCAD design during the 1970s, and then solid modelling in the '80s, tracked a somewhat rough path in the evolution of the data exchange file formats, particularly from the ECAD perspective. The result is an ECAD-MCAD design flow that tends to exist at only a basic level and relies on a range of different file exchange formats, depending on the MCAD and ECAD applications in use.
And this was always predicated on the two disciplines remaining discrete.
Traditionally this means the dimensional and object positioning data from one application are processed and transferred to the other via a range of 2D and 3D file formats, as 'milestone' events. With each of these steps suitable design modifications are made, and another data exchange may then be instigated to confirm those modifications, resulting in a rather cumbersome, sequential process that does not encourage MCAD-ECAD design collaboration.
Another approach to the problem has been the use of separate, third-party design translators to ease file compatibility issues (IDF, for example, is sparsely supported in the MCAD world) and make the process more flexible. These often provide import/export options in the native format of the ECAD-MCAD applications, and in some cases connect directly into those programs using object linking (OLEs) or application programming interfaces (APIs).
To date both these approaches have fallen short of the ideal. With the basic file exchange setup, data translation errors are frequent due to limitations and inconsistencies in the exchange format itself and there is little control over the degree of data sent - too much or too little is equally problematic. But above all, the process is generally clunky and marred by the incompatibilities of weak data exchange formats.
Dedicated CAD translation programs generally offer a better approach, thanks to more rigidly defined formats and data filtering options that allow you to specify what objects are included for transfer. Unfortunately however, it is often a case of two steps forward and two steps back due to the added layer of translation complexity inserted into the process.
The approach can, for example, make the translation process version-sensitive because of its intimate ties to the MCAD-ECAD applications, and it certainly adds another licensing cost to the overall design system. The linked (OLE, API) version of the translator programs can offer a more integrated solution by bolting itself into the MCAD or ECAD application, but the trade-off is that it then becomes 'version-critical' and the MCAD-ECAD applications must be loaded on the same PC platform so the OLE/API interconnections can be established.
A unified solution
As with other engineering processes that have evolved to cater for a growing need, it is worth taking a higher level view of the desired result those processes aspire to provide. As it stands, the existing solutions attempt to bridge the MCAD-ECAD gap though a maze of file formats and applications designed to stitch processes together. What is basically needed however, from a process point of view, is the ability to design and position correctly-sized objects in both domains so that the overall design fits together as intended.
In essence then, the star of the show is clearance checking, or in other terms the process of 'materials fit'. This part of the design process is generally undertaken in the MCAD environment, where an imported 3D rendition of the PCB assembly is placed within the MCAD design. Clash-detection within that environment then determines the success of that fit, and if necessary, board modification data can then be sent back to the ECAD domain.
What's been needed at a fundamental level then is a reliable, comprehensive and convenient way to transfer that data between the domains. Fortunately the development of 3D data transfer protocols has moved to the next level with the relatively new STEP format, which is a data-rich and extremely robust protocol designed for 3D design and manufacturing processes.
STEP is now supported by most MCAD systems and the introduction of bi-directional support within the ECAD domain offers the potential to eliminate the 3D data translation problems in one 'step'. STEP files can be large, but this can be easily constrained if the ECAD system also offers an intelligent range of object filtering options in the translation interface. Along with file compatibility benefits, this approach also removes the complications and expense of third party applications, and does not suffer from MCAD-ECAD application version issues.
Focusing again on the fundamental need, it also becomes clear that a significant part of the problem needs to be solved in the ECAD domain, particularly if true concurrent ECAD-MCAD design is the desired outcome. In the existing workflow where object clearance issues are solved exclusively within the MCAD domain, ECAD design can only progress when those 'milestone' clearance checks have been completed. As a result, intermittent design concurrency is the best possible result.
To make ECAD clearance checking a possibility, what are needed are realtime 3D capabilities within the PCB editor, plus the ability to import MCAD assemblies into that space. By using the robust STEP format to bring, say, a case assembly into the ECAD domain, practical interference checking can become a reality in the PCB design environment. If such a system is then coupled to matching user-defined clearance rules and 3D object transparency options, a large part of the mechanical fit task can be resolved in realtime within the ECAD domain. This system would match and potentially exceed the capabilities of the equivalent process in the MCAD environment, enabling genuine concurrent design between the domains.
Such an approach significantly reduces the complexity and number of MCAD-ECAD design iterations that are required by existing systems. In an ideal world the iterations might be eliminated by a single, huge design environment that caters for both MCAD and ECAD design. But while this is not a practical reality with current technology, file exchange processes can be reduced or even eliminated by linking to 3D data files rather than embedding that data within the ECAD design files.
In workflow terms this means that the ECAD application simply loads data from an external 3D STEP file that has been generated by the MCAD application. The PCB editor can then alert the user when that external file changes - in response to an update from the MCAD domain - then update the object in the PCB work space and ECAD design files. This would all occur in a realtime 3D design environment, allowing board designers to resolve mechanical clearance errors on the fly rather than through a protracted series of MCAD-ECAD design iterations.
Ultimately, the increasing importance of the physical properties of today's designs means that the interdependency of the ECAD and MCAD design environments needs to be catered for by systems that deal with the core problem directly. Most existing systems that attempt to provide a solution fall short of the mark or create counterproductive and error-prone workflow. By introducing an ECAD system that provides robust 3D data transfer, interactive clearance checking and the ability to link to the MCAD world in realtime, designers can work cooperatively in both domains to create unique products that deliver a clear and sustainable competitive edge.
These were the philosophies which led to exactly these capabilities being incorporated into the latest release of Altium Designer. This release is the latest step in delivering electronics design tools which unify the whole design process, from electronics design through to, today, the MCAD world.
Recent releases of Altium Designer have focused on device intelligence at the core of the design process. From that start point, designers can now embrace the MCAD world, all within a unified electronics design environment.
| Tel: | +27 12 665 0375 |
| Email: | [email protected] |
| www: | www.edatech.co.za |
| Articles: | More information and articles about EDA Technologies |
© Technews Publishing (Pty) Ltd | All Rights Reserved
printer friendly version