Model SoS

Description

A core DANSE concept is that adaptation and evolution of the SoS is controlled through the use of models that can predict SoS behaviour while allowing exploration of alternative architectures.A first solution method is to model the SoS.In the DANSE methodology, modelling is best performed using the Unified Profile for DoDAF and MoDAF (UPDM), while SoS models can alternatively be in any architecture framework that can connect with the Tool-Net.Other usable frameworks include the NATO Architecture Framework (NAF), the DoD Architecture Framework (DoDAF), the MoD Architecture Framework (MoDAF), and System Modeling Language (SysML).This section assumes the use of UPDM.

Initial Situation

SoS modelling starts when the SoS is recognized as such and an SoS manager or architect is interested in managing its evolution.  The SoS may already exist, or the constituent systems may exist and be interconnected, or the SoS may only be envisioned for the future.

Expected Result

At the completion of this solution method, the SoS architect will have sufficient depth of modelling to support an understanding of the SoS.The model elements described herein will support executable simulation through the DANSE Tool-Net.

Required Tools

Different tools are appropriate, depending on the architecture framework chosen for the SoS modelling, but nearly all work for this solution method is performed in a single tool.

-       Rhapsody is appropriate for UPDM models

-       System Architect is appropriate for SysML models

-       DANSE Modelling Extension Profiles provide additional resources.

 

Figure 37.  Tool Flow: Model SoS

Activities

Figure 38 depicts the sequence of activities appropriate to the use of UPDM, DoDAF, or MoDAF.  Simple analogies can extend the diagram to the use of NAF.  In the activity descriptions that follow, the UPDM views that are most critical to the DANSE methodology are indicated with an asterisk (*).  These views are essential to the joint simulation capabilities.

Figure 38.  Activity Diagram: Model SoS

Describe SoS and its environment

The starting point to create a UPDM model is to describe the SoS and its environment.This description provides both textual and diagrammatic information that helps all the following work to stay in context.The following UPDM views are normally useful:

·  AV-1 Overview and Summary – a textual description of the SoS vision, goals, objectives, plans, activities, events, conditions, measures, effects, and products.

·  AV-2 Integrated Dictionary – an architectural data repository with common definitions of terms used throughout the model.

·  OV-1 High-Level Operational Concept Graphic – a graphical depiction of the SoS and its environment as an operational concept.

·  CV-1 Vision – textual or graphical description of the capabilities performed by the SoS along with a vision for how those capabilities are used and fit into the environment.

Describe capabilities (optional)

In a case where the SoS capabilities are difficult to conceptualize or changing rapidly or have dependencies with each other, it may be useful to describe the capabilities in more depth.The following UPDM views may be created as needed:

·  CV-2 Capability Taxonomy – a hierarchy of the capabilities, usually depicted as a SysML Block Definition Diagram.

·  CV-3 Capability Phasing – the plan for achievement of capabilities at different points in time or for different periods of time.

·  CV-4 Capability Dependencies – definition of logical grouping of capabilities with time-based or logical-based dependencies among them.

Describe operational resources

With an understanding of the SoS concept and its environment, the next step is to describe the operational resources that are available within the SoS.Note that operational resources are not usually the same thing as constituent systems.Rather, “resources” can be organizations, people, services, systems, material, or information.  Each resource exists within the SoS and may be used by other resources within or outside the SoS.The following UPDM views should be created, usually in parallel with each other because the information is developed in all three simultaneously:

·  OV-2 Operational Resource Flow Description – a diagram depicting the flow of resources exchanged between operational activities.  The diagram is based on “need lines” that show the need for a resource to perform an operational activity.

·  OV-5a Operational Activity Decomposition Tree – a diagram showing the different operational activities in a hierarchical relationship, usually depicted as a SysML Block Definition Diagram.

·  OV-5b Operational Activity Model* – multiple diagrams showing the activities in operational relationship to each other, with sequences, inputs, and outputs, usually depicted as SysML Use Case and Activity Diagrams. 

Describe operational activities/sequences

The information about activities and resources provides sufficient context to explore the time and logical sequences inherent in the SoS operational activities.  Further executable diagrams help to expand on the relationships, including:

·  OV-6b State Transition Description* – a diagram showing the different operational states of being, the possible transitions among those states, and the events that would cause those transitions, usually depicted as one or more SysML State Transition Diagrams.

·  OV-6c Event-Trace Description* – a diagram showing the sequence of resource interchanges among operational activities in relation to the OV-2, usually depicted as one or more SysML Sequence Diagrams. 

Describe and trace CS functions

At this point in the UPDM modelling effort, the focus shifts from the SoS operational to the constituent systems and services.  With knowledge of the operational resources, activities, and sequences, these can be tied to actual systems and their functionality.  The following UPDM views help to do this.

·  SV-1 Systems Interface Description* – a diagram showing the constituent systems and their interconnections, usually depicted as a SysML Internal Block Diagram; can also be augmented by a SysML Block Definition Diagram.

·  SV-4 Systems Functionality Description* - a diagram of the system functions and the functional interfaces among them, including sequences of functions, usually depicted as SysML Use Case and Activity Diagrams.

·  SV-5 Operational Activity to Systems Function Traceability Matrix – a matrix representation of the parent-child relationship between operational activities and system functions, linking each system function to the operational activities that it supports.

Describe and trace CS functional activities/sequences

For DANSE simulation purposes, the UPDM models are now completed by providing the executable details of the system functions, showing how those system functions work with each other along with the measures that indicate successful functionality.The following UPDM views help to do this.

·  SV-7 Systems Measures Matrix – a matrix listing the technical measures related to the systems and their functionality.  The SV-7 is the source for performance measures and timing to be checked later in the DANSE methodology.

·  SV-10b Systems State Transition Description* - a diagram showing the different states of being of constituent systems, the possible transitions among those states, and the events that would cause those transitions, usually depicted as one or more SysML State Transition Diagrams.

·  SV-10c Systems Event-Trace Description* - a diagram showing the time-based sequence of interactions among constituent systems, usually depicted as one or more SysML Sequence Diagrams.

Describe other features (optional)

Other UPDM views provide additional information concerning the SoS and its relationships.  Some of the other views may be useful in specific SoS models, depending on the complexity and features of the SoS itself.  If desired, these views may also be added to the model.

Limitations

Creation of the many views in any UPDM model can be time-consuming.  Each view provides additional information, and creating each view helps the SoS architect to better understand the SoS – but many of the views provide only incremental benefit for most SoS.It is a wise practice to evaluate each view for its worth to the model before expending the effort to create it.The descriptions above have indicated which views are important to the DANSE simulations, but it is frequently true that not even all of these views are necessary.

Follow-up Solution Methods

This solution method “Model SoS” is the starting point for the DANSE methodology.  Creating the SoS model provides the base information that allows the architect to manage the evolution and adaptation of the SoS over time.  Any of the following solution methods may be selected following completion of the SoS model:

·  Abstract CS model

·  Apply architecture patterns

·  Generate architecture alternatives

·  Generate optimized architectures

·  Perform joint simulation

·  Evaluate emergent behaviour

·  Evaluate goals and contracts

·  Perform formal verification



* Views that support simulation and are thus important to the joint simulation.