Methodology - STRATA

STRATA: An MBSE Methodology for Consistency and Completeness

Adopting an ad hoc systems engineering method in the face of today's complex program environment can quickly lead to project failure. Launching your critical projects without a sound approach to systems engineering is risky, potentially setting your project back beyond recovery and costing you future opportunities.

STRATA is a practical methodology developed around well-proven engineering principles. Hundreds of programs executed over four decades have leveraged the clear logic and value delivered from STRATA's layered, iterative approach. Teams of engineers come together more quickly and gain deeper insight.

Migrating to model-based systems engineering (MBSE), enhancing your existing efforts, or recoving from previous failed MBSE initiatives is easier when you follow the STRATA methodology. The agility of an executable, model-centric design, built with a layered approach, means your engineering team can take on more projects, have less rework, and demonstrate deeper traceability. This prized combination makes your organization more competitive, lean, and profitable.

What is STRATA?

STRATA is an MBSE modeling methodology.  An MBSE methodology is a documented set of design tasks and organizational structure that ensures that everyone on the team is building the system model consistently and working towards a common end point.  An MBSE methodology is one of the three fundamental pillars of MBSE.

The STRATA name comes from a stylistic concatenation of the term "Strategic Layers." It consists of three fundamental concepts:

• Layers (rows): gradual elaboration of the system definition through refinement and derivation to converge strategically on the solution

• Pillars (columns): logical groupings of systems engineering concepts (as defined by INCOSE Systems Engineering Handbook, v5 and ISO-15288).

• Traceability between rows and columns to establish consistency & completeness. Iteration is necessary between the layers and pillars.

What Differentiates STRATA from other MBSE Methodologies?

Most MBSE methodologies address the following concepts:

• Decomposition:  a structured means of decomposing a system architecture from high level, more abstract concepts, to lower level, more concrete, refined, and specific concepts. Some define patterns of aggregation for building a system from lower-level piece parts. 

• SE Concept Groups: categorical groupings of systems engineering concepts (classes and relationships).

• Roles: a definition of the individuals or roles withing an MBSE modeling team that are responsible for executing specific tasks.

• Tasks and Task Sequencing: a definition of the ordered tasks or processes required to generate and maintain a complete MBSE model. 

• Visualization Overview Diagram: a diagram or visual representation of the structure of the methodology in terms of concept groups, decomposition levels, roles, and/or task sequences.  These visual representation diagrams are often implemented as a navigable diagram in an MBSE tool that provides support for the methodology. 

What makes STRATA unique:

• Derived Requirements Depend Upon the Higher Level Systems Architecture: STRATA explicitly acknowledges the relationship between derived requirements and the decisions made at the L+1 higher-level architecture.  Derived requirements are not generated in a vacuum siloed from the systems architecture; rather, they are informed and/or constrained by design decisions made in the functional and structural architecture.  GENESYS and STRATA formally acknowledge and show this traceability - something that stand-alone requirement management tools cannot do.

• Model What You Know: Start anywhere! There is no need to attempt to enforce a purely unrealistic top-down or bottom-up design process.  The real-world almost never delivers pue clean sheet design projects relevant to top-down waterfall methods or other design sequences that can be clearly spelled out prior to project start.  Often, organizations look to re-use or upgrade existing systems or components that are to be used in a new system, and these can be at various levels of a system architecture hierarchy. Requirements are often a combination of top-level customer needs and constraints as well as internal/enterprise reuirements and constrants which can often span system layers.  Customer needs or requiements may be incomplete or are communicated/captured in disparated chunks. STRATA allows you to capture any information relevant to the system specification and design as you can gather it, regardless of where it fits in the system specification and architecture. Use the built-in completeness & integrity rules to identify gaps and inconsistencies to ensure your system architecture specification is self-consistent, complete, and correct. 

• Prioritization of the importance of Verification & Validation: Other methodologies based on SysML v1.x lack the robustness of the V&V capabilities embodied within CSDL and STRATA. 

Pillars

STRATA, along with the systems engineering and program management language concepts embodied within CSDL, provides modeling teams the ability to capture enterprise engineering, program management, and systems engineering and architecture data in 6 pillars.

• Program Management:  Capture the details of the designing system: the organizational structure, WBS, risks & opportunities, concerns, defined terms, and program activities. Tie into the system architecture to define who is responsible for what and when. 

• Requirements: Define what the system must achieve & under what conditions.

• Functional Architecture & Behavior: Define what the system must do. Build in the desired emergent behavior.

• Structural Architecture: Define the building blocks, including how they decompose, how they interface, and what they transfer.

• Validation & Verification: Ensure you’re building the right thing and building it right.

• Specialty Engineering: Optional add-on extensions such as FMEA. 
  

Four of the pillars are considered "core" ii that they are fundamentally necessary to specify and design a complete and consistent system architecture.  The four core pillars are Requirements, Functional Architure & Behavior, Structural Architecture, and Validation & Verification. These must be completely defined to the team-specified layer of decomposition to constitute a fuly specified and defined systems architecture. 

Layers

Define the designator numbers and names for each layer.  In “Edit Schema” mode, add a new attribute named “layer” of type Enumeration to the Element abstract class, which will make it applicable to all entities in GENESYS.  Add values for each layer designator and name. The numbering and naming convention should be tailored to the terminology used in your organization or program.  Define each layer name and layer designator using an entity of type Defined Term. A typical set of layer designators and names are shown in the table below. (Note: the starter STRATA.gnsx template includes the layer attribute.)

STRATA Implementation Guidelines

A model can grow to tens of thousands for a moderately complex system to over a million elements for a highly complex system. With that level of complexity, model organization and management practices become absolutely necessary.  Even for smaller models, implementers of the STRATA methodology can reap major benefits from implementing the following best practices:

• Define your Layers: see the section above

• Configure Packages: Under Basic Packages, create a Package for each layer in your hierarchy. Optionally, create a subpackage under each layer package for each STRATA Pillar.

• Configure Folders: For each major class utilized in the model, create a subfolder for each layer.

• Utilize STRATA Pillar Facilities:  Use STRATA pillar facilities to filter the Project Explorer to just the classes relevant to the pillar on which you are working. 

• Create Layer Consistency Tables: For each layer, create a table using metachain navigation to show the entities, relationships, and related entities across each STRATA Pillar.  Use these to identify allocation gaps, missing entities, and orphan entities.  

• Create Allocation Matrices: Within each layer, create an allocation matrix to bridge the gap between each pillar.  Use the matrix to identify allocation gaps.

• Create Derivation Matrices: Within each pillar, create a derivation matrix to bridge the gap over each layer.  Use the matrix to identify orphan lower level entities. 

• Utilize Layer Node Templates: Apply the STRATA Layer node template to diagrams to visually display the layer designator of each entity.  Identify incorrect allocation of entities to layers.

• Utilize the STRATA Organization script:  Run the STRATA Organization script to organize the entities in your model into the designated layer-based folders and packages.

Support for the 3 Systems

We often focus on the system that we’re designing, but there are other related systems that are important to acknowledge due to their interactions with our system under design and the impacts that they can have on that system.  

• System Under Design (System-of-Interest - SOI): This is what you’re designing, building, testing, and fielding.

• Context System:  This is the environment in which the system-of-interest operates.  It almost always involves human-system interactions.

• Designing System (Enterprise System):  The company, including the tools, processes, policies, procedures, people, equipment, other resources and culture that design the system-of-interest. 

STRATA, along with CSDL, provides the structure, breadth and precision to model each of the three systems.  Vitech's solutions can assist with modeling and managing the interrelationships between each of these three systems.  

The STRATA framework is aligned to support the modeling of each of these three systems as well as their interfaces with one another.  The Designing System is modeled in the Program Managemt STRATA Pillar.  The Context System is modeled as layer [L0] across the Four Core pillars and, optionally, the Specialty Engineering Pillar.  The System Under Design is modeled as [L1] to [Ln] across the Four Core pillars and, optionally, the Specialty Engineering Pillar. Relationships exist with CSDL to seamlessly tie together the 3 Systems into a consistent, coherent, and correct model. 

STRATA Modeling Patterns

Top-Down

As acknowledged before, no real program is truly top-down, but as a general pattern for guidance, the following steps can be used for a mostly new, "green field" system.

• [L0]: Capture all stakeholders, enablers, and constraints. Define the system boundary. Define external interfaces in terms of stimuli & response. Extract and/or derive needs and externally visible behaviors. Solve Use Cases using Thread Analysis. Iterate between Requirements, Functional Arch, & Structural Arch to achieve a consistent and complete definition of the system.

• [L1 to Ln]: Zig zag—the architectural decisions made at a level above impact, inform, and constrain the requirements derived at the next lower layer. Repeat at each lower layer.
  

  

  

Derivative System / Upgrade

If there is a previous version of the system that exists, some variant of the following pattern can be used:

• [Ln]: Start with updating the functional & structural architecture of the new Ln element(s). Check for conformance with Ln requirements and completeness across the layer.

• [Ln-1 to L0]: Work upwards, tracing the updated  [Ln] functions, behavior, and structure to their higher level requirements, functions, behavior, and structure. Check for incongruent physical interfaces, incompatible higher level behavior, or requirements.  Resolve issues.  Continue upward, ensuring that system functionality is preserved & all requirements are satisfied.

STRATA and the Digital Thread

Provide the right information at the right time for the right intent in the language & format that the consuming stakeholder can understand.  The goal is to facilitate better decision making, reduce errors, and eliminate non-value-added manual data exchanges and communication.  For each interacting tool, define the purpose of the exchange, stakeholders involved, appropriate layer of MBSE model, & necessary information to exchange plus context. Agree on handoff layer (L3 in example below). Capture necessary information in a designated DTPackage, which acts as the Digital Thread “Port” into and out of GENESYS. As needed, define a Viewpoint to apply masks and mappings to the DTPackage data as it is exported from GENESYS.  For the specified purpose & phase of the project, define which tool acts as the Authoritative Source of Truth (ASOT) for each data item, the workflow for exchanging information, & the process to make changes to the ASOT

Summary of Benefits

Repeatability Drives Efficiency

Duplicating project success is the key to growing organizations and maintaining systemic profitability. A portfolio of disjointed systems projects applying different systems approaches creates management overhead and impedes effective communication. Failure to consistently apply a shared approach impairs cross-project exchange and inhibits corporate learning.

STRATA helps you standardize your systems development and ensures that projects communicate effectively, leveraging common concepts and language. This brings efficiency to your organization and drives down the risk and cost of each project. The repeatability of the STRATA methodology allows your engineers to easily transition between projects, empowering corporate agility, and accelerating project success.

Approachable and Trainable

Engineering teams must be able to grow and develop in capability. As new engineers join projects, it is critical that they are provided the tools and processes to help them contribute quickly, and stay aligned with the rest of the team. Easy to learn and apply, STRATA enables your team to come up to speed quickly and become proficient system practitioners.

STRATA's consistent language allows engineers to collaborate more efficiently. Systems development best practices are more easily shared when they can be discussed with a common vocabulary and rich models, rather than disjointed drawings from dissimilar tools.

Adaptable to Change

Changes in your project will occur. Your ability to handle the inevitable shift in milestones, requirements, or operating environment determines project success or failure. The STRATA approach gives you the ability to respond by showing you how to build flexible system models in a way that can be quickly changed without costly rework. Building and rebuilding models takes less time, meaning you have more time to evaluate decisions and determine the best course of action.

At a time when you need answers and a quick response, STRATA provides help, not hindrance. Reuse of model components, iterative verification, and logical interface connectivity provide you the tools you need for rapid recovery from change.

Results

Building the right model in the right way means your team will have more time for thoughtful analysis, intuitive decision-making, and winning responses to customer needs. Understanding cost trade-offs and performance risks in the face of evolving requirements can only be done successfully with a highly integrated system model. STRATA helps you organize your work and your team to build meaningful models that enable rapid trade-off analysis and early insight.

Empower your entire system team to design in confidence and take command of project success by applying the STRATA methodology.

To begin engineering project success, contact Vitech's professional services group, and learn how to implement the STRATA methodology at your organization. Details on STRATA can be found at www.vitechcorp.com, including a free electronic copy of our MBSE Primer, the STRATA Quick Reference Guide, and the STRATA .gnsx project template.