# Gaining Insights into Conceptual Models: A Graph-Theoretic Querying Approach
## 5 Use Cases for OPM Queries
### Cause and Effect in Model-Based System Engineering
#### 5.1.1 Impact Analysis by Forward Chaining: The Case of the Aircraft Collision Avoidance System  
Systems engineers often face the challenge of \"What will be the impact of my change?\" The larger and more complex the system, the more difficult it is to answer this question. A similar challenge exists when a system element fails, with the question being \"What disruption will this failure cause to the operation of the system?\" An OPM model of a system, converted to a graph representation, will often reveal a sub-graph directed \begin{table}
\begin{tabular}{l l} \hline \hline
**OPM Link** & \\ \hline \multirow{2}{*}{**Cypher relationship creation query**} & MATCH (n1:Object [name:’Passenger’, opm_id:’1’]) \\  & MATCH (n2:Process [name:’Passenger Securing’, \\ opm_id:’2’]) \\  & MERGE (n1)-[r:’Agent’ [opm_id: 3’]]->(n2) \\ \hline \hline \end{tabular}
\end{table} 
Table 3: Example of converting an OPM link to a Cypher query. \"downstream\", rooted from the affecting OPM thing, which includes the things connected to it. This information enables the systems engineer to evaluate the impacts and risks of planned and unplanned changes on the system's health and performance. Figure 7 is an OPM model of an **Airplanes Collision Avoiding System** with three levels of detail, created by iteratively zooming into the processes. The model describes the stateful object **Aircraft 1**. The **Airplanes Collision Avoiding** process changes the state of **Aircraft 1** from **close** (i.e., being near an obstacle) to **collision avoided**. The process consists of the subprocesses **Collision Detecting**, **Route Change Calculating**, and **Collision Avoiding**. The in-zoomed process **Collision Detecting** requires the instrument **Vicinity Screening Subsystem** to execute the process with the subprocesses nested within it. Suppose there is a scheduled maintenance task of upgrading the **Vicinity Screening Subsystem**, which is specified in Figure 7 at the second detail level, SD 1.1: **Collision Detecting** In-Zoomed. The team responsible for executing this task does not have the full picture of the possible impact of a failure of this system. Hence, their risk assessment of the system's operation will be very limited, as from the viewpoint of SD1.1, it seems that removing the **Vicinity Screening Subsystem** would impact only **Vicinity Screening** and **Obstacle Detecting**. Executing a \"Directional\" query, which is one of the queries described below, collectively named \"Neighborhood OPM Queries\", and filtering only the \"Outgoing\" relationships from the **Vicinity Screening Subsystem** as the graph root node will provide all the OPM things that are impacted due to element failure or disruption. The Cypher query to retrieve the data is as follows:  
1: MATCH p=(source:SSTART_NODE_TYPE [name:\"SSTART_NODE_TEXT\"])-[\"1.5 MAX_DEPTH]->(child)  
2: RETURN p  
The result of the query presented in Figure 8 provides additional elements to consider beyond the obvious ones, **Vicinity Screening** and **Obstacle Detecting**. The result includes  
Figure 7: An **Airplanes Collision Avoiding System**. Top: The system diagram, SD; bottom left: SD1—first detail level; bottom right: SD1.1—second detail level. elements from all the model levels and the relationships among them, clearly showing that failure or disruption of this subsystem has a major impact, as it might prevent the system from being able to avoid an obstacle. The three objects, **Collision Detected Aircraft 1**, **Route Change Aircraft 1**, and **Collision Avoided Aircraft 1**, result from de-stating (see Section 4.1.1) of the 5-state object (object with five states) **Aircraft 1**. System monitoring and controlling capability is an important factor in ensuring system stability and health, as it provides for continuous validation, verification, and incident mitigation.