Validating Systems Architectures from the Bottom Up

Validating Systems Architectures from the Bottom Up

Menu

Thanks to advancing technology, products are becoming more feature-rich and in turn, more complex. They must incorporate sophisticated electronic and electrical systems to provide the interconnectivity and user experience modern consumers demand. As a result, many organizations increasingly rely on systems engineering.

In this post, I’ll dive into some common issues with developing systems architectures. I will focus on how to increase collaboration between detailed design and systems engineering teams through a validation step right before detailed design starts.

Making Systems Engineering Work for Your Company

Your systems engineers are experts in their domain. They provide a unique skill set that is hard to find in the industry. It often takes years of experience to refine and hone their capabilities. Doing systems work is not easy. And systems practices can make a tangible difference.

However, the process is far from perfect. Too often, detailed design teams are dead in the water right from the beginning. They usually don’t know it yet.

Driving Systems Architecture from the Top Down

Today’s systems engineering processes typically take a top-down approach. First, you take the definition of your customer requirements, and then break those down into technical requirements. Next, you must allocate these technical requirements to functions. You then fulfill these functions with logical architectures and translate them into a physical, systems architecture.

These tasks are an arduous undertaking. It requires your organization to implement a range of cultural changes, role and responsibility adjustments, process and procedure modifications, and new technologies. Even if you perfect your upfront systems engineering processes, there is no guarantee that your systems architectures will always be on target.

Why? Because some systems architectures are not feasible in a real operating environment. In the worst-case scenario, your detailed design teams are stuck with a series of impossible requirements, in other words, an over-constrained design. These no-win situations lead to dramatic delays causing your organization to fall short of project deadlines and budget.

Validating Systems Architecture from the Bottom Up

There is a better way. You can avoid these situations by incorporating a new phase into your systems engineering process. The purpose of this phase is to ensure the feasibility of an initial systems architecture. In this phase, your detailed design teams assess, simulate, and validate the system’s definitions and architectures.

This effort manifests as concept design work. It includes rough designs, simulations, and abstract definitions. Teams working in different domains might have different validation approaches. For example, an electronics design team might assess the processor power requirements and heat dissipation constraints. An electrical engineer might validate network bandwidth. Systems engineers and design teams must collaborate here.

Note that this step is a final check that must happen before the detailed design phase starts. Verifying the systems architecture’s feasibility before investing in its design allows you to get it right the first time.

While this additional step is crucial, it does not perfect the process. But it does catch unrealistic or infeasible constraints and requirements early on.

Enabling Systems Engineering Collaboration

So, how does this new phase of the systems engineering process work? As I’ve mentioned, collaboration is the key to boosting your final systems architecture solution. Let me explain what I mean.

Your engineers must work with your detailed design teams. They need the right conceptual capabilities to explore many design alternatives. They also need simulation and design check tools to assess if the design addresses the requirements and constraints defined in the system architecture. But note that the tools used in the phase are not necessarily the same as those used in detailed design. Engineers on the detailed design teams must complete these validation checks very quickly, resulting in an acceptable level of confidence that the design is realizable. Remember, this new phase’s activities are executed as a final step to the initial system architecture definition, not to do the detailed design work.

Recap

  • Systems engineers do great work. They have unique skillsets that translate into tangible benefits for their companies. However, as the model moves into implementation, there is risk that some aspects of the design are over-constrained, and therefore unrealizable.
  • A typical systems engineering process breaks customer demands down into technical requirements. These are allocated to functions, logical architectures, and then physical architectures. However, this top-down approach often leaves detailed design teams with impossible requirements. As a result, you can see dramatic delays and overruns across your development lifecycle as design teams discover they cannot meet the requirements.
  • Your detailed design teams can avoid these problems by performing a final check to assess, simulate, and validate the systems definitions and systems architecture. You can identify unrealistic or infeasible constraints and requirements before detailed design begins.
  • Your teams need conceptual tools that will let them quickly explore many design alternatives. To validate performance, they need simulation analysis capabilities. It is vital to choose programs that are fast, agile, and efficient.

For more information about MBSE, systems engineering, and digital engineering visit our Digital Engineering web pages, or read more systems engineering blog posts here.


 

Chad Jackson
Chad Jackson
Chief Analyst and CEO of Lifecycle Insights
Chad Jackson 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.