Top-down and Bottom-up Architecture Verification

Products are increasing in complexity at an astonishing rate. Smartphones are just one example: today’s devices combine the functionality of yesterday’s phones, cameras, calculators, and pagers and place desktop applications and internet browsers in the palms of our hands. Advancing electrification, mass miniaturization, and IoT-driven digitization are making a vast range of devices smarter and smaller.

To cope with these changes, manufacturers must transform the way they develop complex systems. This post compares and contrasts the traditional and modern approaches to developing and verifying products.

The traditional approach: design, build, test

The traditional design approach follows a process that looks like this: system architects and engineers take high-level product requirements and distribute them across teams. Each team starts its design work, documenting requirements and sub-requirements and their development plans. If the work of one team is likely to have an impact on that of another, there may be some loose communication between them. In general, though, teams work separately. They perform quick, abstract calculations and capture them on custom spreadsheets. With this disjointed approach, everyone keeps their head down and gets on with the job until every team is ready to move to the prototyping and testing phases.

On paper, this may look like a feasible way of working, and when the end product is simple, it may be. But in practice, inconsistent design processes create problems, especially with complex products. For example, one team may come up with an innovative way to work within the constraints on its requirements. Another team may tweak its requirements to produce an elegant solution. Other teams may push back on their requirements and request significant changes because they believe the requirements are infeasible.

Thanks to the diversity of these approaches, the teams’ designs diverge, begetting problems that will become manifest only later in the product development lifecycle when different teams’ designs must come together. Indeed, without an established and robust way to conduct spreadsheet calculations, every team’s results could be dramatically off the mark, allowing poor-performing designs to move straight into the testing phase. Simply put, because there is no communication across teams, their approaches are opaque and inconsistent, and problems creep in.

In the prototyping and testing stages, these problems become evident. The proposed design is amalgamated by the testing and design teams to create a prototype, which has issues—perhaps thousands of them. When tested against original requirements, the prototype fails. The design teams go back to the drawing board, change the design, and create another prototype at considerable expense, only for it to fail again during testing. Then, another prototype is created, and another, with each iteration needing more work and failing testing. The project incurs significant delays, and costs mount.

The modern approach: model, analyze, build

The modern approach is quite different from the traditional approach. Collaboration, visibility, and consistency are at its core. Systems engineers, architects, and design team leads work together to create a digital model of the entire system. The model incorporates all system requirements, functions, logical architectures, and physical architectures while allowing individual teams to work within their areas of expertise.

This approach, model-based systems engineering (MBSE), is highly dynamic. Changes to the model can be made on an hourly basis. The system’s central single source of truth governs such changes, so the engineering and design departments’ activities are coordinated. As teams move into the detailed design stage, they can change and tweak their designs or request changes to requirements without disrupting the final design. This is possible because when a design team makes a change, it is visible across all departmental teams. Therefore, everyone has the same information, so different teams’ work does not diverge.

This modern approach is also highly iterative, enabling teams to run a variety of simulations and analyses to test the impact of their changes on the design and verify performance at the system level. Therefore, teams will have insight into the feasibility of the project’s requirements. Design teams apply MBSE to every sub-system design, giving the team confidence in their individual work while guaranteeing that the overall system performs as expected and fulfills its requirements.

When the design moves to the prototyping and testing stages, the benefits of this modern method are clear. Because simulation and analysis have allowed teams to test and verify their designs in the virtual world, when they move to the physical domain, there are no nasty surprises. Simulation and analysis help uncover and resolve issues. The common digital thread running through MBSE provides much-needed consistency and visibility to design and engineering teams. In physical testing and prototyping, the design passes most tests on the first pass, helping organizations meet their product deadlines within budget. In other words, the consistency and collaboration of this modern, bottom-up approach give organizations a way to expedite their product development processes.