The V-model has long provided a metaphor for the classic systems engineering (SE) process, but it is problematic in the Model-Based Engineering (MBE) context:

Figure 1 The Systems Engineering V-model

• It does not reflect much of the work systems engineers actually do. Of the six generic use cases we described in Part 1 of this series, only the first, New System Design, is really represented by the V-model.
• SE is rarely about strictly sequential tasks. The reality is parallel development at multiple levels of the architecture and iterative interaction between levels.
• On a strictly graphical level, the narrowing of the V-model as we progress down the first leg is completely at odds with the normal expansion of personnel and tools during this phase. The project is getting larger, not smaller.

As we consider how to develop an MBE process for our own programs, it may be helpful to consider an alternate symbolic representation.

The MBE Wheel

Figure 2 The MBE Wheel

When we acknowledge the cyclic nature of engineering development, a circle is a natural place to begin. The MBE Wheel shown in Figure 2 divides the process into four quadrants

• Design/Architecture/Code represents the conventional view of “creative” engineering, individuals at a computer drafting or programming tool. SE arose because many modern projects involve multiple disciplines that cannot proceed entirely independently.
• Synthesis is the core idea behind MBE, that the many individual models created in the first quadrant must be brought together into a single, consistent Total System Model (TSM). This is the driver for MBE platforms like Syndeia from Intercax.
• Analysis & Simulation is a key part of the engineering process, the earlier the better. Trade studies and risk assessment allow better choices early in the design process when they can still be implemented cost-effectively. But analysis must come after synthesis for the results to be meaningful.
• Verification & Validation compares the results of Analysis against the use cases, requirements and scenarios established for the system and provide feedback for the next round of Design.

It seems clear that the more rapidly organizations can proceed through this cycle, the more effectively and efficiently the system can be developed. MBE platforms like Syndeia work to facilitate this, particularly the Synthesis and V&V quadrants.

New System Design – Phase 1

Let’s apply this way of thinking to the first use case on our list, the new system design process. The first cycle (Figure 3) start with the Concept-of-Operation (CoO) stages, establishing use cases, requirements, and scenarios. This may be carried out in a SysML modeling tool, a requirements management tool, or some combination of the two. These form the foundation for a first attempt at the system architecture, preferably in the SysML tool rather than MS Office or Vizio.

Figure 3 New System Design – Phase 1

A Synthesis phase is required even in the first cycle, to ensure that the combination of requirements, functions, and structure specified forms a coherent whole. A SysML model is an efficient place to do this, and may even be the primary tool necessary in this first cycle. It can also provide the initial analysis capability through plug-ins like the InterCAX parametric solvers. The results of that analysis can be fed into the V&V quadrant to complete the first cycle.

New System Design – Phase 2

After some number of early cycles, the development process expands in terms of people and tools (Figure 4). Domain engineers using CAD or programming environments, and the PLM/ALM repositories that support them, comprise much of the effort in the right-hand quadrant, although the SysML architecture model may remain an important hub of the TSM.

Figure 4  New System Design – Phase 2

The Synthesis process becomes much more difficult because system design data is distributed over many different tools. One task for an MBE platform such as Syndeia is to create a graph of connections between tools that can aid in reconciling the individual engineering efforts.

A second task for the MBE platform is to create model transforms to specialized analysis and simulation tools (e.g. Simulink, Modelica) that are consistent with the current synthesized TSM. A third task is to bring the results of analysis and simulation into the V&V quadrant and provide a snapshot of the current status of system development.

New System Design – Later Stages

As the system development proceeds, more people and tools are brought into the process. More detailed designs and higher fidelity analyses are created. Non-digital activities such as build, integrate and test are executed.

Figure 5  New System Design – Later Stages

The MBE Wheel begins to look like an onion with more and more layers (Figure 5). The demands on the MBE platform increase as well. Rather than create new analysis models, for example, the framework must be able to compare existing models and update them as necessary. Tracing connections across the TSM efficiently becomes a challenge as the number of connections grows.

In agile methodologies, as described in an earlier blog post, the goal is to complete the cycle as rapidly as possible, even on a daily basis. Project management has a clean, up-to-the-minute status report that identifies problems early and allows management to direct resources most effectively.

Next Steps

In this blog post, we have only considered one of the basic MBE use cases described in Part 1.  In Part 4, we will offer a quick overview of how the MBE metaphor plays out in the other ones.

Related posts:

• First Steps in Adopting MBE | Part 1 
• First Steps in Adopting MBE | Part 2
• First Steps in Adopting MBE | Part 3 (this post)
• First Steps in Adopting MBE | Part 4

Tweet