In previous posts, I described multiple types of projects or use cases that system engineers work on and proposed an alternate image to the classic V-model. In Part 3 of this series, I suggested a cyclical spiral of

• Architecture and Design
• Synthesis
• Analysis and Simulation
• Verification and Validation

as a useful representation, what I will call the ASAV cycle.  In this concluding part, it might be useful to consider how this visual metaphor can be adapted to the different use cases.

New System (Greenfields) Design

Figure 1 New System Design

In the last part, we described systems engineering as a counterclockwise spiral, starting from a core Concept-of-Operations (CoO) in the upper quadrant. The spiral expands from the center outwards in successive cycles as more engineering disciplines and tools are involved.  In the case of new system design, shown in Figure 1, we have expanded the Architecture and Analysis quadrant relative to Synthesis and Validation. This is not to minimize the importance of these functions, but to recognize that the bulk of engineering effort is frequently in the detailed design and analysis when new system components are being developed and tested.

IoT Integration

Figure 2 IoT Integration

In more recent systems developments, the balance is changing, with the emphasis shifting to adding functionality through intelligence and networking. These IoT-class systems make use of off-the-shelf components in new configurations. The systems engineer must focus on Synthesis and Validation/Verification of these new systems, shown in these expanded quadrants in Figure 2. However, the overall process is similar to the first use case, starting with a CoO and gradually bringing in more detail, frequently in software development, as the project proceeds.

Figure 3 Reverse Engineering

In the Reverse Engineering use case, the system engineer is starting from the detailed design documents and seeking to recover the deeper knowledge as to how the components combine to create system functionality. Unlike the other use cases, this can be viewed as working from the outside in, starting from the CAD files or software code and working backwards to a more conceptual architecture. The relative balance of effort is in Design, examining the design documents, and Synthesis, finding the connections between them, as indicated in Figure 3. Analysis and Validation/Verification are less critical since the performance of the existing system is presumably well-known.

Variant Evaluation

Figure 4 Variant Evaluation

Variant evaluation describes a project where the requirements and functionality are taken as a given; the goal is to compose and compare multiple design solutions. Object-oriented modeling languages like SysML can facilitate this process.  The same ASAV cycle applies, but the early cycles at the center are not needed, as indicated in the shadowed core in Figure 4.

Model-Based Acquisition

Figure 5 Model-Based Acquisition

Model-Based Acquisition represents a discontinuous process, captured in the shading in Figure 5.  The initial phase for the acquisition agent is to define requirements and function for the system, the inner sections of the top and right quadrants. The model is then handed off to the vendors who develop and propose the detailed design through the intermediate stages of the ASAV cycle. The final role of the acquisition agent is to analyze the submitted proposals and verify them against requirements, the outermost segments of the left and top quadrants.

Failure Analysis and Operations

Figure 6 Failure Analysis and Operations

A key role of the systems engineer is to identify and mitigate failure modes and this job does not end when the system is deployed.  This activity is largely about making connections between the structural and functional elements in the Design and Architecture quadrant by means of the Synthesis tools and processes that have been applied. Figure 6 highlights these quadrants and the importance of an effective MBE platform such as Syndeia for tracing and visualizing these connections.

Next Steps

In this blog series First Steps in Adopting MBE, we have tried to provide some perspectives on evaluating methodologies without proposing or endorsing any particular approach.

• In Part 1, we described some of the different types of systems engineering projects organizations conduct, and the questions organizations should ask in evaluating methodologies for these projects.
• In Part 2, we proposed that effective methodologies should include an interoperability strategy that governs data management and model content, as well as a process flow and model organization.
• In Parts 3 and 4, we examined a pattern for methodologies as cycles of design, synthesis, analysis and verification and how this pattern applies to the different use cases from part 1.

The challenge remains for each organization to develop their own approach to MBE. Our goal has been to provide a means through which organizational needs and capabilities can be incorporated explicitly in that development.

Related posts:

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

Tweet