Recap from Part 1 of the discussion: I was tasked with building a thread of system features related to the control, guidance, and navigation of a military aircraft. The end product must show the system’s behavior at different hierarchical levels: system capabilities, system features, and subsystem features. The model must also be useable in an Agile DevOps environment.
With an understanding of a system capability, I laid out an overall series of system capabilities based on phases of flight. Since the Program wished to view system capabilities as how the aircraft was “used” at the high level, phases of the flight made sense to me. Keeping this type of behavior in the Operational Activity (OA) layer was also crucial. That way, the same set of functions can implement multiple activities in multiple capabilities.
Now we are ready to look at an example of system capabilities similar to what I developed for the actual aircraft system. It starts with “Check System – Preflight” and ends with “Taxi – Postflight.” Note that these capabilities are generically named for demonstration purposes in this article. They do not reflect the actual system operational concepts or design implementations for security reasons.
Figure 1: System Capabilities as Operational Activities
In the spirit of DevOps, each system capability must address how the end-user, among other product lifecycle stakeholders, would interact with the system. Therefore, I have decomposed each phase of flight into Operational Activities performed by (allocated to) either the pilot or the aircraft. The intent is that the pilot OAs represent the actions of the user or “operator,” and the aircraft OAs represent the system’s reactions. Taken together in a control flow, OAs represent how the user uses the system: system capabilities!
Figure 2: System Capability Decomposition
The Activity diagram (Figure 2) shows a demonstration excerpt of a “Take Off” system capability. It is not a complete OA decomposition; many more pilot and aircraft activities would occur after the parking brake’s release. But the example gives us a sense of how interactions between the user and the system work. Note that the Operational Items between the OAs are kept at a very high level. “Pilot LNAV Arm Cmd” might well be realized as an ARINC429 label from a touchscreen to the flight computer. But at the operational level, we cannot know how this exchange is implemented. Operational Activities are also kept at a very high level: the aircraft will do something to start departure lateral navigation. How it is done and with what subsystems is not the question to answer at the system capability level.
To transition from a system capability to system features, we will now look at the functional implementations of the OAs that make up the system capability. Since we are talking about system features, only the aircraft OAs are implemented by functions. The pilot OAs (actions) are modeled to ensure the aircraft OAs (reactions) are correctly set. The system behavior is what we are really after, to step through the hierarchy of the descriptive architecture. That said, the pilot OAs are not to be forgotten beyond the system capability definition. These operational “steps” could be useful when developing a system validation plan. As part of DevOps, we should take advantage of every design artifact to aid the testing and fielding of the system. Understanding the intended user’s procedures is essential in proving that we have built the right system.
How would we derive system features from the activity “Initialize Departure Lateral Navigation”? We know that to accomplish lateral navigation of an aircraft upon departure, the system needs to be able to follow a flight plan and know that it is in the Climb phase. Therefore, we could identify our first two system features. “Follow Flight Plan Route” and “Position Ship” implement “Initialize Departure Lateral Navigation.” You might ask, “Isn’t the feature to follow a flight plan route bigger than just implementing a navigation initialization activity?” The answer is “Yes.” The feature (function) is more comprehensive and complete than the fractional usage of its ability (operational activity). This is entirely acceptable and quite realistic. When the engineers design “flight plan route following,” they will not just work on a function by itself to “initialize the plan while still on the ground to navigate laterally immediately after takeoff.” This function is only one element in the complex behavior of self-positioning, mode capturing, legs and turns building, error detecting and correcting, etc. Systems engineering simply cannot force an operation-function implementation at such a micro level. As in most life situations, we build a whole tool, but we may only need a part of it for a particular usage for a specific scenario.
Let’s look at “Initialize Takeoff Vertical Guidance.” We could identify “Guide Aircraft in Takeoff Mode” as a system feature. A question may arise here: why am I not seeing the flight director mentioned in this context? Isn’t flight guidance all about the flight director after all? True, but the flight director is a function of the Display subsystem, generated by a label sent from the flight computer. This is the realm of subsystem features, which will be covered later in this article series.
From this short example (not complete) of a system capability, we could arrive at the following system features for the “Take Off” system capability:
- Follow Flight Plan Route
- Follow Flight Plan Glidepath
- Position Ship
- Guide Aircraft in Lateral Navigation Mode
- Guide Aircraft in Takeoff Mode
- Control Brake
When submitted to Program Management in a document form, my system capabilities and system features set looked quite straightforward in a hierarchy. Capabilities followed the usage of the system or phases of flight. A capability then had many features “below” it. But in fact, the actual translation from the CORE model was slightly more complicated:
- System capabilities are Operational Activities following phases of flight.
- A system capability is presented by interactions between the pilot and the aircraft and decomposing Operational Activities.
- The aircraft’s Operational Activities are then implemented by the system features.
In the next installment of the article, we will discuss why the implemented by relationship is so important when it comes to overlapping system capabilities.
