Specifying a Control Structure

Activity 0, Step 2 involves specifying the candidate control structure in an actionable format. This sets up the actual analysis to be performed in activities 1 and 2.

Drawing System Boundaries

An analyst begins by selecting the element closest to the controlled process that is inside the system boundary. Which elements, though, should be considered “inside” the system boundary? Recall from the introduction to Activity 0, where we explained that elements which are directly under the analyst/developer’s control should be considered inside the sys- tem, while those that are not should be considered to be in the environment. Note, however, that the boundary will, expand/shrink as analysts move up/down a system’s abstraction hierarchy.

Consider Figure 4.12, which overlays three boundaries onto the app-developer’s view of the PCA Interlock scenario from Figure 2.3. The innermost boundary, in red, is that of the app logic developer: he gets input from, and sends output to, the devices, but he has no control over what those devices are. The middle boundary, in blue, is that of the app designer herself: by specifying the properties required of the devices, she exercises direct control over which ones get used and which do not. She does not, though, control the patient or the clinician directly, so they are still considered environmental. Finally, the outermost boundary, in black, includes all elements of the clinical process. Other boundaries are possible, including those at both lower and higher levels of abstraction. Additionally, boundaries are not necessarily concentric: the PCA Pump creator’s boundaries exist at the same level of abstraction as the app logic developer’s, but they do not overlap.

Identifying Elements

The next task is to uniquely identify the elements by their place in the system’s control structure. When specifying a control structure, analysts should typically start at the con- trolled process and work backwards, at each element asking “what element(s) affects this current one?” For example, in the PCA Interlock scenario, an analyst would begin by considering the patient: what component or connection affects the patient? The IV line. What affects the IV line? The PCA pump. This process would continue iterating back-

wards through the control structure until all the elements identified previously have been allocated. When in doubt, analysts should recall the two-part notion of causality discussed in Section 4.1.4: for some component A to control some component B, A should have an intransitive, actual effect on B. In fact, it as at this level that we believe system causality becomes more of a burden than a benefit: when hardware- and software-based components are directly interacting, non-traditional models of causality can become quite unintuitive.

In Figure 4.12, the first element inside the app system boundary—when working back- wards from the patient—is the PCA Pump, so the analyst should start here. For M-SAFE this requires creating a copy of the element worksheet shown in Figure 4.15 for the pump. Then, the element is named and the names of predecessor and successor links are specified using row 4 of the worksheet.

In T-SAFE this step is automatically performed by specifying the app layout in the language subset from Chapter 3. Both the System and the Process constructs can be thought of as defining boundaries and decompositions, since they include an external interface (the type) and the internal decomposition (the implementation). Systems are used to specify the app’s overall component and connection topology, equivalent to the blue boundary in Figure 4.12. The Process construct is one level lower in the abstraction hierarchy, and is equivalent to the red boundary in Figure4.12. See Sections 3.3.2and 3.3.3 for details.

Specifying Classifications

In the hierarchical control structures used by STPA, components are typically assigned roles, e.g., controller, actuator, sensor or controlled process. We believe that this notion is useful, but SAFE generalizes the concept somewhat. We name these roles architectural classifications, but we expect that future work may come up with other, possibly domain- specific, classifications as well. These classifications may be used to guide tasks in activities 1 and 2, and we believe that they may be tailored by domain experts to if domain specificity

would be useful. The final task in Activity 0 is to document the role played by a particular component, or in the case of a connection, the roles played by its sender and receiver. In M-SAFE a component’s architectural classification is specified in cell 4H, while T-SAFE uses the Component Type property to set the value (see line 10 of Figure 4.13).

Note that if a single component has multiple successor links and could reasonably be classified under multiple architectural classification, the analyst should “split” the compo- nent for the purpose of the SAFE analysis. That is, since the system is being modeled based on its control structure—rather than its physical deployment—what we consider to be a component or connection are technically logical components and connections. Typi- cally these logical structures (e.g., app logic, PCA pump) align with physical realizations (e.g., executable code, a specific PCA pump) when a system is deployed, but in the cases where they do not, the logical structures should be modeled.

Backwards Iteration

Once a component’s classification(s) have been specified, the analyst can either start iden- tifying a new component by moving backwards one step in the control structure or proceed with analysis of a previously-identified element by beginning Activity 1. If the analyst moves to a new element, a new copy of the worksheet from Figure 4.15 should be created for each predecessor that has a link to the current element, and the analyst should return to the “Identifying Elements” task. This backwards iteration should continue until all el- ements inside the system boundary (as specified at the beginning of this step) have been identified. Note that any time after a component’s predecessors have been fully identified and documented as part of Activity 0’s second step, Activity 1’s tasks can be performed on it. If multiple analysts are available, the two activities can be performed in parallel, as long as each component’s predecessors are fully identified before its external interactions are analyzed.