The Mumbri Engineering Process is heavily influenced by the Prince2 and Agile methodologies. It is intended for highly regulated or safety-critical environments, but it is appropriate for any complex systems engineering task. The primary innovation of Mumbri is the focus on highly automated processes, reducing administrative overhead and improving process accuracy and reliability.
If change management is a concern, Mumbri can help. If more than two subject matter experts are required, Mumbri will save on costs. And if Multi-disciplinary optimization is involved, Mumbri will keep the team synchronized.
Process Objectives
The goal of the Mumbri Method is to reduce errors in prototype integration. It is in the integration phase that costs grow uncontrollably, as previously invisible design conflicts become apparent. The means to achieve this is by identifying design conflicts early and by allowing for design changes late in the process.
The Mumbri Method is designed around the following specification, and its effectiveness therefore measured against these requirements:
Must Have Features
- Must Provide a “Single Source of Truth” for all technical decisions
- Must derive as many requirements as possible early in the process
- Must provide at least semi-automatic documentation generation
- Said documents shall be acceptable to the certifying authority (if applicable)
- Engineering Decisions must be traceable from source to final engineering artifact (“Digital Thread” capability)
- Must have version control
- Must have robust change management capability
- Subsystem requirements must be testable, ideally with test-driven development
Should Have Features
- Should be compatible with Agile Development Methods
- Process should be easy to learn for subject matter experts and design engineers
- Overall process burden should not exceed 10% of work time and effort
- Should have diff/merge capability
- Subsystem Requirements should be automatically generated
- Requirements tests should also be automatically generated
Out of Scope
- Access restriction (for security clearance or IP purposes) is not to be considered at this stage
- Automatic generation of designs is out of scope
Version Control : The Foundation
As a design evolves, it necessarily passes through phases of functionality and non-functionality. Changes to a working system are likely to break in unexpected ways, and non-working systems need to be changed in order to become functional.
The Agile method is centered around iterating over a working system, and therefore tries to achieve a “minimum viable product” as early in the design as possible. Therefore, agile methods in particular pass through many cycles of fixing and breaking a system as it is improved.
These changes lead to the problem of managing the state of the system. If many changes happen at the same time, it becomes hard to know which change broke the system. Further, certain changes in combination break (or fix) the system, and simply recreating the state of the system at a given time becomes quite difficult.
Version control systems are the solution to the above problem. They efficiently create “snapshots” of the system through time, and both broken and working versions of the system can be recreated on demand. Further, they effectively allow for “tamper sensitivity”, logging changes made to documents by whom, when, why, etc.
Mumbri therefore requires a version control system to function effectively. We recommend Apache Subversion (SVN) for teams that are new to version control, and git for teams that are more familiar with the concept. The latter is more feature rich, but allows for more branching and has more complicated synchronization procedures when compared to SVN.
Model Based Systems Engineering (MBSE)
MBSE is the tool used to understand a system before it is designed and built in detail. We recommend the Arcadia methodology, which is supported by the Capella modeling program. SysML 2.0 is a promising development, but is not yet ready for production use.
MBSE allows systems engineers to construct models of complex systems, and thus explicitly define all of the interfaces between subsystems. It is in principle an exhaustive list of all potential design conflicts in a system, allowing conflicting design decisions to be caught and eliminated before more consequential engineering effort is expended. Trade studies can be more thorough, and design consequences explored in detail.
Later on in the design process, MBSE allows for a machine-readable method to explore the consequences of changes, greatly simplifying change management. In principle, proposed changes can have automatic cost estimates generated “on the fly”, simply by reading the list of affected systems.
Arcadia provides a framework to derive a complex system from top level design requirements, making it ideal for early-phase systems design. Capella, the leading implementation of Arcadia, has extensive plugins allowing for management of parameters and requirements, as well as late-stage tools for FMECA and automated document generation.
Simulation and Multi-Disciplinary Optimization
The point of divergence between agile hardware and software design is the ease of testing and simulation. Software can be tested robustly using software tools, principally because it doesn’t actually need to be simulated. Software under test can simply be run under normal conditions, or in a simulated environment. The software itself can be the real thing, and one can have confidence that it is representative of itself.
Hardware, on the other hand, must be simulated or prototyped in order to observe its behavior. Simulations are necessarily imperfect, and prototypes are expensive to produce. Worse still, hardware systems often have features that fall within multiple disciplines, such that multiple subject-matter experts have to look at aspects of the system separately and with different tools.
Mumbri attempts to manage this hurdle with tools such as OpenMDAO, which provides a framework for multi-domain simulation.
The crux of the matter is that simulations are valid for narrow design spaces, and invalid outside of those ranges. The Mumbri approach is to ask subject matter experts to explicitly state the valid ranges of their models, and to throw errors when design parameters fall outside of those ranges. It is then the prerogative of the project manager to either request a new simulation or to limit the design parameter to the valid range.
Feasibility Studies
Once an architecture has been decided upon and all of the subsystem requirements enumerated, Mumbri requires a critical step be undertaken : Feasibility Studies.
As a systems engineer, I work under the constant assumption that I am the least informed about the state of the art of a given domain until proven otherwise. A systems architect necessarily has too broad a view to be up to date on all relevant technologies. Thus, subsystem requirements, published as “specs”, must be validated by specialists in the relevant domain.
This step allows for the elimination of unrealistic features and subsequent cost overruns. If certain critical specs are found to be unrealistic, alternative architectures can be selected from the preceding MBSE work. Alternatively, if a system must exceed the state of the art, that fact will be highlighted at the beginning of the project, when appropriate resources can be allocated to that need.
Error Checking and Change Management
Finally, despite the best efforts of the system engineer and project lead, the system architecture is likely to be wrong or suboptimal in some way. Change management is necessary to adapt the planned system to the observed reality.
Here, many tools from agile methods are taken and adapted to hardware engineering. Continuous Integration tools such as Jenkins are used to test nightly builds of the system, based on CAD data and other sources. This in turn, requires discipline in using test-driven development to make violations of design assumptions machine testable.
As an example, in tightly packed mechanisms such as in aerospace systems, we propose the definition of “assembly” and “range of motion” volumes, in addition to the solid forms of parts usually defined in CAD. These volumes then have rules (eg: parts cannot exist within another parts range of motion, assembly volumes can only be occupied if the assembly order is respected, etc.) which can be checked for violation by a Jenkins script.
Once errors have been detected, changes can be proposed. These changes will have impacts that can be identified using the MBSE model. Thus, change proposals can have an immediate cost estimate, and can be compared to one another objectively on the basis of performance and cost.
Tying it all together
These processes and systems are the necessary elements for continuous integration in a hardware context. In other words, these tools, taken together, allow for the state of the system to be known at all times, and to move freely between iterations until at last a production-ready system is built and tested.
The above flowchart shows the flow of engineering data from initial requirements, through the MBSE process and into optimization phases and detail design. Some documents have not been described (such as the N2 diagram), but are necessary for the tracking of data flows in detail.
Mumbri Systems will be developing Mumbri EDM over the next few years, a project management framework automating much of the Mumbri Process. It will be, as much as possible, tooling agnostic, allowing your team to use the best software for the job without vendor lock-in to a set of engineering software packages.