An Advanced Approach for E/E Systems Development
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.
Rising Complexity
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 AgendaStudy explored this issue, revealing that:
- 58% of respondents said the complexity of electrical distribution is increasing or increasing greatly.
- 66% of respondents said the complexity of electronics is increasing or increasing greatly.
- 68% of respondents said the complexity of embedded software is increasing or increasing greatly.
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.
The Integration Chokepoint
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 Need for Multi-Domain Visibility
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.
Capabilities for E/E Systems Engineering
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.
Recap
- Systems complexity is increasing across E/E systems, electrical distribution, electronics, and embedded software.
- Engineers making decisions in one domain, while entirely logical in isolation, can conflict with decisions made in other domains. Sometimes engineers catch this fact early and fix it proactively. When they don’t, it results in numerous failed prototypes during testing.
- A progressive approach that resolves these issues involves new solutions that allow engineers to quickly and rapidly explore design changes in a coordinated, cross-domain fashion. These tools provide insight into key performance factors such as network bandwidth and processor utilization while looking at design alternatives.
This is part one of three guest posts by Chad Jackson, who is the Chief Analyst and CEO of Lifecycle Insights. He leads the company’s research and thought leadership programs, attends and speaks at industry events, and reviews emerging technology solutions. Chad’s twenty-five-year career has focused on improving executives’ ability to reap value from technology-led engineering initiatives during the industry’s transition to smart, connected products.
You might also be interested in:
