A Data-Centric Approach for Model-Based Systems Engineering

3.1 High-Level Data Meta-Model

According to the model driven architecture with the meta object facility designed by the object management group[11], systems models can be organized within a four-layered architecture. The meta-model (model of model or model of metadata) of this four-layered architecture typically defines the abstract syntax of models and the interrelationships between model elements. That is, it is usually defined as a set of concepts or model elements, as well as the constraints and rules for how they may be arranged and related to build models without necessarily providing the concrete syntax of the language[12]. Accordingly, the meta-model is independent of modeling languages and tools, providing the basis for comparing and integrating the models across different MBSE methodologies. It thus ensures data consistency, and facilitates the automatic construction of some models from previously defined data[13,14]. In the three core steps of SEP, there always exists a need to answer a serious of questions to collect information on the requirements, functions/behavior, and architecture (RFBA) of the system. These questions can be grouped into six semantically complete communication interrogatives, i.e., WHO, WHERE, WHAT, WHEN, WHY, and HOW (5W1H)[15]. Clearly, 5W1H, as the high-level data concepts representing the six different aspects of the RFBA respectively, can be used to collect all the key information and thereby capture the core data elements for all steps of SEP. Moreover, as the data taxonomy of models at the highest level, 5W1H can ensure the consistency in the meaning of each data elements, in order to eliminate the aforementioned problems in current MBSE methodologies. As shown in Figure 2, 5W1H, as well as their logical relationships of how they may be arranged and related to build models, constitute the high-level data meta-model. It can be summarized as an integrated dynamic model of sequenced Activities (HOW) and their Events (WHEN) performed by Performers (WHO) to produce and consume Resources (WHAT) in Locations (WHERE) under specified Rules and Conditions (WHY)[16]. If performance parameters and measures are incorporated into a basic executable model constructed from core data elements and their associations, quantitative decision-making analysis in the practice of SEP can be supported effectively. The data meta-model formalizes general or high-level data concepts and their associations with standard terminology and formal semantics. Thus, in the whole SEP, all the necessary data elements in accordance with the data meta-model can be collected, maintained, and shared among various organizations as a common, consistent, and integrated data dictionary.

Figure 2

High-level data meta-model based on 5W1H

3.2 Data Modeling

Based on the above high-level data meta-model, all the necessary data elements in the whole SEP can be captured around 5W1H. These data elements can be divided into three object classes: entities, relationships among entities, and attributes of entities and their relationships[17]. Figure 3 depicts the whole process of the proposed approach, and shows the data entities in different steps. In order to reduce the complexity of the picture, the relationships among entities and their attributes will be discussed later. Note that there exist corresponding relations between the data elements in different steps. For example, the Capability, Operational Activity, and System Function are connected by the relation of HOW, indicating that the three data entities are all derived from HOW that is one of the high-level data concepts. Thus, they are just different representations for the same semantic content in different steps of SEP. In particular, the elements of the functional/behavioral analysis and architectural design steps are symmetrically aligned with each other within each of the 5W1H. As shaded in Figure 3, these data elements representing the semantic concepts of 3W1H (i.e., HOW, WHO, WHERE, and WHAT) are the core entities for SE, which are also considered as the core modeling primitives with the meaning of HOW performed by WHO at WHERE to produce/consume WHAT. As shown in Figure 3, the proposed approach includes the following three steps.

Figure 3

Data elements of the three core steps

3.3 Mapping Associations among Core Entities

Around 5W1H, all the necessary data elements in accordance with the aforementioned high-level data meta-model are captured for different steps of SEP in a semantically complete and consistent way. No doubt, these data elements are considered as the center and basis of the whole SEP. More specifically, Capability as the core data entity is really the foundation of the collection, modeling and analysis of requirement-related data in Step 1. And the functional/behavioral analysis is carried out around Operational Activity in Step 2. With regard to the step of architectural design, it focuses on both of System and System Function, each of which is the core data entity. According to the guidelines on data meta-models and view products provided by the latest U.S. Department of Defense Ar-chitecture Framework (DoDAF 2.0), the core data entity Capability can be successively mapped to System Function and System with the products Capability to Operational Activities Mapping (CV-6) and Operational Activity to Systems Function Traceability Matrix (SV-5a), and the view products in Systems Viewpoint (SV)[19]. Therefore, the mapping associations among the data entities in Figure 4 and the requirements traceability matrix in Figure 5 are established.

Figure 4

Capability mapping process

Figure 5

Requirement traceability matrix

On one hand, the mapping associations among the data elements effectively solve the aforementioned problem that the elements of models are hardly associated in current MBSE methodologies. On the other hand, with the requirements traceability matrix, it becomes quite easy to identify whether the capabilities are supported by corresponding system functions and realized by the systems or not, thus the requirements verification is no longer a big headache. For example, as shown in Figure 5, there exist mapping associations between Capability 5 and System Function Β and D, while the two system functions are accomplished by Systems 1 and 2 respectively. Clearly, this capability can be realized or the requirement be satisfied if only the two systems exist simultaneously.

According to the above approach, the data elements are the center of the entire SEP, while the models are just the visualized representations of them. That is, all kinds of view products can be utilized to organize these data elements to form fit-for-purpose models and thereby support more powerful description and analysis. Thus, the forms of the model should/can be selected or customized according to specific problems, not limited to the DoDAF-described view products.

Step 1

Capabilities (HOW), as the core data entities, include the air defense capability and its sub-capabilities. The de-composition is the major relationship among them. Therefore, all kinds of visualized models can be used to organize these data elements to carry out complete requirements description and analysis. Here the view product Capability taxonomy (CV-2) is utilized to describe these data elements, as shown in Figure 6. Note that, the leaf-level capabilities are considered as the functional requirements, which are the inputs of Step 2.

Figure 6

Capability taxonomy (CV-2)

Step 2

Based on the functional requirements in Step 1, the data elements are captured around 5W1H, as follows: Activities (HOW) include Fly In, Issue Surveillance Directive (Surv_Dir), Issue Interception Directive (Int_Dir), Issue Locating Directive (Loc_Dir), Issue Assessing Directive (Ass_Dir), Track Target, Control, Intercept, Locate Target, Assess Kill, etc. Performers (WHO) include Intelligence, Surveillance, Reconnaissance (ISR), Command, Control, Interceptor, and Enemy Target, each of which is considered as the Operational Node. Locations (Where) correspond to Performers in this example. Resources (WHAT) include Enemy Targets, Interceptors, and other command and control (C2) information. Desired Effects (WHY) is to expel or destroy the Enemy Targets. Events (WHEN) include: 1) As soon as the enemy targets are detected and identified, the ISR will track them, collect relevant information, and send information to the Command; 2) According to the received information, the Command makes decisions and issues orders after a serious of analysis; 3) After receiving the orders from the Command, the Control schedules the interceptors to intercept the enemy targets. 4) Finally, the ISR collects relevant battlefield information again, in order to assess the effect. Similarly, according to specific problems, the fit-for-purpose models can be constructed based on the captured data with the support of specific methodologies and presentations. Also, some DoDAF-described view products in OV can be selected to organize these data elements to support visualized analysis. Constrained by the page limitation, this example only gives an activity diagram with swim lanes, namely Operational activity model (OV-5b), to illustrate the sequenced activities needed to provide the desired capabilities, as shown in Figure 7.

Figure 7

Operational activity model (OV-5b)

Step 3

As discussed earlier, the data elements of Step 2 and 3 are symmetrically aligned with each other within each of the 5W1H, which means that they are just different representations for the same semantic content in different steps of SEP. Thus, here only gives two kinds of data elements, namely System Function (HOW) and System (WHO), while the others correspond to those of Step 2, respectively. System Functions (HOW) include Surveillance and Reconnaissance Function, Intelligence Gathering Function, Target Lo-cating Function, Information Transmission Function, Command and Decision-making Function, Control Function, Engagement Function. Systems (WHO) include ISR Sub-system, Command Sub-system, Control Sub-system, and Interceptor. With the above data elements, all kinds of visualized models can be constructed by organizing them. This means that these elements act as the common foundation of all models in different steps of SEP, and thereby the consistency of models is ensured. In addition, there exist lots of relationships among these data elements, such as the interfaces among the sub-systems, the resource flows, etc. If performance parameters and measures are incorporated into a model constructed from these data entities and their relationships, trade-off analysis can be carried out to select the best system architectural solution. Moreover, with the mapping associations among Capability, Operational Activity, System Function, and System, the requirement traceability matrix can be achieved to facilitate the requirements verification, as shown in Figure 8. For example, with respect to the information transmission capability of the air defense system, this capability requirement can be satisfied if only all sub-systems own the information transmission function simultaneously.

Figure 8

Requirement traceability matrix