In the evolving landscape of Model-Based Systems Engineering (MBSE), practitioners often face the challenge of maintaining clarity and coherence across increasingly complex system models. As systems grow in scale and sophistication, a structured, methodical approach becomes essential to manage abstraction, decomposition, and integration effectively in a way that maintains definitional consistency. The STRATA methodology is designed to bring strategic order to MBSE by layering system information in a way that supports both top-down understanding and bottom-up refinement. This blog introduces STRATA as a powerful framework for navigating system complexity, aligning perspectives, and enabling iterative development across all phases of the engineering lifecycle.
What is a “Methodology?”
A methodology in Model-based Systems Engineering (MBSE) is a prescribed framework that guides how such practice should be employed throughout the system development lifecycle. It establishes key modeling concepts including:
- Processes: The sequence of activities (e.g., capture requirements then write verification statements).
- Modeling Guidelines: Rules and best practices for creating and managing models (e.g., a function should not be allocated to more than one performing component).
- Tools and Languages: The MBSE tool and modeling languages used (e.g., GENESYS and the Comprehensive Systems Design Language).
- Artifacts: The types of diagram views and documents produced (e.g., Activity diagrams, Requirements table, System Description Document report).
- Roles and Responsibilities: Who does what in the modeling process (e.g., systems engineers, program manager).
- Integration with Other Disciplines: How MBSE connects with software engineering, hardware design, testing, etc.
Some examples of “MBSE methodologies” include INCOSE MBSE frameworks, Harmony-SE, OOSEM (Object-Oriented Systems Engineering Method), and Strategic Layers (STRATA).
What is STRATA?
STRATA, which stands for “Strategic Layers,” is an MBSE methodology built around the principle of handling problems in layers of increasing granularity to strategically converge on a solution. It emphasizes managing the logical decomposition of a system while maintaining the interconnections between abstraction layers, recognizing that systems are inherently hierarchical.
Unlike traditional waterfall approaches, STRATA encourages iterative refinements between layers, allowing changes at lower levels to also influence and update higher levels. This flexibility means practitioners can start modeling with any known model concept, regardless of its position within the systems engineering pillars or abstraction layers.
STRATA enables engineers to work through system layers efficiently while preserving a holistic view of the entire system. Paired with the right tool and language, such as GENESYS and CSDL, the modeler can ensure model consistency, completeness, and correctness.
What Makes STRATA a Unique Methodology?
Since STRATA recognizes the hierarchical nature of every system perspective, it also acknowledges explicitly the relationship between derived requirements and the decisions made in the higher-level architecture. One design change in Layer-n can be traced to affected requirements in Layer-n+.
Built upon the inter-layer and inter-perspective relationships, STRATA allows the systems engineers to model what they know, starting from any cell of the STRATA grid. Engineers can use the built-in completeness and integrity rules of GENESYS to identify gaps and model inconsistencies.
STRATA addresses verification and validation in every abstraction layer. It prioritizes the modeling effort in the proof-space as early as possible. That ensures completeness and robustness of the final MBSE solution.
Overview of STRATA Implementation
STRATA addresses both perspectives on the system and level-of-detail of the system. Put together in a grid, the columns and rows define the modeling activities and artifacts as intersecting cells.
The Columns: Aligning Information from the Four Perspectives
The main four perspectives on the system (or four pillars of a system model) are Requirements, Behavioral Architecture, Physical Architecture, and Verification & Validation. Within one layer of the system (covered by the next section), requirements are the basis of behaviors, behavior is allocated to a physical structure, and requirements are verified and validated. This type of information alignment helps systems engineers gradually progress from the problem space, through the solution space, and into the proof space. Along the way, standard systems engineering techniques may be employed in accordance with MBSE best practices: use cases, risks and concerns, functional threads, physical allocations, etc.
The Rows: Elaborating Details of the System
The layers of STRATA indicate how detailed the system is described within a perspective (or pillar). Row-1 is the most abstract layer: Layer-0. This is where the system context is modeled. It means that Layer-0 requirements are contextual, e.g. originating requirements about the purpose of the system. Layer-0 behaviors are contextual, e.g. how the system interacts with external systems and the environment. Layer-0 physical architecture is contextual, what external systems are connected to the system. Finally, Layer-0 V&V is also contextual, e.g. how originating requirements are verified.
System description in Row-2 is more concrete: Layer-1. This is where the system itself as a complete entity is modeled. Originating requirements from Layer-0 are refined for the first time. System-thread behaviors are transformed into integrated system behavior. First-time physical decomposition takes place. And verification requirements are also decomposed.
Repeat the process
The level of detail gets even richer in Row-3: Layer-2, where subsystems are now modeled. System requirements are further refined for subsystems. System integrated behavior is decomposed and partitioned into subsystem behaviors. As the physical architecture is also decomposed in this layer, the correct subsystem behaviors are then allocated to the correct physical subsystems. Appropriate subsystem V&V is also refined as necessary.
Repeat the process for each subsequent layer until an actionable design solution is achieved. If a pattern starts to emerge as practitioners follow the STRATA grid, they are doing it right: decompose the layers and connect the perspectives.
Keep in mind that such top-down description of the STRATA grid is merely for the purpose of academically explaining the concept. After all, most people understand new information more easily when presented left-to-right and top-to-bottom. In practice, practitioners may start using the grid from any layer, any column, or any cell, depending on the available information about the system. A brand-new system concept will begin with Requirements of Layer-0. A reverse-engineering project will likely start with the Physical Architecture of parts. And a typical R&D project will usually require a close look at some existing system’s behavior – somewhere in the middle of the grid.
Comprehensive Systems Design Language: The Language behind STRATA
The Comprehensive Systems Design Language (CSDL) is Vitech’s modeling language, designed to unify systems engineering concepts across domains: requirements, behavioral and structural architecture, verification & validation, program management, and others. It is based on the ERA model: Entities, Relationships, and Attributes, which allows engineers to build models that are both intuitive and semantically precise. When employed with STRATA, the relationships in the language enable traversal between system perspectives (columns) and abstraction layers (rows).
Although STRATA is created based on CSDL and optimized for it, the methodology may be practiced with any modeling language that recognizes multiple system perspectives and hierarchical decomposition.
GENESYS Views and Diagrams
GENESYS provides a rich set of diagrams, including Requirements, Use Case, State Machines, Block Definition, Activity, Sequence, etc. Due to their purpose-built and precise nature, GENESYS diagrams are suitable and effective when used as STRATA artifacts.
IntegrationConformance with ISO 15288
STRATA aligns with ISO 15288 standards, covering technical and management processes, lifecycle modeling, verification & validation, and integration. This ensures STRATA is not just practical but also compliant with global systems engineering standards.
Conclusion
STRATA offers a powerful and flexible methodology for Model-based Systems Engineering by embracing the inherent complexity and hierarchical nature of systems. Through its structure of system perspectives and abstraction layers, STRATA enables engineers to navigate from high-level system context to detailed subsystem or part design while maintaining modeling coherence across requirements, behaviors, structures, and V&V activities. Its iterative and non-linear approach supports diverse project and system types: from new system development to reverse engineering, making it adaptable to real-world engineering challenges. When paired with robust tools like GENESYS, STRATA not only enhances model consistency and completeness but also empowers teams to converge strategically on effective and actionable solutions.
