Wire/Cable Harness: The Stepchild of Product Development
Ken Versprille, PLM Research Director, CPDA

The integration of electrical and mechanical components remains a challenge for manufacturing companies. New products continuously incorporate more electronic controls across all industry verticals. This increase in electro-mechanical systems places critical demands on the product development process of connecting electronic components throughout a product structure. Those links are supported by wire/cable harness connections.

Long called the “stepchild” of product development, wire and cable harness design and manufacturing commonly take a back seat to the attention grabbing areas of mechanical design, as well as the development of the actual electrical components that drive the product’s operation. However, the increasing competitive importance of enhancing electronic capabilities, together with demands to reduce cost and shorten product development cycles, all combine to dramatize the difficulties in designing wire/cable harnesses. Problems can lead to unacceptable delays at the tail-end of new product launch, or even worse, create downstream warranty liabilities when the design is rushed.

Collaborative Product Development Associates (CPDA) recently conducted a study of the development procedures for wire/cable harness design and manufacturing currently implemented in aerospace, automotive, and large machinery companies. The study covered the five high-level product development phases of requirements management, functional design, logical design, 3D physical design, and production manufacturing. Although the energy invested in any given phase varied between industry and by company within the same vertical, all companies contacted followed the five phases with some level of consistency. Differences arose when dealing with attempts to reuse previous designs, or when outsourcing occurred in the manufacturing phase.

Electrical systems and the wire/cable harness that unite them can no longer afford to be the stepchild in the product design process. The child is growing up. Manufacturing companies must invest in understanding and improving the full electrical systems development process from requirements management, which is becoming increasingly complex, through to manufacturing, assembly, and downstream serviceability. By better understanding where the industry is today, and where roadblocks exist in process improvement, companies will be able to better evaluate their own process and make the correct decisions that benefit their business.

Study Results

All paid close attention to the collection and documentation of requirements. Surprisingly, however, only one company reported the use of a commercial application tool to record and manage those requirements. The majority of companies only documented requirements in a text editing application.

The first design step in an electrical system design is to propose an overall solution as to how the systems will be functional decomposed in a topological architecture in order to satisfy requirements. Companies indicated the use of two approaches. The most common approach was a top-down systems look. Others tackled the problem initially at a subsystems level, and then integrated at the top systems level to resolve any conflicts. This second approach was most common in companies attempting to do major reuse of precious designs or those under tight design cycle pressure.

The output of the functional design phase was often a 2D or 2½D topological map of the schematic design solution. There was an apparent lack of commercial rules-checking and validation tools used to verify that the systems design approach satisfied requirements. The majority indicated that if validation occurred at this stage, it was most likely a manual process, and sometimes limited to a design rules “connectivity” check. A few did report the use of digital validation tools – either developed in-house or obtained from another end-user company that has commercialized its own tools.

Detailed 2D schematic drawings for each harness are the output of the logical design phase. Companies report it is common practice to overlap the actual 3D routing of the wire/cable harnesses before the 2D schematics are finalized. In most companies, 2D and 3D tools from different commercial vendors were used. This led to difficulties in supporting any type of automatic change update between the two applications.

Most reported the use of a 3D CAD design authoring tool for 3D routing of wires and cables through the product structure. Those designing in 3D paid close attention to defining and supporting libraries of electrical components that could be placed into the product models, with the harnesses then routed between the components. Some reported concerns that these libraries were not kept in a central repository – allowing duplication and raising the risk of incompatibilities.

Only a few indicated they used commercial applications to perform digital simulation of assembly or disassembly to ensure the harnesses could be placed into the product without clearance issues during assembly manufacturing, and to guarantee the harnesses could be disassembled easily for downstream serviceability. Most trusted experienced design engineers to model harnesses that would not cause problems.

More than half of the companies outsourced manufacturing of the design harnesses. Of those doing in-house manufacturing, most reported the use of commercial applications for defining formboards for the manufacturing process and for the layout of the harnesses themselves. However, the full formboard manufacturing approach was only undertaken when the production volume required was high. Of particular note, companies that outsourced harness manufacturing typically supplied paper diagrams and other specification documents in hardcopy. Very little digital data is exchanged, although many commented that they were moving in that direction.

Process Weaknesses

A broad analysis of the harness product development processes uncovered during the study reveals that although some companies have made sophisticated accomplishments in particular phases of development, no one company has a fully optimized solution across the entire development cycle. Harness design itself can be looked at as a microcosm of the overall product development process. It is rare to find a product designed and manufactured today that is not an electro-mechanical system. Harness design embodies all the development phases through which any such product transitions, from requirements gathering, conceptual design, detailed design, on into manufacturing. Any weakness in one of the phases, or transition between phases, affects the entire process.

Putting aside the difficulties companies must face when updating previously developed products and their need to deal with the older applications and methodologies originally used to create that product’s schematics, designs, and drawings, the study cast a critical eye on new product development. Given a new product start, how do these companies proceed through the product development cycle, what tools do they deploy, and what stumbling blocks do they encounter?

These issues fall into one of two high-level categories. The first deals with the flow of information through the harness development process. The second category delves deeper into the data structures that capture that information.

At least four areas of critical concern must be addressed:

A mechanism is needed to digitally link the execution results of validation applications to the requirements they satisfy. Once such links are in place, it becomes straightforward for management and project leaders to ensure compliance and track progress of the design.

Improved, standardized interfaces must be established for defining the interrelationships between 2D schematics and 3D routings – even between disparate vendor applications – for automatic update when changes occur.

A more robust framework of rules-based and procedural design rules checking and validation tools must be developed, and must allow easy integration.

Software design authoring applications must provide added capabilities under user direction to support the diverse end-user needs in dealing with the multiple configuration design problem.

Data Flow Roadblocks

As new product development steps through the five phases of requirements management, functional design, logical design, 3D physical design, and manufacturing, users input various types of information about the harness through their choice of content authoring applications. The study indicates that most often these tools are a collection obtained from different commercial vendors.

Each application may have to communicate with each other application in the process flow in order to assure consistency. However, not all data in each application must be moved or referenced. The data flow might entail a value translation or simply a link to associate two different data values. For example, if wire gauge is authored in logical design, that value may need to be translated into the 3D CAD application to provide a realistic image of the 3D routed wire. In another case, a minimum distance between wires recorded in the requirement specification may need only to be linked to the results of an interference check in the 3D CAD application for validation tracking purposes.

Requirements Linked to Validation

Although product requirements management extends well beyond just harness development, designers of harnesses should gauge their adherence to best practices by considering the following aspects:

Store requirements in a central repository, or if working in a distributed environment with multiple repositories, ensure that they remain in synchronization.

Disallow individual copies of the data that cannot be tracked.

Consider some form of push technology to inform stakeholders when a requirements change occurs.

More importantly, requirements should be digitally tracked for having been satisfied by the actual product designs. In the study, companies indicated that they relied on individuals in design engineering to own the responsibility to ensure that their work met requirements. At best, an individual would manually verify the design and check off a line item in a project worksheet. In most cases, although not specifically called out as such in the study interviews, this led to a heightened concern of the risk involved. Questions were asked as to whether proof existed that the designs actually satisfied the requirements. Was there a digital data result to confirm that fact that management could track? Were errors being caught too late in the process causing delays and additional development costs? Worst of all, were errors being released and coming back to cost the company?

The digital-verification tracking issue is only a subset of the overall design-verification issue uncovered in the study. Broader concerns over validation are addressed in a following section of this report. For this localized issue, however, best practices should include:

Whenever a software application is run to validate a particular aspect of the design, an associative link between the results of the analysis and the digitally stored requirements should be established. That link should contain at least, but not be limited to, the following meta data:

Type of analysis application run

Design revision of model upon which analysis was run

Time and date of analysis run

Name of individual who ran the analysis

Analysis results

Depending upon how requirements are articulated, dependencies may easily occur between requirements themselves, and should be linked.

With an associative link established, management can easily track a program’s progress. Such information could be interfaced into a project workflow solution and used to trigger progress through stage-gates with management approval.

Better 2D / 3D Integration

Surveyed companies stated that for a given harness design their first transition from the 2D world of schematics into 3D modeling proceeds smoothly. This may be due in part to a practice of manually taking data already entered into a schematic and re-entering that data into the 3D design application where it is appropriate. All agree, however, a problem occurs when change happens during in-process design. The technology solutions of digitally sharing data between 2D schematics and 3D models used for routing wires are weak. Admittedly, the study uncovered the root cause of many of the 2D-to-3D integration problems were based on the companies using disparate vendor solutions in each area or an older version of a software application. The issue was most severe when they used a non-intelligent 2D schematic drawing package where wires are simply lines on a drawing.

The legacy issue may well be a triggering cause of some problems at selected companies. In the past few years, many commercial solution vendors have enhanced their applications to provide a more robust interface between the 2D and 3D worlds. If a company is using an older version of an application, a simple upgrade may offer help.

Putting the legacy issue aside, however, the 2D-3D interface could be much better. The technology exists today, with data exchange mechanisms such as Extensible Markup Language (XML), for the industry to come together and define a de facto data exchange standard to solve this issue. XML allows data content exchange with encoded syntax description, thus avoiding the need for competing commercial vendors having to agree upon a rigid binary data exchange standard – only to agree on data content.

A number of 3D CAD vendors provide their own 2D schematic application and have control over the interface between the two. In addition, 3D CAD vendors may partner with a third party vendor for 2D schematic creation and jointly work the interface between the two disparate applications. Users report, however, that more must be done – especially between two disparate vendor applications that may not have built an interface because of vendor business reasons. The user community must take the lead in promoting these concerns. CPDA views this issue as worthy of deeper study.

Some work is in progress with a wire harness standard from ISO STEP. Their focus, however, seems to be on a full harness definition, not just the subset of data needed for transition between 2D schematics and 3D routings. Also, work on the STEP standard seems currently limited to the German automotive community. Only one of the CPDA study participants noted that their company was involved in these STEP efforts.

In another related issue, many of the companies indicated that they were mechanical-driven companies, in that the engineering groups for the structural product ruled the decision making. As such, harness designers are not allowed to reserve space for harness runways. This only compounds the pressure they face when an in-process design change forces them to redesign the 3D aspects of a harness.

Expanded Analysis and Simulation

As noted earlier, analysis of the study results highlighted a serious gap in the commercial support for integration of software simulation tools into a seamless harness development process. During the interview process, companies were asked at the end of each major product development phase of functional design, logical design, and 3D physical design discussions whether specific analysis and validation applications were run against the then-current design. Their most common response was, “No, it is the responsibility of the designer to check that requirements are met and that designs are correct.” It was left as a judgment call on the part of the designers. Companies stated that what they most trusted was the experience of their design/engineering staff in these matters.

Looking deeper, it became apparent that companies faced a challenge in integrating validation software applications into their design tools. The most common validation application used was a simple connectivity check to make sure all wires had a start and end connection. A limited number of companies reported the use of other validation applications, such as voltage distribution, shielding, and violation of minimum bend radius; and that they have taken it upon themselves to implement or purchase from another end-user company that commercialized its own in-house development. In addition, the software application integration was done in-house or outsourced to a third-party software integrator – all costly solutions.

Again, upon analysis, the root cause of difficulties can be directly attributed to the inconsistencies in accessing harness design data as it flows through both 2D and 3D authoring tools. The complexity of interfacing different authoring tools has already been noted. Because any analysis/validation application must access a subset of that same data, the analysis programs, too, suffer in kind. Without an industry-agreed upon plug-and-play integration approach, users will find themselves either locked in to solutions from a single vendor or burdened with the cost of doing the integration themselves.

Today, many companies must face their only alternative — stage a physical mock-up of the electrical systems and the harnesses that connect the various electrical components. As in any physical mock-up, the associated costs and time delays to build and test adds a burden to the overall product development cycle.

Software Simulation

With the advance of technology, many electrical system solutions are now developed with computerized processors running embedded software to initiate and receive signals between electrical components. Therefore, in order to do a full digital simulation, not only must companies simulate the movement of mechanical parts and electrical signals that drive many of those parts, they must emulate the execution of embedded software that controls the systems. Only recently is the industry offering application tools to aid this process. However, the study failed to show any perceivable use of such tools by the companies that participated. Without software emulation, companies are forced to stage physical prototypes of the electrical systems in their design labs for realistic test and verification.

Data Structure Roadblocks

As is the case in any evolving application, data structures that store information content often come under pressure as additional enhancements are implemented. In CAD the pressure for enhancement can often arise out of the ways designers use the application – ways not originally envisioned by the application developers. The weaknesses found in current 2D and 3D CAD for harness design stem from just this problem in dealing with the way users create multiple configurations.