Olin King might not have invented EMS, but his approach is a model for public-private partnership.

An old Army ballad says, “Old soldiers never die; they just fade away.” The same is apparently true for electronics manufacturing services entrepreneurs. Olin B. King, founder of SCI Systems, passed away on June 16, with very little mention outside of northern Alabama.

I had to do a little soul-searching before writing this. I spent five years in what I jokingly called the Olin King School of Hard Knocks in the early ’80s and not all of it was good. That said, I honestly can’t say I’ve worked with a CEO since who had as many accomplishments or helped as many people. And I think it is important to discuss a few of those accomplishments, not from the perspective of accolades, but in terms of examples worth emulating.

King was one of the founders of Space Craft Inc. in 1961. The company name was later changed to SCI Systems to better reflect its diverse customer base. One obituary credited King with inventing contract manufacturing. That isn’t exactly true. Contract manufacturing was a widespread cottage industry in the ’60s and ’70s. However, SCI won the contract to build the first IBM PC. That turned it into the EMS industry’s first Tier One contractor, and it stayed in that leadership role for decades. King actually deserves credit for laying the foundation for the Tier One business model. SCI was the first predominantly EMS company to go public and enter the Fortune 500, although other publicly traded companies had divisions that did some form of contract manufacturing at that time. King was also instrumental in educating financial markets on the potential for the business model, actually bussing in analysts once a year to tour factories and listen to presentations on company and industry trends. King literally plowed the road for future competitors’ IPOs, with SCI’s success stories.

Northern Alabama also benefited from SCI’s presence in the region. SCI was headquartered in Huntsville. At the time it started to grow with the IBM PC contract, that region was depressed. Huntsville had been a big winner in the fledging space program, but when the Apollo program wound down concurrent with military downsizing, Huntsville was hit hard. The interstate highway system bypassed Huntsville, making it less attractive as a manufacturing center for new industries. Under King, SCI didn’t simply grow as a company; it grew the region. King would regularly call the governor’s office looking for resources for SCI. Most of the time those resources benefitted Huntsville as well. When I was there, SCI became Huntsville’s largest employer, and many of the employees it hired had no manufacturing skills. Alabama paid for classroom trailers and instructors to teach soldering skills. SCI set the trailers up in its parking lots. The best students got hired, and the rest walked away with skills that made them employable in other companies in the region, many of whom preferred not to hire unskilled labor. King was instrumental in getting the city connected to the interstate, growing a major technology park and enhancing the state university system. Today, Huntsville has a diverse economy, but I wonder what the city would look like had King not worked to improve the infrastructure. The SCI public-private partnerships in the ’80s translated to thousands of jobs, conversion of unskilled applicants into trained production operators, and enhancements to the local transportation and educational infrastructure that benefited the entire business community, all within promised deadlines.

Wages at SCI back then were low. I used to joke that I made more money in college as a waitress. However, SCI had Cadillac benefits. It wasn’t all philanthropy. SCI had been a union target, and King saw good benefits as a way to compete with unionized factories. Union avoidance was another reason unskilled workers, mostly women, were hired in large numbers. Women would work for lower wages, were less prone to organize, and were willing to do repetitive tasks like drop loading components or clipping leads. While some would call this a sweatshop environment, I saw a totally different picture. The health insurance benefits were quite comprehensive, and sick leave could be accumulated indefinitely. The few employees I knew who got serious injuries or illnesses had jobs when they came back, and if they’d saved their sick leave, got full pay, plus disability coverage, during recovery. There was also strong United Way support, and United Way agencies helped a lot of people in that community. While I can’t speak to what the company did after I left in 1986, I can say that during my time there, SCI was one of the more stable employers, because wages and salaries stayed low. The unionized operations seemed to have annual strikes, often driven by negotiations in other parts of the country, and non-union employers with higher wages often course corrected through layoffs. But the crown jewel in SCI’s benefits was the best tuition refund program I’ve ever seen. Any full-time employee could receive reimbursement for classes at any state university, provided they earned a C on undergraduate classes or a B on graduate classes. It didn’t have to be job-related. And, King and other business leaders worked with the University of Alabama in Huntsville to design evening-based degree programs, so employees could work full-time and go to college at night.  Additionally, SCI offered first line supervisor training and other courses via its National Management Association chapter, and would pay for job-related training on a case-by-case basis. In short, those willing to put in the time to tap the training options could gain skills that opened the door to far greater opportunity than they’d had when they were hired. It was a pathway to the American Dream funded by sweat equity, not taxpayer dollars.

Everyone who worked at SCI has at least one Olin King story, some good, some bad. Some will remember him for his Type A management style, which he labeled “distributed autocracy.” Others will remember him as a truly ruthless competitor on projects strategic to SCI. Yet others will remember his involvement at the community and state level. I will remember him as a man who opened the door to opportunity for any employee willing to put in the hours to take it. SCI paid for my master’s degree, and I often wonder if my life would be nearly as comfortable if I hadn’t earned a graduate degree and developed a “no excuses” work ethic in the Olin King School of Hard Knocks. I suspect many others feel the same way. RIP, Olin King.

Susan Mucha is president of Powell-Mucha Consulting Inc. (powell-muchaconsulting.com), and author of Find It. Book It. Grow It. A Robust Process for Account Acquisition in Electronics Manufacturing Services; This email address is being protected from spambots. You need JavaScript enabled to view it..

The circuit board industry in Japan seems to be on life support.

Read more: JPCA Show 2012, Part III

This is the second in a three-part series that details my observations from the 42nd International Electronic Circuits Exhibition held in Tokyo Big Sight in Japan June 13 through June 15. I could not visit every exhibit because of the limited time, so I decided to share a couple of technology changes and advancements that seems to be newsworthy.

Read more: JPCA Show 2012 Recap, Part II

A new data exchange format, IDX, promises to improve electromechanical design collaboration.

Electromechanical product designers face constant competitive pressure to reduce development costs, improve design cycle times, and eliminate errors that can lead to costly rework. Nowhere is this challenge more apparent than in the integration of PCB layout with mechanical design, where sharing design information efficiently and reliably has long been a bottleneck in the overall electromechanical product design process.

It’s a tough problem to solve. Not only does the shared information have to bridge the 2D to 3D gap, the amount and type of information that needs to be shared varies from design to design and company to company. Plus, the information requirements often change throughout the design process.

For nearly 20 years, the Intermediate Data Format (IDF) has been the preferred file format for exchanging basic design information between the ECAD and MCAD systems that PCB layout designers and mechanical designers use to design electromechanical products. Unlike drawing data formats like DXF and IGES, the IDF preserves design intent during the exchange process, resulting in significant productivity improvements.

But the IDF is not a panacea. Design information that can be shared through the IDF is limited to the board shape, basic component shapes and locations, basic hole definitions and locations, and keep-in/keep-out areas. More significant, IDF files can only represent “snapshots” of the design at any point in time; the IDF does not support incremental changes throughout the design process.

A new data format, known as IDX for “Incremental Data eXchange,” has been developed to overcome the limitations of the IDF and provide a new level of collaboration between board layout and mechanical design.

History of IDX

IDX grew out of discussions between Mentor Graphics and Parametric Technology Corp. and their customers about ways to enable more collaborative use of their respective tools on designing electromechanical products. Faced with the challenges of designing smaller, more complex products, the customers were asking for a design collaboration solution that could not be developed around the IDF.

As a result of these discussions, they engaged the ProSTEP iViP Association, a standards development consortium based in Germany, to develop a new data exchange format for ECAD/MCAD design collaboration and make it available to the entire CAD vendor and OEM community. A project group was established, and work on the new format began in 2006.

The project group created a data model for ECAD/MCAD collaboration called the EDMD (Electronic Data Mechanical Data). The EDMD data model borrows from STEP (Standard for the Exchange of Product model data), an international standard, specifically, Application Protocol (AP) 214 “Core Data Model for Automotive Mechanical Design Processes” and AP 210 “Electronic Assembly, Interconnection, and Packaging Design.” In addition, a goal of the project group was to incorporate the concepts and content of IDF 3.0 in the initial data model.

ProSTEP released an initial version (1.2) of the EDMD in 2008. The current release of the EDMD, version 2.0, was completed and published as “ProSTEP iViP Recommendation PSI 5” in May 2010. The recommendation includes an XML file representation of the EDMD data model. The XML files have an extension of .idx, which is where IDX gets its name.

Some of the key features of IDX that are not found in the IDF are:

• XML representation. The EDMD data model is defined with XML schemas, and IDX files are XML documents. This makes IDX flexible and extensible. New features, such as support for etch shapes or traces, can be added in future releases of IDX without affecting current implementations. Plus, XML is familiar to many developers, so there is less reinventing the wheel to support IDX file exchange in their CAD products.
• Unique design object identifiers. Every design object has a unique identifier in IDX – not just electrical component instances (uniquely identified by reference designator in the IDF) but holes, keep-outs, mechanical components, and other design objects as well. Unique object identifiers are the key to tracking and managing changes in a collaborative design environment.
• Incremental exchange. IDX can represent an initial “baseline” design state, as well as incremental changes to that state and subsequent states. Incremental exchange reduces the amount of design information shared between PCB layout and mechanical design during the design cycle. More important, IDX gives designers the ability to identify what changes are being proposed and evaluate the effect of those changes before accepting them.
• Change history. Each design change represented in an IDX file can include a history of who originated the change, when it was made, a comment explaining why it was made, who reviewed the change, whether the change was accepted or rejected, and a comment explaining why it was accepted or rejected. This history is a key element of the collaborative design process.

---

Inside IDX

The following sections offer a brief look at some of the main aspects of the EDMD data model and how it relates to the IDF:

Geometry. IDX supports the basic geometry of the IDF: polylines (connected sequences of line segments), circular arcs, circles, and composite curves (two or more polylines and arcs joined end to end). Parabolas, ellipses, b-splines, and other curve types are also permitted, although most ECAD systems do not currently support them. The points that define these geometric elements are confined to the x-y plane.

Lines and curves combine to form IDX curvesets. An upper and lower bound can be specified for each curveset, giving the curveset a “thickness” in the Z direction. This is how IDX gives thickness to the board, heights to components, and height-based restrictions on keep-ins and keep-outs. As with the IDF, IDX currently limits geometry to this 2.5D representation because ECAD systems do not generally support full 3D models. However, the EDMD data model supports a full 3D geometry representation for future use.

Shapes. Objects in a board design are created from IDX shape elements. Each shape element specifies a curveset and a type (for example, “part feature” for the board and component parts, and “non feature shape element” for keep-ins/keep-outs). A shape element can be “inverted” to create a void in another shape element. For example, a shape element can be inverted to create a cutout in the board shape.

Shape elements combine to create shapes for the board (called a “stratum” in IDX), assembly components, keep-ins/keep-outs, holes (called “interstratum features”), and other design objects such as mechanical parts. Because shape elements can be combined, it is possible to create board shapes with cutouts, and component shapes with more than one height.

For example, the body of a DIP can be one shape element, and the rows of leads on either side can be additional shape elements. So, although geometry is limited to 2.5D in IDX, multiple shape elements can be used to closely approximate 3D shapes (Figure 1). In the IDF, components only have a single shape.

Items and instances. IDX defines the structure of a board design using items and item instances. Items represent the definitions of board design objects; item instances represent the occurrence of those objects in the board design.

An item can define a single object such as the board itself, a component, a hole, or a keep-out. Or, an item can define an assembly that includes other single objects or assemblies. Each item definition includes all the design information for an object, including its shape, identification and properties, if any. Items can be reused in the design. So for example, an item that defines a component part can be used multiple times in a board assembly.

An item instance is the occurrence of an item in the overall board design structure. Each item instance can include a transformation (currently limited to 2D) that determines the item’s location in the design. Assembly items can contain multiple item instances of single items or other assembly items. This permits IDX to represent hierarchical design structures.

For example, to support panelization as in IDF 3.0, an IDX assembly item could define a manufacturing panel that includes multiple instances of a board part (single item), or multiple instances of a complete board assembly (assembly item).

Roles. IDX extends the concept of ownership in IDF 3.0 with roles. Roles can be assigned to items and item instances to determine who has responsibility for those items and instances, and control who has the right to make changes to them.

Each role specifies a person or group, a type (owner or listener), a category (mechanical, electrical, organizational), a function (design, layout, thermal, etc.), and the item or item instance to which the role is assigned.

For example, with IDX roles, one mechanical designer can own connector locations, and another mechanical designer can own the board shape. The PCB layout group as a whole can own all other component locations.

Properties. In IDX, as with IDF 3.0, properties can be used to assign functional characteristics to component definitions such as capacitance, thermal resistance and power dissipation. Unlike IDF 3.0, IDX extends the use of properties to component instances, shapes, geometry, and most other elements of a design, including the design as a whole. The unit length property, for example, sets the global units for the design.

Properties in IDX can also be used to temporarily extend the functionality of the data model itself. For example, IDX 2.0 does not have an explicit way to represent the side of the board where a placement keep-out applies. Instead, this characteristic of a keep-out is represented as a user property on the keep-out item instance.

---

Groups. Items can be assigned to groups in IDX, a capability not supported by the IDF. For example, a component can be grouped with a route keep-out. Or, the components that comprise a related portion of a circuit in an area of the board can be grouped.

Constraints can be assigned to a group to determine the behavior of the group, for example, that the items in the group have to move or rotate as a unit. A group can also have an owner that specifies who is responsible for the group.

Text. As with IDF 3.0, IDX provides support for displayable text that can be used to annotate a design but is not part of the design itself. However, IDX allows more control over the size and appearance of text. Each occurrence of IDX text is located within a bounding box defined by upper left and lower right points, and can specify a font, style, weight, alignment, and other attributes.

IDX files are XML documents, so their syntax is XML syntax. The structure of an IDX file is defined by a dozen interrelated XML schemas that comprise the EDMD data model.

Every IDX file contains a root element with a Header section followed by a Body section. The Header contains general information about the file, such as the creator of the file and the tool that was used to create it. The Body section includes all the information – shapes, items, instances, properties, groups, roles, etc. – that describe the current state of the design.

IDX files that represent a complete design state, called baseline files, tend to be large – at least an order of magnitude larger than corresponding IDF files. Large designs can result in IDX files several megabytes in size. However, IDX files that represent incremental design changes are generally much smaller, depending on the number and nature of changes they contain.

Note that IDX files are not designed to be edited by hand. Many of the XML elements in an IDX file contain references to other XML elements in the file. Modifying or removing portions of the file can result in incorrect design information or even corrupt the entire file. IDX files should only be processed by applications that comply with the EDMD data model.

Figure 2 is a small excerpt from the Body section of an IDX file that defines a component instance.\

 

Managing Change

IDX’s most significant contribution to ECAD/MCAD collaboration is its ability to represent and manage incremental changes throughout the design cycle. This lets designers focus on what’s most important as the design evolves, and collaborate on the changes.

The key to incremental exchange is having unique, persistent identifiers for each design object. With the IDF, only component instances have unique identifiers – their reference designators. In IDX, every item definition and item instance has a unique identifier. So, for example, if a keep-out is removed from the mechanical design and an IDX file is sent with this change, the receiving ECAD system knows which keep-out to remove in the layout by its matching IDX identifier. As another example, having unique identifiers for component instances permits reference designators to be re-sequenced for manufacturing purposes at the end of the design process.

The identifiers are established and communicated in a baseline IDX file exchange. The baseline file sets the initial state of the design and is the starting point for future collaboration. The baseline can come from either CAD system. Often, this is MCAD, where the mechanical designer determines the board shape, mounting hole locations, and the locations of critical components such as connectors and switches. Or, if a new design is based on an existing design, the baseline may come from ECAD.

After the baseline exchange, both CAD systems have the same identifier for every design object exchanged in the baseline, and the mechanical design and PCB layout are synchronized from a collaboration standpoint. Subsequent IDX file exchanges contain only objects that have changed from the baseline or from a later synchronized state of the design.

An IDX change file contains a Changes section that specifies what items and item instances have changed, with references to the actual changes described in the Body section. Changes can result from adding new items (such as placing new components on the board), moving items (such as relocating a mounting hole), modifying items (such as changing the board shape), or deleting items (such as removing a keep-out).

IDX can also indicate the acceptance state of changed items. This allows designers to preview proposed changes and either accept or reject them. The accepted and rejected changes are communicated through another IDX exchange back to the sending system so that the state of the mechanical design and PCB layout can be kept in synch.

---

CAD Implementations

A number of CAD vendors now support IDX or have plans to do so. Here’s a quick look at some of them.

Cadence. Support for IDX is built directly into Allegro 16.5 as a standard feature. Versions 1.2 and 2.0 of IDX are both supported. Importing and exporting IDX files in Allegro is similar to importing and exporting IDF files, including the ability to configure export filter settings (Figure 3). Importing an IDX change file brings up a form that lists all the proposed changes. Selecting an item from the list previews the change in the design so you can see the effect of the change before accepting it. Similarly, when exporting changes, a form is displayed showing all the changes made since the last synchronized state of the design. You can choose which items to include in the IDX change file from this form.

As with the IDF, Allegro also provides a batch executable command for exporting IDX files from the Allegro command line or from an OS command prompt. A batch command for importing IDX files is not provided because importing requires users to preview, accept, and reject changes.

Dassault Systèmes (Catia). Dassault Systèmes is working to implement IDX for its CATIA Circuit Board Design and CATIA Flexible Board Design products. The IDX interface will be implemented by a DS Development Partner, CadCam Design Centar D.O.O.

CATIA currently manages PCB exchanges through IDF 2.0 and 3.0 in CATIA Circuit Board Design and CATIA Flexible Board Design. With CATIA V6, collaboration and
synchronization between electrical and mechanical PCB designs is ensured by IDF file sharing. To improve this sharing, IDF files are saved directly within the V6 Platform, ensuring full synchronization at all times, and efficient traceability of design changes.

Dassault Systèmes (SolidWorks). Solidworks support for IDX is provided by the CircuitWorks add-in included with SolidWorks Premium 2012. The CircuitWorks add-in supports both IDX versions 1.2 and 2.0, as well as Mentor PADS .asc files and all versions of the IDF.

CircuitWorks sets up a common folder for exchanging IDX files with ECAD and constantly monitors this folder, sending notifications whenever a new IDX file comes in. If a common folder cannot be set up, CircuitWorks can be configured to automatically email IDX baseline and change files.

Once a baseline is established and an IDX change file is imported, proposed changes can be viewed and accepted or rejected. A one-button operation updates the SolidWorks design with the accepted changes and exports an IDX change file for synchronizing with ECAD. CircuitWorks maintains a model tree showing the history and status of all changes (Figure 4).

Mentor Graphics. Mentor’s ECAD-MCAD Collaborator (EDMD) supports IDX versions 1.2 and 2.0 for the Expedition Enterprise, BoardStation XE and PADS design flows. The ECAD-MCAD Collaborator provides a 3D visualization environment to review, accept, and reject IDX change proposals from MCAD. Detailed 3D models of electronic and mechanical parts can be imported to help evaluate the effects of the proposed changes. Mechanical packaging data can also be imported so that a complete product assembly with multiple PCB databases can be built completely within the PCB environment.

The ECAD-MCAD Collaborator also allows dynamic view following with the PCB tool. If a part is moved in the PCB tool, the 3D view updates in real time. Panning, zooming and layer display changes in the PCB tools also dynamically update in the Collaborator.

PTC. Creo, PTC’s suite of design software, and Pro/Engineer Wildfire both support IDX.

IDX support for Creo Parametric, PTC’s 3D parametric design app, is provided with the ECAD-MCAD Collaboration Extension (ECX), available beginning with Pro/Engineer Wildfire 5.0. ECX supports both versions 1.2 and 2.0 of IDX.

With ECX, IDX baseline files can be exported or changes proposed for exporting in an IDX change file. One could either manually select the changes to propose from the Creo Parametric assembly or use the compare functionality to propose all changes made since a previous saved version of the board assembly.

When importing IDX files, Creo View ECAD Validate lets you select the proposed changes from a transaction list and preview them in the Creo Parametric assembly. Once it’s been decided which changes to accept or reject in the transaction list, they can be approved to update the assembly and then saved in a new IDX file for ECAD to synchronize the design accordingly.

Creo View ECAD, PTC’s standalone visualization app for ECAD, also supports importing both versions 1.2 and 2.0 of IDX for graphical visualization.

Siemens PLM. NX 8 provides support for IDX through a fully-embedded application called NX PCB Exchange. NX PCB Exchange is developed by Maya Heat Transfer Technologies, an OEM technology partner with Siemens PLM Software.

NX PCB Exchange currently supports baseline IDX version 1.2 transfers. However, NX PCB Exchange also has the ability to compare, preview, and accept/reject changes in IDF files. This functionality will be extended in the near future to support incremental IDX changes. IDX 2.0 files will also be supported.

Zuken. Zuken supports IDX for CR-5000 with the Zuken Interchanger for Creo. As the name suggests, the Zuken Interchanger for Creo is currently optimized for use with Creo Parametric and was developed cooperatively with PTC. Over time, as CAD industry support for IDX matures, Zuken expects to use it with other MCAD systems as well.

The Zuken Interchanger for Creo supports IDX version 2.0 and can exchange both baseline and change files. It also provides filtering capabilities when exporting from CR-5000 so that designers can limit the number and type of design objects included in the resultant mechanical model.

Summary

IDX represents a major step forward in integrating PCB layout and mechanical design permitting collaboration through incremental data exchange. It’s the first ECAD/MCAD data exchange format to provide this capability. As with any new data exchange format, there will likely be implementation issues and missing functionality to resolve over time. The good news is IDX is designed to change and grow as design collaboration needs evolve. A critical mass of CAD vendors now support IDX, so the first test of a standard – acceptance – has been met. Many vendors have committed significant time and resources to develop their IDX-based collaboration solutions, and they want these solutions to work for their customers.

Dave Kehmeier is an MCAD/ECAD integration consultant and developer of the IDF (liaiseintegration.com); This email address is being protected from spambots. You need JavaScript enabled to view it..