What is middle-out systems engineering?

Middle-out approaches concurrently combine the best aspects of traditional top-down and subsystem-level bottom up development methods. But is it enough?

By John Blyler, Founding Systems Engineering, JB Systems

In school, systems engineering is taught as a top-down process, but in actual practice is involved bottom-up techniques. In the former, the desired system is broken down or partitioned into smaller subsystem in order for requirements, functions and architectures to be decomposed to a point where engineers can begin to build hardware, software, etc.

Conversely, the bottom-up approach begins with the integration of lower level hardware and software components. These subsystems are tested and built-up until the original desired systems is created.  Almost all of the traditional engineering disciplines (like electronic, mechanical, software and network engineering) follow a subsystem or component bottom-up approach.

In reality, most engineers and managers in the real world follow a middle-out or inside-out approach. As the name implies, the “middle-out” systems engineering approach consists of concurrent bottom-up and top-down systems engineering activities. The bottom-up tasks are built on a detailed knowledge of component parts and subsystems that will help to minimize design risk.  The concurrent top-down activities will preserve the customer-focused, requirements-driven emphasis that keeps the system development in a functional domain that optimizes implementation choices.

One of the key benefits of the middle-out approach is the traceability afforded by combining iterative,  top-level requirements-function-synthesis process with the known requirements and functions from bottom-level system elements.  Both executive level and component/subsystem engineers are brought together in this activity to ensure the traceability of requirements. Critical members from both groups will then be involve involved in the design and integration decisions.

Several experts and practitioners would agree – to varying degrees – that most real world systems engineering projects follow a middle-out approach.

“I agree with that may projects “should” take middle-out approaches since so few projects today are creating new systems from complete scratch,” observed Cary Bryczek, Principle Solutions Architect for aerospace and defense for Jama Software. “Things like modernization efforts, developing product variants, and the Internet of Things are all requiring a consideration where the future environment itself is uncertain. But I also still see many projects especially systems being built in the defense space or systems where safety or survivability are critical still are taking traditional top down systems engineering approaches. I suspect a lot of this is driven by contract vehicles.”

Mark Sampson, product manager at Siemens, agrees that a majority of projects involves changes to existing products. However, he prefers the phrase inside-out over middle-out as the former focuses on understanding the impact of a change (add, remove, update).

“Today that process relies on knowledge, talking with experienced people, etc. rather than models to understand the impacts,” explains Samspon. “Of course it all gets much easier if you’ve designed your product for evolving by considering up front what the architecture of the product would be and where the possible areas of change are over time (i.e. anticipate where the future update opportunities are and design the product from the start for change). The label for that is Product Line Engineering (PLE).”

Regardless of the name, most systems engineers must meet both top-down, corporate objectives and bottom-up, product requirements. Fortunately, the growth of Model-Based Systems Engineering (MBSE) paradigm supports a middle-out systems engineering approach. Models can be used in both the top-down, multiple domain architectural and requirements design as well as the bottom-up simulation and prototypes of preliminary system, subsystems and component evaluation and verification. Together, these models provide a platform that combines high-level system models with specific component and subsystem oriented executable models.

The middle-out approach is a recognized in the electronics space. Consider the PCB design tool space where vendors are now being driven both from the top-down and also from the middle-out, notes Paul Dempsey, co-founder of the Tech Design Forum. “For example, Altium community beta members have explicitly reached out to the maker community.”

Related Articles:

• Approaches: Top-down, Middle-out, and Bottom-up
• The allegory of the humidifier: ROI for systems engineering

Originally Published in Design News