Developing electrical/electronic (E/E) systems has never been easy. But as clients and consumers demand new smart, connected features, things are only getting more difficult. In response to these challenges, some companies are revisiting their development processes with more progressive approaches, from beginning to end.
In this post, we’ll look at some key components in a progressive design approach to E/E systems.
Manufacturers are turning to mass electrification and digitization to meet demand for smart, connected products. Engineers are certainly feeling the strain. Our recent Engineering Executive Strategic Agenda Study explored this issue, revealing that:
This rising complexity makes design more difficult in each of these domains. In the development of overall E/E systems, this complexity multiplies. For example, engineers must figure out how to arrange software-driven functions, which are themselves becoming more complex, on increasingly complicated multi-board systems.
Rising complexity is a significant challenge on its own, but it also exacerbates a longstanding issue.
Manufacturers have employed a waterfall development approach for years. It starts with systems engineers developing and vetting an E/E architecture. Then they pass the architecture to detailed design teams, where work in each domain begins in earnest.
Once there, engineers make key decisions like selecting a communication protocol, determining a timing schedule, or formatting data. Each decision is entirely logical in the context of its domain.
But some of these decisions also have an impact outside of that one domain. Selecting a communication protocol affects software, electronics, and the network. Unfortunately, while sometimes engineers realize there is such an impact, other times they don’t.
Issues caused by a decision made in a different domain come to a head during prototyping and testing. In a traditional approach, this is the first time the design work from the disparate domains come back together and have to work as a cohesive whole. To the dismay of many, this is when prototype after prototype fails integration tests. Engineering teams are stuck debugging and finding workarounds rather than actually testing the system.
Why do companies struggle with this integration chokepoint? It’s because they’re using a generic systems engineering approach.
The design representations in the different domains of an E/E system, including electronics, electrical distribution, and embedded software, are highly interconnected. As we’ve discussed, decisions made in one area might be logical in the context of that domain, but they can actually constrain or even conflict with decisions in another area.
Your engineers have to explore and assess system architectures in the context of all these domains. Then they can fully understand the implications of their decisions. Here’s an example:
Imagine you are shifting a function from one electrical control unit (ECU) to another. You’ll need to move some software along with that function. This shift is going to impact network traffic, because signals now need to start and terminate at the new ECU instead of the old one. Furthermore, the new ECU is now going to need more processing power. In this case, the engineer needs to know: 1) whether the network bandwidth is over its limit, and 2) whether the processor on the new ECU is now underpowered. This is actually an incredibly simple example. Now, imagine moving five functions around the E/E system. Without this kind of insight, you’re going to run into problems.
To address the rising complexity of today’s E/E systems, engineers need the capability to quickly and easily develop system architectures from a single source of truth. The solution delivering that capability must also account for the interconnected nature of today’s products.
That’s not all.
Engineers also need the capabilities to check the performance of candidate architectures against factors such as network bandwidth, power delivery, processor utilization, and much more. And they have to do this while considering the potential domino effect that small changes in one area can have across the design.
Of course, developing a great architecture for your E/E system alone isn’t enough. The solution that provides these capabilities must deliver these definitions to your detailed design tools, synchronizing them across the final product as your engineers explore the realization of the detailed design.
