Keywords

7.1 Introduction

Visualization can enrich the understanding of industrial safety, especially for complex industrial operations. In complex industrial operations, the work is often under-specified. The success of such operations relies on local adjustments by workers to account for the under-specification. Furthermore, these local adjustments can cause chaotic system behaviours over time and make it difficult for safety and risk assessors to imagine how outcomes might emerge from the operations. The difficulty in foreseeing outcomes and anticipating system behaviours can make the operation seem opaque or intractable. The opaqueness of the operations can lead to improper diagnosis of safety concerns and, in turn, poor safety management decisions.

This operational opaqueness has been evidenced in conventional approaches to safety analysis. One popular approach to safety analysis is to hypothesize about important accident causing factors and examine an operation to obtain an understanding of each factor’s significance to accident causation. This approach has been used with some effectiveness, but while it may help identify some of the significant contributors to accidents, it does not provide an understanding of how system behaviours might be affected by making changes to the identified contributor. The factors’ interconnection with other operational elements is important information for explaining operational outcomes and implementing safety management decisions. Consider that the accident causing factors that may be of interest to your analysis are part of a larger system that have complex inter-relations that contribute to the system’s functionality. It will be difficult to ascertain whether the factors being assessed are also influenced by other factors within the system without somehow examining the system as a whole. This gap can be addressed by adopting a system analysis approach which focuses on understanding the entire system rather than just a few elements of it. Figure 7.1 illustrates how the traditional approach can leave the system seeming opaque and how a system modelling approach can help illuminate the system structure.

Fig. 7.1
2 Illustrations of traditional approach analysis. 3 factors leading to a model without a system are blank, whereas 3 factors leading to a model with a system depict the structure with nodes and connections.

Analysis without system model (top) versus analysis with system model (bottom)

The complexities in operational systems can be difficult to imagine and thus having a visualization tool to animate the processes is advantageous. In this chapter, we propose using functional signatures, which is an extension of the functional resonance analysis method (FRAM), to visualize complex operations with the purpose of enhancing learning and informing safety management.

7.2 Background

7.2.1 Fram

The functional resonance analysis method (FRAM) is a system functionality modelling method [1]. The method has two main modelling components: (1) the functions or activities and (2) the variability. The first part of the FRAM involves describing the potential functions that are or could be used to achieve some goal. The functions are work that is done within the system. The basic rule to distinguish functions from other system parameters is to determine whether something is being produced. If there is nothing being produced, there is no work being done, and thus it should not be modelled as a function. Each function has 6 aspects that can be described: (1) input(s), (2) output(s), (3) resource(s), (4) time, (5) control(s) and (6) precondition(s). The aspects help understand the expectations of each function, by explicitly considering what is produced [output(s)], what initiates the function [input(s)], what is required prior to the function’s execution [precondition(s)], what is consumed by the function [resource(s)], what constrains the functional process [control(s)] and what ways are the available time to execute the function affected (time). In addition to providing an understanding of how a function might be executed individually, the aspects also provide a mechanism to connect multiple functions and build a functional system. As outputs are produced by functions, they may be utilized by other functions, thus coupling one function’s outputs to one or more of the other five aspects for another function. Figure 7.2 illustrates the concept of a functional node and a functional system.

Fig. 7.2
2 illustrations of F R A M node and F R A M model. a. F R A M node has hexagonal function activity with 6 nodes labeled control, output, resources, preconditions, input, and time. b. A F R A M model has 6 interconnected functions.

FRAM node (top left) and FRAM model (bottom right)

The second part of the FRAM is to model the variability. The FRAM focuses on modelling the variability in two ways: (1) the variability of individual functional outputs and (2) the coupled variability of multiple functions. The individual functional variability refers to the output of a single function. Individual outputs can vary with respect to time and with respect to precision. High variability functions are not necessarily seen as harmful, in some cases there must be an allowance for high variability to accommodate many possibilities. Similarly, low variability is not necessarily seen as desirable. Once the individual functional variability is characterized, the next step is to understand how certain configurations of variability throughout the system might combine to produce outcomes. The understanding of coupled variability can be used to monitor and manage the functionality of systems.

7.2.2 Functional Signatures

The FRAM is itself a visualization technique. FRAM models can be visualized using the FRAM model visualizer (FMV) which is freely available online [2]. The FMV allows users to visualize their FRAM models, displaying the functions and relationships between them. The model is a representation of the potential functional processes that could be executed to achieve the overall goal of the system. This static visualization of the FRAM model illustrates the first part of the FRAM—describing the system—but does not offer the ability to visualize the variability.

Functional signatures can be used to visualize the variability of operations by way of an extension to the standard FRAM visualization. Functional signatures are recorded accounts of the functional activity and individual functional output variability over time. As operations are executed, the functionality can be monitored over time. Likely not all of the functions in a FRAM model will be active at once and the location within the FRAM model of the functional activity will change over time as different functions become active. The functional activity can be traced over time helping to understand the dynamic nature of functionality in complex systems. In addition to the dynamics of the functional activity, the outputs of the active functions can be monitored. After the function is executed, the quality and/or quantity of the output can be recorded. Monitoring this will help understand the nature of variability with respect to the functional outputs—are the outputs produced the same every time, are they produced on time, or is there a lot of variability in the output? Specific combinations of variability can lead to differences in outcomes for the overall system; thus, it is important to trace the functional signature that is left behind as certain outcomes are achieved.

Functional signatures are created by logging the functional activity and functional outputs over time. The log can be visualized by using video and a few additions to the standard FRAM visualization conventions. The system can first be modelled using the standard FRAM procedures [1]. At this stage, the model represents the potential functional possibilities of the operation. The functional signature—the specific functional activities and functional outputs over time—can then be visualized by (1) distinguishing active functions from inactive functions usually by using colour and (2) writing the quality and/or quantity of a specific output on the line that connects the active function’s output to a downstream function. See Fig. 7.3 for an example of this concept.

Fig. 7.3
An illustration of the functional signature of 5 active functions. Function 1 to 6 are connected through function 2 and 5 and function 3 and 4, where function 5 is inactive. The outputs are connected to the inputs giving output variation, also function 2 output is connected to function 4 control.

Functional signature with active functions bolded in red

7.3 Discussion

The concept of functional signatures is rather simple but the manifestations that occur when monitoring complex operations can be more complicated. The level of complexity will depend on the nature of the operation. Operations that have a large number of functions that are highly connected will generally produce more complex functional signatures than smaller, less connected ones. Other operations that can produce more complex manifestations are operations that are modelled recursively. A recursively modelled operation is an operation that requires constant management in real-time and allow for worker interventions. When modelling an operation recursively, the focus is on modelling the management-intervention process. The management-intervention process is repeated as many times as needed. This means the model could repeat many times while the operation is working towards achieving its goal, thus increasing the complexity.

In order to demonstrate the functional signature concept, an example is used based on ship navigation in a simulated ship environment. A ship simulator for ice management was used to monitor an operation and generate functional signatures. The ship simulator consists of a platform with ship-like controls, situated in the centre of a wraparound projection screen, where users have a 360° view of the environment they are operating in. Figure 7.4 shows the setup for the ship simulator. The ice management operation involved a support vessel (AHTS—anchor-handling tug supply vessel) for a larger “fixed” offshore installation that was surrounded in pack ice. The driver of the support vessel was asked to clear a zone in the pack ice where a lifeboat could be launched. This scenario is outlined in Fig. 7.5. As the driver navigated the support vessel through the pack ice, the functionality of their operation was tracked.

Fig. 7.4
An illustration of a ship simulator setup. A circular cabin with 360 wraparound projection screen has ship-like controls in the center of the cabin from which the ship can be simulated and saved from calamities.

Ship simulator setup

Fig. 7.5
An illustration of a scenario in which the ship is surrounded by pack ice. The other parts labeled are the petroleum installation site at the bottom and the A H T S in the center.

Scenario configuration for the ship simulator

The first step is to create a FRAM model for ship navigation. A model was created via interviews of ship captains. The details of the modelling process can be seen in [3]. However, the model presented here has a reduced scope to minimize the clutter of functions that could not possibly become active in the simulated environment. The FRAM model is displayed in Fig. 7.6. The FRAM model describes how the driver will make assessments of their situation and decide whether or not to change course (intervene) or maintain it. The assessment will be based on their understanding of the ice conditions, where they are positioned in their environment, their vessel parameters and an awareness of a regulatory requirement to keep the speed of this vessel below 3 knots in the ice field. This process is repeated as many times as needed as the driver tries to achieve their goal—clearing ice from the lifeboat area.

Fig. 7.6
An illustration of the F R A M model for ship navigation lists the following steps. Observe ice conditions, forecast ice conditions, assess locations, make situational assessments, monitor vessels, compute ice numerals, assign ship classification, and beware of the ship's capabilities.

FRAM model for ship navigation

By using this FRAM model and monitoring the functionality of the driver during the operation, functional signatures can be created. There are two visualization techniques that can be used to view this type of recursively modelled operation: (1) cyclic functional signatures or (2) linear functional signatures. There is value in both of these visualization techniques and one is not necessarily better than the other. Users may use both visualization techniques as dictated by their preference.

7.3.1 Cyclic Functional Signatures

The cyclic visualization technique keeps the original FRAM model static, in the background, and overlays the functionality of the operation as it animates. Figures 7.7 and 7.8 demonstrate of a cyclic functional signature for a driver of the ship simulator. Figure 7.7 shows the assessment function becoming active after receiving two outputs from the two upstream functions at time equals 11 s. Figure 7.8 shows the cycle being repeated after a heading change was made. The cyclic will then repeat as operator performs the next task.

Fig. 7.7
An illustration of a cyclic functional signature lists the following steps. Observe ice conditions, forecast ice conditions, assess locations, make situational assessments, monitor vessels, compute ice numerals, assign ship classification, and beware of the ship's capabilities.

Cyclic functional signature 11 s after beginning

Fig. 7.8
An illustration of cyclic functional signature 70 s lists the following steps. Observe ice conditions, forecast ice conditions, assess locations, make situational assessments, monitor vessels, compute ice numerals, assign ship classification, and beware of the ship's capabilities.

Cyclic functional signature 70 s after beginning

7.3.2 Linear Functional Signatures

Linear functional signatures march forward with time as the operation is shown. The FRAM model will be copied ahead of itself and the active functions are highlighted as each recursive cycle is shown. Also, there can be an option to only display the active functions when the model is copied in front and hide the inactive functions. This option can hide unnecessary clutter as the functional signature is displayed. Figure 7.9 displays a snapshot of a linear functional signature a driver of the ship simulator with the inactive functions hidden. Figure 7.9 shows another cycle of the model beginning with three active functions after a course change. It is also important to note that the model may appear stretched or compressed with respect to the original FRAM model layout. The stretching and compression is determined by the time it takes for functions to be completed. Functions that take longer to be completed will appear stretched opposed to functions that are completed quicker.

Fig. 7.9
An illustration of Linear functional signature 55 s lists the following steps. Observe ice conditions, forecast ice conditions, assess locations, make situational assessments, monitor vessels, compute ice numerals, assign ship classification, and beware of the ship's capabilities.

Linear functional signature 55 s after beginning

7.4 Conclusions

Industrial operations can be complex, leading to unexpected outcomes, which is a safety concern. Much of the uncertainty associated with these complex operations stem from intractability and system opaqueness. This chapter presents functional signatures as a visual technique that can help monitor complex operations and improve tractability. Creating a functional signature requires that key functional activities are monitored and recorded. Two versions of functional signatures are presented in this work: (1) cyclic functional signatures and (2) linear functional signatures. Both visualizations are seen as valuable to operational safety assessments. The cyclic functional signature shows how the functionality propagates through the FRAM model as the original model remains unchanged in the background. The linear function signature still illustrates the propagation of functionality but uses time marching to scale the horizontal length of the model. Since both techniques illustrate the propagation of functionality, which is highly intractable for complex industrial operations, both techniques are considered valuable. The selection of technique should be left to user preference.