If your organization is still getting its ‘sea legs’ when it comes to developing smart, connected products, then don’t worry: you’re not alone. Many companies are trying to figure out the intricacies of developing software code, integrating electronics into mechanical design, or figuring out what data to send to an Internet of Things (IoT) platform. Lots of folks are climbing up a pretty steep learning curve.
There is one area, however, that is a frequent stumbling block: the development of routed electrical systems. Those wires, cables, and harnesses deliver power to all electronics and carry signals between sensors, antennas, and embedded systems. Despite its critical role in smart, connected products, many organizations don’t see its development as a high priority. That’s a major oversight. In this post, we’re going to look at the timing of the development of harnesses, the needs of modern engineers to support concurrent harness design, and the technology capabilities needed to enable that change.
Let’s get started.
The Timing of Harness Design
When considering the design of harnesses, it is useful to think about it as an interface. Some wires deliver power from a source to an electronics endpoint. Other wires carry signals between two or more electronics endpoints. Yet, wires have characteristics of their own as well. They have power ratings. They have network bandwidth. They have connectors. Wires have key constraints as well, depending on what they connect. If a wire delivering a signal to an embedded system is too long, then the signal might be too weak. Ultimately, the characteristics of wires in a harness are highly dependent on what they connect.
Now, everyone knows that the design cycle can be a chaotic process. Engineers tweak and refine the embedded systems, sensors, and antennas in smart, connected products as necessary. That’s natural. Engineers need to experiment and explore different options in an effort to develop a better product. However, what’s the implication for engineers that design the harnesses that are supposed to connect those electronics? It means they must react to those rapid changes.
As a result, that has caused many engineering organizations to hold off on the design of harnesses until those chaotic times have settled to a relative stable state. That means the engineers developing harnesses can do their work without an electronics change disrupting their work. Yet, that means that harness design occurs towards the end of the entire design cycle. That means there is less time to react to big changes. That means that there is less time to work through any problems with harnesses. That means that prototyping and testing happens very quickly after design. All of this can lead to serious delays and costs in the development cycle.
Migrating to Concurrent Harness Design
How does an organization mitigate the risks associated with harness design happening so late in the design cycle? Make it happen concurrently.
The idea here is to develop the harness while the rest of the electronics in the electrical system are being designed. When done in parallel, there is more time to work through the kinks in the design and explore more alternatives. It means that a more mature design is delivered to prototyping and testing, both for the harness validation as well as the overall smart, connected product validation. All this sounds good in theory. Though, the underlying issue remains: how do engineers designing harnesses deal with all that chaotic change happening with the design of the electronic endpoints. Remember, those embedded systems, sensors, and antennas define the constraints on the harness. The fundamental change is that the engineers designing harnesses need to be able to accommodate those changes. However, the answer is to work harder or put in more hours. Another solution is needed.
That’s where new capabilities in both MCAD and ECAD applications are needed as enablers.
New Capabilities to Accommodate Change
So how can the engineers designing harnesses accommodate change?
A critical new capability that has recently emerged is tighter associativity between the ECAD application used to develop the harness’ schematic and the MCAD application used to route that harness’ wires through the 3D mechanical assembly. As a power, network, or other requirement for an electronic endpoint changes, the electrical engineer makes a change to their harness schematic. It might be to change the wire type, its color, switching wires, or something else. Once that is done, that change is seamlessly and automatically propagated to the harness design in the 3D mechanical assembly. This concept of associativity provides some control to the electrical engineer and the mechanical engineer involved, allowing them to visualize what has changed. However, it also gives them the capability to quickly and easily make that change to the routing. This is one way that these two engineers can more readily accommodate change.
Now all changes to the constraints on harnesses, however, aren’t so simple. Some don’t just require a change to the wire type. In some cases, a whole set of wires must be replaced and rerouted. That might require collaborative and iterative work back and forth between the electrical and mechanical engineers. That, though, brings up some challenges. An electrical engineer can’t easily look at the harness routed through the 3D mechanical assembly and understand how it relates to the harness schematic. The mechanical engineer can’t easily look at the harness schematic and understand how it relates to the 3D mechanical assembly. Each needs their familiar context to have a collaborative and iterative discussion.
This is where the second key capability comes into play: interactive highlighting. It may not seem groundbreaking, but in these circumstances, it is crucial. The idea is that a wire in the harness schematic can be selected and the corresponding wire in the harness routed through the 3D mechanical assembly highlights simultaneously. The same is true going the other direction, selecting wires in the 3D mechanical assembly and seeing it highlight in the harness schematic. This interplay, back and forth between ECAD and MCAD applications, is a key enabler to having collaborative and interactive discussions about how to resolve a complex change to a harness.
Traditionally, it has been difficult for harness engineers to accommodate changes to electrical endpoints. Harnesses have often been designed at the end of the design cycle.
Waiting so long to design harnesses carries significant risk. It can inject significant delay and costs into development.
The alternative is to design harnesses concurrently with the electronic endpoints they connect. They key is accommodating and accepting changes more readily.
A key technology enabler is tighter and more automated associativity between ECAD and MCAD applications, making it easier to accept changes quickly and easily.
Another key technology enabler is interactive selection and highlighting between ECAD and MCAD applications, allowing electrical and mechanical engineers to collaboratively and iteratively work through complex change quickly and easily.
If you haven’t turned your attention to this issue with harnesses during your company’s journey to develop smart, connected products, now is the time to consider it. Good solutions are emerging in this space.
That’s my take folks. Would love to hear your thoughts in the comments below.