InterCAX and Georgia Tech collaborate to provide a lot of MBSE and SysML training. After the introductory course on SysML language, new modelers are inclined to ask, “What next?” They are looking for guidance on how to start using modeling for their own work. They want a process, a methodology, even a template, and these can be very useful in getting to the next level. Outside consultants frequently offer templates, but all of them will admit that “one size fits all” doesn’t work well in this area.
In this blog, I will review a number of different use cases where system modeling can make a powerful contribution to the engineering process. We start with three questions,
- What is the purpose of the model?
- How will model organization support the purpose?
- How will methodology support the purpose?
and offer a few suggestions and observations about the answers for different use cases.
One use case we will not consider involves designing a new system from scratch. The case of a small group of systems engineers/modelers leading system development from use case definition through physical architecture rarely occurs outside of the classroom. Real projects are messy affairs, balancing customer and other stakeholder needs against organizational priorities and resources. SysML can be a valuable communication mechanism in the negotiations, but it is hard to sustain the classic MBSE methodologies in the turbulence.
Documenting an Existing System
Purpose
- Knowledge capture before experts leave organization
- Knowledge re-use as building blocks for creating new products
- System deployment, maintenance and disposal
- Training new modelers using a known system
Organization
The most important parts of the model focus on detailed system structure and behavior. Less emphasis is placed on domain modeling, requirements and simulation, since the purpose and performance of the system are well-known.
Methodology
The V-Model can run backwards, starting with reverse engineering of components from PLM, CAD and software repositories and simulation models, and building the model up to the system level. Tools like InterCAX Syndeia that pull information from other tools into SysML can speed up the process.
Creating a Request for Proposal
Purpose
Procurement organizations can use SysML models as the basis of RFPs, providing the prospective vendors a clear statement of requirements and desired behavior without predefining the structural solution.
Organization
The primary sections of the model are use cases, requirements and system-level behaviors. Parametric analyses can be created in separate blocks, informing vendors what aspects of their models will be evaluated, and how.
Methodology
Good methodologies follow the classic path from uses cases, to requirements, to behaviors. Emphasis is on requirements validation (consistent, complete, feasible, verifiable) and on the traceability from behavior back to requirements back to use cases.
Assessing system safety and risk
Purpose
When a system architecture has been chosen, there is a need to systematically assess safety and risk. Once the system is operational, the model becomes a tool to understand field failures and mission anomalies, often in time-critical situations.
Organization
All aspects of the model must be covered in these applications. Domain-level structure and connectivity are important in assessing system vulnerabilities. Parametrics allow quantitative predictions of system risk. Accommodation for detailed descriptions of the test plan allows failures to be compared against the standards the components were tested against.
Methodology
Careful modeling of both structure and behavior is critical to these applications. In particular, allocating behavior to structure at a detailed level helps trace the impact of component failure. Also, coupling of behaviors at the domain, system-of-interest, subsystem and lower levels helps the modeler identify unpredicted emergent behaviors. Coupling the model to simulations via parametrics supports Monte Carlo and similar approaches for calculating risk.
Evaluating system variants
Purpose
After the high-level system architecture is defined, system engineers are frequently tasked with generating and evaluating multiple system variants in architectural and parametric trade studies. SysML models facilitate the generation of “allowable” variants by clearly defining structure, interfaces and requirements in the same space.
Organization
System-level structure and parametrics are key elements of the model organization. Management of multiple topological variants and/or multiple instances is important for evaluating the results efficiently.
Methodology
The approach typically begins with specifying the common structure, accommodating specializations and multiplicities to cover the alternatives of interest. Measures of Effectiveness (MOEs) are identified and parametric models for those MOEs are attached to the structure. The goal is to evaluate many variants quickly, so minimizing the gap between model and simulation is key. Simple parametric sweeps, design of experiments and more sophisticated optimization methods can be applied when the architectural variants are narrowed down.
Integrating the engineering process
Purpose
In some organizations, the system model is primarily a coordinating mechanism between the different engineering disciplines and project management. It provides a common view of the system, a high-level roadmap of the engineering effort and a clearinghouse for critical system-level information.
Organization
Model organization in this case often reflects the engineering tools and databases used in the organization. The system engineers’ job is to create a traceable network between these silos. Frequently, the model also captures the engineering organization and process as structure and behavior, respectively, providing a project management perspective.
Methodology
The process pulls in engineering artifacts as they are created in a range of tools, including MS PowerPoint and Excel. Tools like InterCAX Syndeia maintain the connection between the SysML elements and the external tools, so that the system model can be updated as the system evolves. The system engineers build the links between these elements and provide visualizations, including traceability within and between tools.
Conclusions
It is tempting to try to combine several objectives in a single model. SysML can support that, but it cannot entirely avoid the usual costs of compromise and confusion. Beyond that, model organization and methodology must also support the specific needs of the team in terms of documentation, review, and decision making.
Rather than a single template, each organization might develop a number of templates distinguished by modeling purpose. Selecting the correct template requires a clear agreement on modeling purpose at the beginning of the project, avoiding wasted effort and confusion later on.
About the Author
Dr. Dirk Zwemer (dirk.zwemer@intercax.com) is President of InterCAX LLC, Atlanta, GA and holds OCSMP certification as Model Builder - Advanced.
For further information, visit us at www.intercax.com or contact us at info@intercax.com