MBSE to Graph Database Translator

Abstract

The non-transitory machine-readable medium having machine-executable instructions includes a translator, the machine-readable instructions for the translator being executable by a processor core to perform operations. The operations include translating a plurality of records of model-based systems engineering (MBSE) data for an MBSE platform to identify a plurality of nodes and a plurality of links for graph data in a graph database. The operations also include constructing the graph data using the plurality of nodes and a plurality of links from the translated plurality of nodes. A query on the graph data in the graph database discloses a subset of the plurality of nodes and links between the nodes of the subset and other nodes of the plurality of nodes in the graph data.

Description

[Technical Field]

[0001] The present disclosure relates to transforming model-based systems engineering (MBSE) data for an MBSE platform into graph data for a graph database. [Background technology]

[0002] Model-Based Systems Engineering (MBSE) is the formal application of modeling to support system requirements, design, analysis, verification, and validation activities, beginning with the conceptual design phase and continuing through development and later lifecycle stages. MBSE is an engineering approach to systems engineering that focuses on creating and using domain models (also known as chocolate factory diagrams) as the primary means of information exchange, rather than document-based information exchange. MBSE engineering approaches are commonly applied to a wide range of industries with complex systems, including aerospace, defense, rail, automotive, and manufacturing.

[0003] A graph database (GDB) is a database that represents and stores data using a graph structure with nodes, edges (also called links), and properties to perform semantic queries. The key concept of the system is the graph (or edge, or relationship). A graph associates data items in the store with a set of nodes and edges, where edges represent relationships between the nodes. These relationships allow data in the store to be directly connected to each other and, in many cases, to be retrieved in a single operation. Graph databases prioritize preserving relationships between data. Because the relationships are stored in the database, querying relationships is fast. Relationships can be intuitively visualized using a graph database, making it useful for highly interconnected data. Summary of the Invention

[0004] One example relates to a non-transitory machine-readable medium having machine-executable instructions comprising a translator, the machine-readable instructions for the translator executable by a processor core to perform operations including translating a plurality of records of model-based systems engineering (MBSE) data for an MBSE platform to identify a plurality of nodes and a plurality of links for graph data in a graph database, the operations also including constructing graph data using the plurality of nodes and links from the translated plurality of nodes, wherein querying the graph data in the graph database discloses a subset of the plurality of nodes and links between nodes of the subset of nodes and other nodes of the plurality of nodes in the graph data.

[0005] Another example relates to a system for transforming data. The system includes a non-transitory memory that stores machine-readable instructions and a processor that accesses the non-transitory memory and executes the machine-readable instructions. The machine-readable instructions are executable by the processor to perform operations. The operations include transforming a plurality of records in MBSE data for an MBSE platform to identify a plurality of nodes and a plurality of links for graph data in a graph database. The transforming includes assigning a record title extracted from a given record of the plurality of records to a title of a given node of the plurality of nodes. The transforming also includes determining an element field of the given node based on an element field of the given record. The operations also include constructing graph data using the plurality of nodes and a plurality of links from the plurality of records of the MBSE data. The constructing includes identifying a field in the given record that references other records of the MBSE data. The constructing also includes forming a set of links between the given node and other nodes in the graph data based on the identified field of the given record of the MBSE data. A query to the graph database will reveal a subset of the nodes and links between the nodes of the subset of nodes and other nodes of the plurality of nodes of the graph data.

[0006] Yet another example relates to a method for transforming data. The method includes a translator executing on one or more computing devices translating a plurality of records in MBSE data of an MBSE platform to identify a plurality of nodes and a plurality of links for graph data in a graph database. The method also includes the translator constructing the graph data using the plurality of nodes and the plurality of links from the plurality of records in the MBSE data. A query to the graph database discloses a subset of the plurality of nodes and links between the nodes of the subset and other nodes of the plurality of nodes in the graph database. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 illustrates an example system for transforming database data and running queries on the transformed data to expose metrics. [Figure 2] 10 is a flowchart showing the operation of a translator. [Figure 3] FIG. 1 illustrates a first part of the translation operation of the translator. [Figure 4] FIG. 10 illustrates the operation of a translator to form links between multiple nodes in graph data. [Figure 5] FIG. 10 illustrates the additional operation of the translator to form an abstract link. [Figure 6] FIG. 1 illustrates operational modules (e.g., software modules) of an analytics engine for querying graph data. [Figure 7] 10 is a diagram illustrating a response to a query request from a client to identify whether a particular action includes (or does not include) an activity in graph data. [Figure 8] 1 is a diagram illustrating functional requirements analysis (FRA) performed by a behavioral metrics model on multiple nodes of graph data. [Figure 9] 1 is a diagram illustrating the joint analysis performed by the behavioral metrics module on graph data. [Figure 10] 1 is a diagram illustrating the operation of the structural metrics module on graph data. [Figure 11] 1 shows a diagram illustrating the operation of the request metrics module on graph data. [Figure 12] 1 is a diagram illustrating the operation of the Interface Metrics module on graph data. [Figure 13] 1 is a diagram illustrating the operation of the Parametric Metrics Module on graph data. [Figure 14] 1 is a flowchart illustrating an exemplary method for transforming and analyzing MBSE data. DETAILED DESCRIPTION OF THE INVENTION

[0008] This specification relates to a system for converting model-based systems engineering (MSBE) data into graph data for a graph database. The system includes a translator running on a computing platform (e.g., a server or other computing device), which converts a plurality of records (e.g., a plurality of nodes) in an MBSE platform (e.g., a software platform) to identify a plurality of nodes and a plurality of links in the graph data of the graph database. The conversion also includes assigning a record title (e.g., a node identifier) ​​extracted from a given record of the MBSE data to a title of a given node in the graph data. The conversion also includes determining a category of a given node based on an element field of the given record. The conversion also includes populating the graph data with nodes and links from records in the MBSE data. The populating includes identifying fields in the given record that identify other records of the MBSE platform and forming a set of links for the graph data between a given node and other nodes in the graph database based on the identified fields of the given record.

[0009] The graph database can be queried to reveal nodes of a subset of the graph data and links between nodes of the graph data stored in the graph database. Complex queries can reveal numerous metrics related to the graph data (and MBSE data). These metrics can include behavioral metrics, structural metrics, requirement metrics, interface metrics, and parametric metrics to characterize the relationships (or lack thereof) between nodes in the graph data. Thus, the graph data can be used to visualize otherwise obscure relationships between records in the MBSE data.

[0010] FIG. 1 illustrates an example of a system 100 for converting MBSE data into graph data for a graph database and executing queries on the converted data to discover metrics. The system 100 may include a server 104 (e.g., a computing platform) that may include a memory 108 for storing machine-readable instructions and data and a processor 112 for accessing the memory 108 and executing the machine-readable instructions. The memory 108 represents a non-transitory machine-readable medium such as a random access memory (RAM), a solid-state drive, a hard disk drive, or a combination thereof. The processor 112 (also referred to as a processing unit) may be implemented as one or more processor cores. The server 104 may include a network interface 116 (e.g., a network interface card) configured to communicate with other computing platforms over a network 120, such as a public network (e.g., the Internet), a private network (e.g., a local area network (LAN)), or a combination thereof (e.g., a virtual private network).

[0011] The server 104 may be implemented within a computing cloud. In such a situation, the configuration of the server 104, such as the processor 112, the network interface 116, and the memory 108, may represent a single instance of hardware or multiple instances of hardware, and applications run across (i.e., distributed) multiple instances of hardware (e.g., computers, routers, memory, processors, or combinations thereof). Alternatively, the server 104 may be implemented on a single dedicated server or workstation.

[0012] Other computing platforms (e.g., computing devices) of system 100 also communicate over network 120. These other computing devices include data storage 124 and data consumer computing platform 128. For simplicity of explanation, details of data storage 124 and data consumer computing platform 128 are omitted. However, it will be understood that data storage 124 and data consumer computing platform 128 may be implemented in a manner similar to server 104. Indeed, in some examples, server 104, data storage 124, and data consumer computing platform 128 operate on the same computing device. Unless otherwise indicated, modules of data storage 124 and data consumer computing platform 128 are presumed to be stored in non-transitory memory accessed by a processing unit (e.g., one or more processing cores).

[0013] Data storage 124 includes K MBSE platforms 132 (e.g., MBSE tools such as analysis tools), where K is an integer greater than or equal to 1. Each of MBSE platforms 132 includes stored MBSE data 136. Each instance of MBSE data 136 in K MBSE platforms 132 includes a set of records (e.g., MBSE models), also called nodes. Each node in the set of nodes includes a key and a value field. In some examples, multiple nodes of a given MBSE platform 132 can reference multiple nodes of another MBSE platform 132. For example, MBSE data 136 of a first MBSE platform 132 (MBSE platform 1) may include a node that references a node present in MBSE data 136 of a Kth MBSE platform 132 (e.g., MBSE platform K). In other examples, multiple nodes of a given MBSE platform 132 reference multiple nodes within the same MBSE platform 132.

[0014] The memory 108 of the server 104 includes a translator 140 that converts the MBSE data 136 into graph data 144. More specifically, the translator 140 obtains the MBSE data 136 from each of the K MBSE platforms 132 (or some subset thereof) and generates the graph data 144. In some examples, the translator 140 obtains the MBSE data 136 using an application programming interface (API). The graph data 144 employs a graph structure that supports semantic queries using nodes, links (edges), and properties to represent and store data. The graph data 144 is stored in a graph database 148, which is stored in the data storage 124. In some examples, the translator 140 uses the API to store the graph data 144 in the graph database 148.

[0015] Figure 2 shows a flowchart illustrating the operation of a translator 200, such as translator 140 of Figure 1. The translator 200 executes on a computing platform, such as server 104 of Figure 1. The translator 200 receives MBSE data 204, such as MBSE data 136 of Figure 1, and outputs graph data 208, such as graph data 144 of Figure 1.

[0016] At 212, the translator 200 retrieves the payload of a set of nodes in the MBSE data 204. In some examples, the nodes in the set of nodes are implemented in JavaScript Object Notation (JSON) format. At 216, the translator 200 extracts payloads (e.g., data fields such as key-value pairs) from the nodes in the MBSE data 204. At 220, the translator 200 creates nodes and assigns categories to the graph data 208 based on element fields (e.g., element types) of each corresponding node extracted from the MBSE data 204. At 224, the translator 200 creates (low-level) links between the nodes in the graph data 208. Additionally, at 224, the translator 200 creates abstract links (e.g., bypass links) between the nodes of the graph data 208 to speed up queries. The linked nodes are output as the graph data 208.

[0017] 3-5 illustrate the operation of the translator 200 of FIG. 2 and the translator 140 of FIG. 1. In particular, FIG. 3 is a diagram 300 illustrating a first portion of the operation of the translator 200 of FIG. 2 and the translator 140 of FIG. 1. In FIG. 1, three nodes, namely, node 1 (302), node 2 (304), and node 3 (308), are extracted from the MBSE data (e.g., MBSE data 204 of FIG. 2). Node 1 (302), node 2 (304), and node 3 (308) contain data fields implemented as key-value pairs. In particular, node 1 (302), node 2 (304), and node 3 (308) contain a node identifier (e.g., record identifier) ​​key labeled "aa_id" and an associated value. Additionally, node 1 (300), node 2 (304), and node 3 (308) comprise element types that can be used to generate corresponding nodes in the graph data (e.g., graph data 208 of FIG. 2), as in operation 220 described in FIG. 2. In the illustrated example, node 1 (302) (e.g., an MBSE record) is transformed into node 1 (312) (a graph node), node 2 (304) is transformed into node 2 (316) (a graph node), and node 3 (308) is transformed into node 3 (320) (a graph node).

[0018] Additionally, as described in operation 224 of Figure 2, links are created for the nodes, namely, node 1 (312), node 2 (316), and node 3 (320) (graph nodes). To create the links, the translator examines the key-value pairs of each node and identifies pairs that reference another node. For example, as indicated by box 324, node 1 (302) (corresponding to node 1 (312)) includes a key-value pair with a value corresponding to the identifier of node 2 (304) (corresponding to node 2 (316)), thereby creating a link between node 1 (312) and node 2 (316). Similarly, as indicated by box 328, node 2 (304) includes a key-value pair with a value corresponding to the identifier of node 3 (308) (corresponding to node 3 (320)), thereby creating a link between node 2 (316) and node 3 (320).

[0019] Additionally, a key-value pair that does not identify multiple other nodes may identify a set of activities (e.g., a record) for a given node, such as the activities of node 1 (302), node 2 (304), and / or node 3 (308).

[0020] Figure 4 shows a diagram 400 of the operation of a translator to form multiple links between multiple nodes, such as operation 224 of Figure 2. Diagram 400 includes node 1 (312), node 2 (316), and node 312, which were created in diagram 300 of Figure 3. As shown, a first link 404 is provided between node 1 (312) and node 2 (316), and a second link 408 is provided between node 2 (316) and node 3 (320). In some examples, the links may include values ​​associated with key-value pairs extracted from the MBSE data.

[0021] 5 is a diagram 500 illustrating an additional operation of the translator to form abstract links, such as operation 224 of FIG. 2. Diagram 500 includes node 1 (312), node 2 (316), and node 312, which were created in diagram 400 of FIG. 3. As shown, a first link 404 exists between node 1 (312) and node 3 (320), and a second link 408 exists between node 1 (312) and node 3 (320). In response, the translator forms abstract link 504, which indicates a direct connection between node 1 (312) and node 3 (320), or a bypass link. In this way, a query disclosing node 1 (312) will show a link to node 3 labeled with a type of "TWO_LINKS_AWAY" (or similar).

[0022] 1 , the graph database 148 storing the graph data 144 may be queried by an external system, such as an analytics engine 150 stored in the memory 108 of the server 104. The analytics engine 150 is accessible by a client 154 (e.g., a web browser or a dedicated client) running on the data consumer computing platform 128. The results of the query execution provide a plurality of nodes and characterize a plurality of interconnections between the plurality of nodes. The results may be displayed graphically on the output of the client 154, for example, in a graphical user interface (GUI).

[0023] The analytics engine 150 may be used to run queries on the graph database 148 based on input from the clients 154. Additionally, the analytics engine 150 may organize the data into a format consumable by users of the data consumer computing platform 128. The analytics engine 150 may be used to determine metrics of the graph data 144, such as behavioral metrics, structural metrics, requirement metrics, interface metrics, and / or parametric metrics. These metrics are formatted into output in a format consumable by the clients 154.

[0024] To aid in understanding the benefits of implementing system 100, consider an extended given example ("Given Example") in which system 100 is used to develop an aircraft, such as a fighter jet. Aircraft are inherently complex machines that often require many different levels of design, including, but not limited to, aircraft control actions (e.g., maneuvers), constraints (e.g., accelerations), computer-aided drafting (CAD) drawings, build-of-materials (BOM) lists, software modules, vendor coordination, etc. Furthermore, these lists are not meant to be exhaustive.

[0025] Continuing with the given example, multiple nodes in the K MBSE platforms 132 may include specifications for an aircraft. In a simple example, assume that a first node in a given set of nodes of an instance of MBSE data 136 (e.g., stored in a first MBSE platform 132) represents specifications including the weight of the aircraft's wings. In such a situation, the first node may include a reference to a CAD drawing (e.g., in certain key and value data fields) of a second node in graph data 144. In addition, the first node may include a reference to a BOM of a third node in graph data 144. Thus, a change in the wing weight requires a change in the CAD drawing (e.g., a change in geometry) and a change in the BOM (e.g., a change in material quantities). Using conventional approaches would require cumbersome text-based searches of key and value fields in the MBSE data 136 of the K MBSE platforms 132. In contrast, by converting the first node in a given example to a first node (e.g., graph node) in graph data 144, a graph representing the connectivity relationships, along with labels, is provided as graphical output to client 154. In this way, in the given example, a user of client 154 can quickly see the impact of changing a particular feature of the wing (e.g., weight), i.e., that the change in weight affects a second node (including a reference to a CAD drawing) and a third node (including a reference to a BOM).

[0026] Figure 6 illustrates the operational modules (e.g., software modules) of an analytics engine 600, such as analytics engine 150 of Figure 1. Analytics engine 600 executes on a computing platform, such as server 104 of Figure 1. Analytics engine 600 receives graph data 604, such as graph data 144 from graph database 148 of Figure 1, and outputs front-end data 608, which may be output on a client, such as client 154 of Figure 1.

[0027] The analytics engine 600 includes a client interface 612 that provides the front-end data 608. The client interface 612 communicates with selected metrics modules of the analytics engine 600 in response to requests from clients. In particular, the client interface 612 provides an interface to clients, allowing them to run queries and selectable metrics on the graph data 604. The metrics modules include a behavioral metrics module 616. The behavioral metrics include functional requirements analysis and the coupling and cohesion of multiple nodes in the graph data 604.

[0028] Figures 7-9 illustrate various operations of the operational metrics module 616 performed on multiple nodes (e.g., elements) of the graph data 604 of Figure 6. For simplicity, Figures 6-9 use the same reference numbers to indicate the same structures, and some structures have not been reintroduced.

[0029] 7 is a diagram 700 that illustrates a response to a query request from a client (e.g., client 154) to identify whether a particular action includes (or does not include) an activity. In response to this request, the behavior metrics module 616 queries the graph data for the node of the particular action to determine whether the particular node has a null value (or other empty value) in the action key field. In other words, the behavior metrics module 616 determines whether the particular node in the graph data 604 has an action key field with a null or empty value.

[0030] In the given example, assume that the first node 704 represents a node of an action that performs a maneuver. In this example, assume that the second node 708 represents an instance of performance of a sub-maneuver, represented by the label "HAS_CHILD." Further, the behavior metrics module 616 determines whether a link labeled "TYPED_BY" exists between the second node 708 and the third node 712. Data characterizing the diagram 700 may be provided as front-end data 608.

[0031] As illustrated by diagram 700, a gap analysis can be performed on graph data 604 to compare definitions (activities) with uses (actions). If an action is created without an activity (e.g., the action key field has a null value), this indicates that an action definition has not been created for a node in the MBSE data (e.g., MBSE data 136) and therefore will not be considered in the upstream and / or downstream analysis of the particular node. This upstream and / or downstream analysis may include requirements traceability, assignment of actions to elements of a structure, etc. Additionally, the gap analysis may disclose that duplicate actions have been created in the MBSE data, which may result in inconsistencies between definitions.

[0032] 8 is a diagram 800 illustrating a functional requirements analysis (FRA) performed by the behavioral metrics module 616 on multiple nodes of graph data. In the illustrated example, assume that a client (e.g., client 154 of FIG. 1) has requested a full square (or other logical loop) query. In response to the full square query, the behavioral metrics module 616 returns each FRA square, which contains two requests and two operations.

[0033] 8, a full square metric having a first node 804, a second node 808, a third node 812, and a fourth node 816 is returned in a full square query. More generally, the first node 804, the second node 808, the third node 812, and the fourth node 816 provide a subset of nodes in the graph data with links that form a logical loop. In the given example, assume that the first node 804 is a parent operation with a key and value field of "Thrust=Mach 100." The first node 804 includes a link 820 labeled "refines" to the second node 808 that includes a parent request that "the system should contribute Mach X." The first node 804 also includes a link 822 labeled "DECOMPOSITION" to a third node 812, which includes a child operation of "Thrust = Mach 50." The third node 812 includes a link 828 labeled "REFINES" to a fourth node 816, which includes a child requirement of "Subsystem should contribute Mach Y." The fourth node 816 further includes a link 832 labeled "DERIVE REQUIREMENT" to the second node 808, completing the square.

[0034] The use of FRA squares allows for the rapid identification of patterns of nodes (elements) and relationships between nodes that are not readily discernible within the MBSE data (e.g., MBSE data 136 in FIG. 1) stored in an MBSE platform (e.g., MBSE platform 132 in FIG. 1). Thus, full square metrics such as those illustrated by diagram 800 can be used to verify that parent-to-child requirements are consistent with decompositions of parent-to-child operations, if any.

[0035] Further, in some examples, a complete square query may include a query for an FRA square that is missing one link. In this situation, assume that link 822 (labeled “Decomposition”) between first node 804 and third node 812 does not exist in graph data 604. In this situation, the behavioral metrics module 616 can return each square that could be completed if one link were added. This includes returning the node shown in diagram 800 in the situation where link 822 does not exist. More generally, the behavioral metrics module 616 can identify a subset of nodes in the graph data that have links that are exactly one link away from forming a logical loop (e.g., an FRA square). This is provided as a one-link warning metric in front-end data 608.

[0036] A query on FRA squares with one link missing can be used to check for consistent and available paths (e.g., FRA squares) and paths that flag as not existing (e.g., FRA squares with one link missing). The one-link warning metric flags paths that are one link away from being a complete square, thereby flagging concerns in the architecture model of the MBSE data. This avoids future errors and reduces development costs by identifying design flaws early in the design process and ensuring project requirements are accurately decomposed.

[0037] Further, in some examples, a complete square query may include a query for a single node. In this situation, assume that link 822 between first node 804 and second node 808 does not exist and link 828 between fourth node 816 and second node 808 is missing. In this situation, the behavioral metrics module 616 may identify second node 808 as a single node that is not linked to request and operation nodes in the FRA square. More generally, the behavioral metrics module 616 may identify a subset of nodes in graph data 604 for a particular category that are not linked to another node in the particular category.

[0038] Graph databases allow users to easily identify links to other nodes. This capability is useful in situations where certain types of nodes are expected to be linked to other nodes. For example, in an architecture model, it is common for requirement and operation nodes to link to other requirement or operation nodes. Flagging a single node (e.g., a single node metric), such as second node 808 (in the absence of links 820 and 832), can detect actionable issues. Similar to the one-link warning metric, flagging a single node identifies design flaws early in the design process and ensures that project requirements are accurately decomposed, thereby avoiding future errors and reducing development costs.

[0039] FIG. 9 shows a diagram 900 illustrating a coupling analysis performed by the behavior metrics module 616 in response to a request for coupling scores between behaviors (e.g., actions) of a given behavior in the graph data 604. The coupling score is alternatively referred to as the strength of the action. To calculate the coupling score, the behavior metrics module 616 counts the number of send signal actions and accept event actions between multiple nodes for a first behavior and a second behavior. This number is divided by the maximum number of send signal actions and accept event actions for nodes at the same level as the given node. In the diagram 900, assume that the first behavior is “Operation A” and the second behavior is “Operation B.” In this example, the nodes for Operation A are represented by boxes with rounded corners and share a common color. Similarly, the nodes for the second behavior also share a common color (represented as a pattern). In the diagram 900, the behavior metrics module 616 counts the number of links representing send signal actions and accept event actions between the rounded-corner nodes and other nodes. In this example, there is a first link 904 connecting the first node 908 of operation A and the first node 912 of operation B. Furthermore, in the diagram 900, there is a second link 916 between the second node 920 of operation A and the output 924. Furthermore, there is a third link 928 between the second node 932 of operation B and the third node 936 of operation A. Furthermore, there is a fourth link 940 between the input node 944 and the first node 908 of operation A. Therefore, in the diagram 900, operation A has four links (representing a send signal action and an accept event action) between the node of operation A and other nodes. Furthermore, there are two links (representing a send signal action and an accept event action) between operation A and operation B, namely, the first link 904 and the third link 928. Therefore, the connection score between operation A and operation B is equal to "0.5". In some examples, the behavioral metrics module 616 provides data to the client interface 612 representing a layout of the diagram 900 highlighting the features of the combined scores, and the layout is output on the client.

[0040] By identifying patterns of particular node types (e.g., element types), such as operations and / or activities (e.g., the send signal and accept event actions in diagram 900), it is easy to see how well an operation is coupled to other operations. Coupling scores calculated from such patterns indicate the likelihood that changing a particular operation will affect other operations. In this way, users can determine whether these changes to operations can be refined to meet the project requirements. With traditional approaches, for example, in a given example where there are thousands of nodes in the MBSE data, coupling between nodes is difficult to see.

[0041] Further continuing with diagram 900, assume that a client queries for the cohesion score of a first behavior (operation A) between activity A1.1, represented in diagram 900 as a first node 908 of operation A, and operation A2.1, represented in diagram 900 as a second node 920 of operation A. In this example, the behavior metrics module 616 counts the number of resulting input and output object flows and control flows that exist between the call operation actions within the first behavior and divides by the maximum number of object flows and control flows across all activities present at a given level to determine the cohesion score for the operation that has the particular activity as an associated method.

[0042] In diagram 900, there are two links 950 between the first node 908 and the second node 920 of operation A, and a total of four links 954 between the first node 908, the second node 920, and the third node 936 of operation A. Therefore, behavior metrics module 616 reports a cohesion score of "0.5" for operation A1.1 and operation A2.1. In some examples, behavior metrics module 616 provides data to client interface 612 representing a layout of diagram 900 highlighting features of the cohesion score, and the layout is output on the client.

[0043] As indicated by the cohesion score, the internal components of an operation can be analyzed by identifying the input and output object flows and control flows. In some instances, an operation is expected to fulfill or refine project requirements. Therefore, when changes are made to project requirements, the cohesion score can be used to determine whether the change will cause internal changes to related operations. Such unintended effects are not apparent using traditional views of MBSE data.

[0044] 6, the metrics modules include a structural metrics module 620. The structural metrics module 620 can be used to identify nodes in the graph data 604 that have incomplete structural branches.

[0045] FIG. 10 shows a diagram 1000 illustrating the operation of the structural metrics module 620 on the graph data 604 of FIG. 6. For simplicity, FIGS. 6 and 10 use the same reference numerals to indicate the same structure. The diagram 1000 is generated in response to a request from a client for nodes that are actually "leaf nodes" but have an erroneously false value for the leaf node's corresponding key. In other words, the diagram 1000 is generated to identify nodes that have a value set to "false" but should have a value of "true" using a key-value pair for the key "IsLeaf" (or equivalent). In some examples, the structural metrics module 620 provides data to the client interface 612 representing a layout of the diagram 1000 that highlights features of incomplete structural branches and incorrectly labeled leaf node(s).

[0046] In diagram 1000, a first node 1004 has a link 1006 labeled "HAS_CHILD" to a second node 1008. Additionally, as shown, the first node 1004 has a key-value pair of "IsLeaf=false." However, because the first node 1004 has a child node (the second node 1008), the value of "IsLeaf" for the first node 1004 is false.

[0047] Using a graph database, it is relatively easy to perform gap analysis comparing definitions (e.g., block nodes) with usage elements (e.g., child block nodes). If a particular block node is labeled as not having a leaf or has a child block, this indicates that the Boolean value (IsLeaf) is incorrect and therefore will not be considered in any upstream and / or downstream analysis (e.g., block definition diagrams). Furthermore, in some instances, incomplete structural branching (if not detected) may cause premature termination of the analysis of a block diagram where an incorrectly labeled false leaf is encountered.

[0048] 6, the metrics modules include a request metrics module 624. The request metrics module 624 is operable to count request relationships for nodes (e.g., elements) of the graph data 604.

[0049] FIG. 11 shows a diagram 1100 illustrating the operation of the request metrics module 624 on the graph data 604 of FIG. 6. For simplicity, FIGS. 6 and 11 use the same reference numerals to indicate the same structures. Diagram 1100 is generated in response to a request from a client to identify and count the number of elements that satisfy a particular requirement stereotype. In diagram 1100, node 1104 (labeled “element”) is assumed to satisfy this requirement. In the given example, assume the requirement is “The system shall have Mach X.” In this situation, upon detecting the presence of node 1104, a counter is incremented. In some examples, the request metrics module 624 provides data to the client interface 612 representing the layout of diagram 1100 highlighting a feature indicating how much the counter will be incremented.

[0050] By using a graph database, again, a gap analysis can be performed between definition (ownership element) nodes and use (element) nodes. This allows for the identification of additional relationships between specific elements of use and other elements. Furthermore, this allows for the identification of elements that (in a given example) are not accurately stereotyped by the standard requirement nodes, so that these can be addressed to prevent costly rework of MBSE data in the future.

[0051] 6, the metrics modules include an interface metrics module 628. The interface metrics module 628 can be used to identify ports that are not formatted by an interface block (e.g., a node type).

[0052] FIG. 12 shows a diagram 1200 illustrating the operation of the interface metrics module 628 on the graph data 604 of FIG. 6. For simplicity, FIGS. 6 and 12 use the same reference numerals to indicate the same structures. In the diagram 1200, a first node 1204 (e.g., a port element) is linked to a second node 1208 by a link 1212 labeled "TYPED_BY." The interface metrics module 628 identifies the link 1212 if a relationship exists for the associated port. For example, in the given example, assume that the first node 1204 represents an Ethernet port. Furthermore, the second node 1208 represents a particular Ethernet communication protocol in the given example. The link 1212 indicates that the second node 1208 is typed by the first node 1204. In some examples, the interface metrics module 628 provides data to the client interface 612 that represents a layout of the diagram 1200 that highlights features that indicate how the interface metrics are calculated.

[0053] Again, the graph data allows for gap analysis between nodes (elements) in the graph database. In particular, the interface metrics module 628 allows for gap analysis between definitions (owning ports) and using elements (ports). This gap analysis allows users to identify ports that are not properly formatted by interface block elements before proceeding with development, potentially reducing rework in future project development.

[0054] 6, the metrics modules include a parametric metrics module 632. The parametric metrics module 632 can be used to identify constraint parameters without binding.

[0055] FIG. 13 shows a diagram 1300 illustrating the operation of the parametric metrics module 632 on the graph data 604 of FIG. 6. For simplicity, FIGS. 6 and 13 use the same reference numerals to indicate the same structures. In the diagram 1300, a first node 1304 (e.g., an ownership constraint block) is linked to a second node 1308 by a link 1312 labeled “HAS_CHILD.” The second node 1308 should originally be linked to a third node 1316 via a missing link 1320 labeled “BOUND_VALUE_PROPERTY,” shown in dashed lines. The parametric metrics module 632 identifies the second node 1308 as a constraint parameter without a bounded value property. For example, in the given example, the first node 1304 can represent Newton's second law of motion, F=m*a. In this situation, the second node 1308 can represent acceleration. Additionally, the third node 1316 can represent the acceleration of gravity on Earth (9.8 meters per second (m / s 2 )) boundary value properties. However, the second node 1308, which represents acceleration, does not have a boundary value property because the link 1320 is missing. In some examples, the parametric metrics module 632 provides data to the client interface 612 representing a layout of the diagram 1300 that highlights features indicative of the missing link 1320.

[0056] Again, the graph data enables gap analysis between nodes (elements) of the graph database using parametric diagrams, including diagram 1300. The parametric diagram provides constraint blocks (nodes) that possess constraint parameters (nodes). These parameters have input and output arguments that define how values ​​are converted based on an equation (e.g., F=m*a). Value properties (e.g., third node 1316) provide the numerical values ​​associated with the parameters to be converted into these input / output values. Without the boundary value property, the constraint cannot perform the assigned calculation. Thus, the parametric metrics module 632 discloses missing connections in the parametric diagram of the graph data 604.

[0057] 6, Figures 7-13 illustrate how the visual representation of the nodes of graph data 604 is useful in enabling analysis through queries on graph data 604, including gap analysis on the MBSE data from which graph data 604 is generated. Furthermore, the execution of the operational metrics module 616, structural metrics module 620, requirement metrics module 624, interface metrics module 628, and parametric metrics module 632 is not meant to be exclusive. It is common for a client to request queries against graph data 604 during gap analysis (or other analytical analysis) that analyze the same data in multiple ways.

[0058] 1 , as shown in FIG. 6 , an analytics engine 150 can be used to query the graph data 144 in the graph database 148 to uncover connections and / or errors that may exist in the MBSE data 136 of the K MBSE platforms 132, or some subset thereof. As described with respect to FIGS. 7-13 , conventional text-only analysis of such MBSE data 136 is error-prone and time-consuming. Therefore, by converting instances of MBSE data 136 into graph data 144 in the described manner, the underlying structure of the data and the interrelationships (or lack thereof) between nodes can be analyzed to aid project management of large-scale projects, such as aircraft development in the given example.

[0059] With the structural and functional features described above in mind, an exemplary method may be better understood with reference to FIG. 14 . For ease of explanation, the exemplary method of FIG. 14 is shown and described as being performed serially; however, it should be understood and appreciated that the present example is not limited by the order shown in the specification, as some operations may, in other examples, occur in a different order than shown and described herein and / or simultaneously. Furthermore, not all operations described need to be performed to implement the method. The exemplary method of FIG. 14 may be implemented as instructions stored on a non-transitory machine-readable medium. The instructions may be accessed by a processing unit and executed to perform the methods disclosed herein.

[0060] Figure 14 shows a flowchart of an example method 1400 for transforming and analyzing MBSE data, such as instances of MBSE data 136 of Figure 1. Method 1400 may be performed, for example, by server 104 of Figure 1.

[0061] At 1410, a translator (e.g., translator 140 of FIG. 1) translates records (e.g., nodes) in the MBSE data extracted from the MBSE platform to identify nodes and links in graph data (e.g., graph data 144 of FIG. 1) for a graph database (e.g., graph database 148 of FIG. 1).

[0062] The conversion at 1410 may include, for example, assigning a record title (e.g., a node identifier) ​​extracted from a given record in the MBSE data to a title of a given node in the graph data. The conversion may also include determining a category for a given node based on an element field (e.g., an element type) of the given record.

[0063] At 1420, the translator can populate the graph data with nodes and links from the records. This populating can include, for example, identifying fields in a given record that identify other records of the MBSE data. For example, fields in a given record that identify other records of the MBSE platform can be assigned to actions (e.g., categories). Populating can also include forming a set of links between a given node and other nodes in the graph database based on the identified fields of the given record.

[0064] At 1430, an analytics engine (e.g., analytics engine 150 of FIG. 1) performs metrics queries against the graph data in the graph database. For example, the graph data can be queried to discover a subset of nodes and links between nodes in the graph data. These queries can be used to discover metrics related to the MBSE data (e.g., the metrics shown and described in FIGS. 6-13).

[0065] The above description is illustrative. Of course, it is not possible to describe every conceivable combination of components or methodologies, but one of ordinary skill in the art will recognize that many additional combinations and permutations are possible. Accordingly, this disclosure is intended to embrace all such alterations, modifications, and variations that are within the scope of this application, including the appended claims. As used herein, the term "includes" means including, but not limited to, and the term "including" means including, but not limited to. The term "based on" means based at least in part on. In addition, when this disclosure or claims recite "a," "an," "a first," or "another" component, or equivalents thereof, it should be construed as including one or more such components, and does not require or exclude two or more such components.

Claims

1. 1. A non-transitory machine-readable medium having machine-executable instructions comprising a translator, the machine-readable instructions for the translator being executable by a processor core to perform operations, the operations comprising: Transforming a plurality of records in a model-based systems engineering (hereinafter referred to as MBSE) data for an MBSE platform to identify a plurality of nodes and a plurality of links for graph data of a graph database; constructing the graph data using the plurality of nodes and links from the transformed plurality of nodes, wherein querying the graph data in the graph database discloses a subset of the plurality of nodes and links between nodes in the subset of nodes and other nodes in the plurality of nodes in the graph data.

2. To convert, assigning a record identifier extracted from a given record of said plurality of records to a title of a given node of said plurality of nodes; determining a category for the given node based on element fields of the given record; Identifying a field in the given record that identifies another record of the MBSE data; and forming a set of links between the given node and other nodes in the graph data based on the identified fields of the given record.

3. 3. The non-transitory machine-readable medium of claim 2, wherein the operations involving the translator further include forming bypass links between nodes of the plurality of nodes, the bypass links connecting a first node of the plurality of nodes to a second node of the plurality of nodes, and the first node and the second node connected to a third node of the plurality of nodes.

4. The non-transitory machine-readable medium of claim 3 , wherein the converting further comprises assigning a field in the given record that identifies the other record of the MBSE data to an action.

5. 5. The non-transitory machine-readable medium of claim 4, wherein the operations relating to the translator further include determining a set of activities for the given record based on identifying a field in the given record that does not identify another node in the MBSE data.

6. 5. The non-transitory machine-readable medium of claim 4, wherein the machine-readable instructions further comprise a metrics engine executable by a processor to perform operations to analyze the graph data.

7. 7. The non-transitory machine-readable medium of claim 6, wherein the metrics engine determines the intensity of the action of the given record based on a number of links to other nodes in the plurality of nodes of the graph data.

8. 8. The non-transitory machine-readable medium of claim 7, wherein the subset of nodes is a first subset of nodes, and the analysis involving the metrics engine includes identifying a second subset of nodes in the graph data having multiple links that form a logical loop.

9. 10. The non-transitory machine-readable medium of claim 8, wherein the analysis by the metrics engine includes identifying a third subset of the plurality of nodes in the graph data that have links that are exactly one link away from forming a logical loop.

10. 10. The non-transitory machine-readable medium of claim 9, wherein the third subset of nodes identifies nodes of the graph data of a particular category that are not linked to another node of the particular category.

11. 1. A system for transforming data, comprising: a non-transitory memory storing machine-readable instructions; a processor that accesses the non-transitory memory and executes the machine-readable instructions, the machine-readable instructions being executable by the processor to perform operations, the operations comprising: Transforming a plurality of records in MBSE data of a model-based systems engineering (MBSE) platform to identify a plurality of nodes and a plurality of links for graph data of a graph database, wherein the transforming includes: assigning a record title extracted from a given record of said plurality of records to a title of a given node of said plurality of nodes; determining a category for the given node based on element fields of the given record; constructing the graph data using a plurality of nodes and a plurality of links from the plurality of records of the MBSE data, wherein the constructing includes: Identifying fields in the given record that reference other records of the MBSE data; forming a set of links between the given node and other nodes in the graph data based on the identified fields of the given record of the MBSE data; a query to the graph database reveals a subset of the plurality of nodes and links between the subset of nodes and other nodes of the plurality of nodes of the graph data.

12. The system of claim 11 , wherein the converting further comprises assigning a field in the given record that identifies the other record of the MBSE data to an action.

13. The system of claim 12 , wherein the operations further comprise determining a strength of the action of the given record based on a number of links to other nodes in the plurality of nodes of the graph data.

14. 13. The system of claim 12, wherein the operations further comprise determining a set of activities for the given record based on identifying a field in the given record that does not identify another node in the MBSE data.

15. 13. The system of claim 12, wherein the operations further include forming a bypass link between nodes of the plurality of nodes, the bypass link connecting a first node and a second node, and the first node and the second node connected to a third node.

16. 1. A method for transforming data, comprising: a translator executing on one or more computing devices converting a plurality of records in a model-based systems engineering (MBSE) data for an MBSE platform to identify a plurality of nodes and a plurality of links for graph data of a graph database; the translator constructs the graph data using the nodes and links from the records in the MBSE data, and queries to the graph database disclose a subset of the nodes and links between nodes in the subset and other nodes in the plurality of nodes in the graph database.

17. To convert, assigning a record title extracted from a given record of said plurality of records to a title of a given node of said plurality of nodes; determining a category for the given node based on an element field of the given record; The constructing step includes: Identifying a field in the given record that identifies other records of the MBSE platform; and forming a set of links between the given node and other nodes in the graph database based on the identified fields of the given record.

18. The method of claim 17 , wherein the converting further comprises assigning a field in the given record that identifies the other record of the MBSE platform to an action.

19. 20. The method of claim 18, further comprising: a metrics engine executing on the one or more computing devices determining an intensity of the action of the given record based on a number of links to other nodes in the plurality of nodes of the graph database.

20. 20. The method of claim 18, further comprising determining a set of activities for the given record based on identifying a field in the given record that does not identify another node in the MBSE platform.

Images