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.