## 6 Application
### The Lane Keeping System Revisited  
Our lane keeping system (LKS) running example can now be analyzed according to the CMGVC. An in-zoomed diagram of the LKS, specifying functions performed by the system and their interactions, is illustrated in Figure 12. This is an intentionally partial diagram, with some critical gaps. As we study this diagram we should notice, for instance, that the Lane Crossing object has no source, and that the Road is consumed by the Imaging Road process, rather than remain an instrument as it was specified in the topmost diagram. It is difficult to ensure continuity and consistency this way, and the problem intensifies as the model grows bigger with more objects, processes, and diagrams. Analyzing this model with a POP matrix could help detect some discrepancies in the model. Table 8 is a POP matrix that was derived from the model through the same SQL query defined in Section 6.1 for the POP matrix-supporting records, and rendered as a matrix using a MS Excel pivot table on the query results. The LKS model utilizes additional procedural relations besides the _Result_ and _Consumption_: the _Instrument_ relation is used for non-consumable resources, and the _Invocation_ relation is used for specifying process activation by another process, implying an unspecified interface object. Additional metrics were added to the POP matrix, including the number of inputs and number of outputs per process (calculated on the columns and rows, respectively). Figure 12: Lane Keeping System zooms into Alert Mode, Steer-back Mode, Road Image, Alert Mode, Lane Crossing, and Steer-back Mode, in that vertical sequence, as well as Alerting, Analyzing Road, Imaging Road, Selecting Operational Mode, and Steering (This caption is formal OPL). The POP matrix highlights several issues in the model, which could be helpful for reviews by various stakeholders--customers, system architects, process or function owners, etc. We summarize proposed corrections by entity and issue in Table 9. It would be easy to apply these to the model and reiterate to obtain the revised POP matrix. As details are added to the model, the POP matrix is likely to grow and detect new issues, in a continuous concept revision and improvement cycle. \begin{table}
\begin{tabular}{c c c c c c c c c} \hline \hline
**Source Process** & **Target Process** & **Target Process** & **Target Process** & **Target Process** & **Target Process** & **Target Process** & **Target Process** & **Target Process** & **Target Process** \\ \hline
**(Null)** & & Lane Crossing & Road Image & Road Road & Road & Lane Crossing & Road & 6 \\ \hline
**Lane Keeping** & Improved Safety & & & & & & & & \\ \hline
**Selecting Operational Mode** & & & & & & & & \\ \hline
**Imaging Road** & & & & & & & & \\ \hline
**Analyzing Road** & & & & & & & & **0** \\ \hline
**Alerting** & & & & & & & & & 1 \\ \hline
**Driving** & & & & & & & & & \\ \hline
**Steering** & & & & & & & & & 1 \\ \hline
**Propelling** & & & & & & & & & \\ \hline
**Inputs per Process** & 1 & 2 & 1 & 1 & 1 & 0 & 2 & 3 & 4 \\ \hline \hline \end{tabular}
\end{table} 
Table 8: POP matrix of LKS model maps processes to each other via onput exchange, instrument providing, and invocation. Color coding highlights discrepancies and potential issues: Red cells with a value of 0 indicate processes without inputs or outputs. Lightly-colored cells need further attention.