Information Requirements of a Decision Support System for Severe Accident Management in Nuclear Power Plants

Abstract

In nuclear power plants, a severe accident is a critical accident involving significant nuclear core damage and it is managed by using a set of Severe Accident Management Guidelines (SAMG). Prepared as a guideline that provides lists of suggestions rather than strict instructions, SAMG’s contents require frequent decision-making by the operators, causing high cognitive load and creating an error-prone situation that is also amplified by the stressful environment during the severe accident mitigation efforts. A decision support system (DSS), designed by considering the human decision-making process and the system’s holistic view, can help the operators in making informed and appropriate decisions. In this study, we aim to identify the information requirements in designing such DSS for severe accident management of nuclear power plants. We combined two methods: Functional Resonance Analysis Method (FRAM) and decision ladder to identify the information requirements. FRAM provides a systematic analysis of the functions involved in severe accident management and decision ladder captures the human decision-making processes. We developed the FRAM model and the decision ladder model based on SAMG’s contents to identify the set of information requirements. The identified information requirements and their implementation suggestions are provided. This study is the first step in designing a decision support system that considers human cognitive load and holistic system concepts. The method used in this study shall contribute to the design and implementation of a DSS capable of supporting the operators in achieving safer decision-making, not only in nuclear power plants’ severe accident management but also in similar safety-critical systems.

1. Introduction and Backgrounds

Complex socio-technical systems consist of nonlinear and dynamic interactions of machines, information technologies, and human workers as individuals and as an organization [1,2,3]. Internal and external interactions between the system’s components cause the inherent possibility of accidents that can progress in novel, unpredictable, and dynamic ways in a complex socio-technical system. Nuclear power plant (NPP) is a type of complex socio-technical system, consequently, the possibility of accidents is inevitable. In this study, we are interested in the most critical type of accident at NPPs, called the severe accident, which is when the NPP damage has reached the nuclear core, causing a high probability of a dangerous nuclear radiation release to the resident and their environment. The circumstances of severe accidents are unstable and highly uncertain, which makes severe accident mitigation efforts different from other accident management [4]. During the NPP severe accident mitigation, the operators are required to perform frequent decision-making under highly stressful situations to maintain adaptive strategies as the accident unfolds.

A common approach to support the decision-making during severe accident management in an NPP is to provide a set of Severe Accident Management Guidelines (SAMG), typically as documents. SAMG acts as the minimum support provided to the operators and the provision of SAMG is mandated through the NPP safety regulations, for example, by the Korea Hydro and Nuclear Power in South Korea. Compared to other NPP’s accident management procedures, such as the Emergency Operating Procedures, SAMG is less disciplined, namely, it contains a range of abstract task suggestions, demanding a high cognitive workload from the human decision-makers [4]. Therefore, a Decision Support System (DSS) shall be highly useful to support effective and safer decision-making under high pressure and turbulent conditions [4,5,6]. To support the decision-makers effectively, DSS should provide the required information by the operators through a holistic vision of the system [4,5,6,7,8]. In this study, we aim to identify the information requirements required for managing severe accidents at NPPs using a systemic system modeling method and a human decision-making process analysis method.

The systemic viewpoint allows for the understanding of a system, its components, and their interactions to understand the complex socio-technical systems comprehensively [9,10,11]. Functional Resonance Analysis Method (FRAM) is a system modeling method that adopts a systemic viewpoint to analyze the system based on the functions and the dynamic interactions between the functions [12,13]. FRAM is proved as a valuable method for modeling complex socio-technical systems such as the NPP’s severe accident management [13,14,15]. Moreover, we also applied the decision ladder to understand the fundamental human’s decision-making processes in terms of data-processing activities and states of knowledge, as well as the users’ interactions with the DSS [16,17,18,19]. We developed FRAM and decision ladder models of severe accident management situations using SAMG as the main source of data. Each model is created to determine the information requirements for the DSS.

The critical and large-scale damage from NPP severe accidents require stronger counter-measures than SAMG documentation. Thus, the interest in DSS development designed for managing severe accidents is increasing. In this study, we do not use the term DSS to refer to an information system or software, instead, we consider various forms of tools that serve the goal of anticipating and managing severe accidents. Such DSS can alleviate the operators’ cognitive burden from intensive decision-making during severe accident mitigation efforts to increase the probability of effective and safe decision-making results. To develop such DSS, we need to take the human cognitive point of view, specifically the human information processing and decision-making, as well as the constraints of the working environment, into consideration. These cognitive points of view and constraints can be represented as a set of information required by the decision-makers. The importance of a correct and complete set of information requirements is being increasingly emphasized throughout the years. Motivated by this, the objective of this paper is information requirements identification as the first step of DSS development for managing severe accidents.

To the best of our knowledge, our approach is the first attempt to combine FRAM and decision ladder for systems development, including information requirements development, of DSS. FRAM and decision ladder complement each other, similar to the way system-based analysis complements task-based analysis [20]. FRAM inherits the main drawback of system-based analysis, i.e., it cannot analyze the internal aspects of individuals, such as their information-processing, knowledge, cognitive load, and so on. The decision ladder complements this drawback by allowing the analysis of an individual’s information processing and other cognitive details while performing a certain task. The limitation of the decision ladder, as a type of task-based analysis, is that it can only be used to analyze predetermined tasks and cannot consider unpredictable events nor holistic view of the system. The analyst’s ability to analyze the tasks/functions by following the FRAM modeling principles (performance variability and resonance) complements this limitation. Thus, the FRAM and decision ladder are mutually reinforcing. By combining both methods, we expect to develop a comprehensive set of information requirements for a DSS that considers the cognitive side of human decision-making and can cope with unpredictable events. The resulting set of information requirements is not only necessary but also a sufficient set of information requirements that, if satisfied, shall allow work adaptations under the broadest range of events [20].

1.1. Functional Resonance Analysis Method (FRAM)

Applied as a system modeling method, FRAM serves as a means to achieve a thorough understanding of a system of interest/work domain, comparable to general-purpose system modeling methods [21]. FRAM’s properties allow the system analysts to capture the relations between functions without the limitations from the physical elements’ boundaries and work sequences, enabling performance variability analysis that is restricted in other modeling approaches. FRAM accommodates modeling in a dynamic manner, which is needed to model and analyze complex socio-technical systems covering numerous interactions between humans, technology, and organizations, such as the severe accident management in NPP. Since its first publication in 2004, FRAM has become well-known with more than 200 publications worldwide in 2020 [13].

FRAM is developed based on system theory that focuses on functions and their relations in a complex socio-technical system/work domain [12,22]. The most notable characteristic of FRAM is that the relations between functions are not restricted by either the physical elements’ boundaries or the sequences of works/processes [23]. This characteristic leads to FRAM’s key analysis, that is, the ability to identify the performance variability inherent to certain functions and, through the connections with other functions, can unfold into daily normal (successful) operations or unexpected failures/incidents. The performance variability from a function can spread to other connected functions, where the connection determines either to maintain, amplify, or dampen the variability, hence the ‘resonance’ of the function [24]. FRAM is especially useful to analyze unanticipated critical events, such as accidents, in complex socio-technical systems [21].

The FRAM model, i.e., the modeling result using FRAM, consists of functions, the functions aspects that connect functions, and the contents of the aspects; together, they compose and define the work domain’s activities and behavior attributes [24]. The FRAM function has six aspects: Input, Output, Precondition, Resource, Time, and Control. The Input starts the function or the function processes the Input to create the Output. When Precondition exists, it must be satisfied before the function can be carried out. The function needs or consumes Resource while it is being carried out. The temporal constraints are included in the Time aspect (starting time, finishing time, or duration) and the monitoring or controlling terms are included in the Control aspect. The allowed connection is between the Output aspects and the five other aspects: Input, Time, Control, Precondition, Resource [24]. The FRAM function is drawn as a hexagon and the six aspects are placed in each of the outer corners, as shown in Figure 1a. The connected group of functions forms a model, as shown in Figure 1b.

1.2. Decision Ladder

For about 50 years since the invention of the decision ladder, it has been applied to understand human decision-making from an information processing point of view [18]. The decision ladder was not meant to be used as an absolute model of the human decision-making process, instead, it was proposed as a template where the analysts can map their findings on a certain event of interest to find the structure or reasoning behind the human’s decision-making process [2]. We included the decision ladder in our effort of information requirement elicitation because the frequent and crucial decision-making by the human operators during severe accident management of NPPs exposes the importance of understanding human decision-making. Using the decision ladder, we aimed to analyze the internal/cognitive aspect of the operators when they are about to decide on an action and extract the information they require.

The profound contribution of the decision ladder as a template to map human decision-making processes is the finding that novices and experts make decisions inherently differently, and the systems designers can apply this insight to accommodate both novice and expert users. Novice users tend to strictly follow the sequence of tasks, from the starting signal of events to the final execution of actions, while expert users tend to exert their experience of performing exact/familiar tasks, resulting in shortcuts in the decision ladder [26]. Researchers have applied this decision ladder’s ability in analyzing novices’ versus experts’ decision-making processes in their studies.

Our study, however, has a different point of view. Expertise is not only related to the depth of knowledge but also the experiences of the situation [27]. Thus, in the case of NPP severe accidents, we assume the lack of experts in most NPPs, given severe accidents, took place three times during commercial operations worldwide. Therefore, we apply the decision ladder in our study to capture the required information by the operators when they are faced with a decision-making task, as novices are expected to act by following the step-by-step of the information-processing activities in the decision ladder. The decision ladder consists of two types of entities: information-processing activities and states of knowledge as the results of the preceding information-processing activities [2].

1.3. Earlier Works Related to FRAM and Decision Ladder

FRAM in the industrial domain and NPP. Industrial domain is the third-largest application domain of FRAM, in which it has been used for accidents and resilience analysis [13]. In the domain of NPPs’ severe accidents, [28] developed a FRAM model capturing the Fukushima Dai-ichi 2011 accident. The Fukushima accident had been analyzed exhaustively throughout the years and even though [28]’s findings on the accident causes were not new, they showed the applicability of resilience engineering through FRAM for both retrospective and (limited) prospective analysis to expose the hidden risks. The authors of [29] tried to reduce the gap between work-as-imagined and work-as-done to improve the NPP’s emergency procedures. This study found that FRAM can contribute to creating procedures for novel situations in NPP, especially in the early stages of procedure design.

FRAM for DSS and requirements development. FRAM has been used to develop DSS or elicit requirements since 2016, quite late from its first introduction in 2004. The authors in [15] applied FRAM to develop a DSS, together with a modified Analytical Hierarchical Process (AHP). Compared to our study, [15] elicited a small number of aspects or information requirements while we developed a comprehensive set of information requirements that can be used to develop various types of DSS for safety-critical domains. Moreover, although [15] showed a practical use of FRAM to develop a DSS, they assumed that the data to calculate the probability of the FRAM aspects were available. We considered the importance of identifying the source of information requirements, which is partly provided in the current study and shall be polished in future works.

FRAM was applied after a work domain analysis using Abstraction Hierarchy in [23] to create systems requirements for a centralized information display system to support human decision-making. The final outcome of [23] was systems requirements and we could not analyze their information requirements in detail, however, we predict that our study shall lead to a higher number of information requirements through the combination of FRAM and the decision ladder. The feasibility of FRAM to identify software requirements in the healthcare field is explored in [22]. By following MacKnight’s systematic approach for requirements engineering, the authors performed experiments using Business Process Modeling Notation and FRAM to develop software requirements. The experiments results showed that FRAM was able to extract a higher number of requirements, both functional and non-functional, especially, the requirements related to resilience properties. A lean business methodology called GUEST (Go, Uniform, Evaluate, Solve, and Test) is applied to develop a DSS in the automotive industry, together with a mathematical model to tackle the uncertainty, however, the cognitive aspects of the human decision-makers are not included [8].

Decision ladder in the NPP domain. The research problem that led to the invention of the decision ladder was human operators’ works analysis in industrial process plants [30]. Thus, an NPP is among one of the most common application domains of the decision ladder. Vice versa, NPPs play a major role in nurturing the scientific and practical research of the decision ladder, under the cognitive systems engineering’s umbrella [31]. Research about decision ladder application for NPPs is still carried out steadily, for example, the attempt to define the transformative new state of NPP in the United States was published in 2021 [32].

Decision ladder for information requirements development. Decision ladder has been frequently applied to conduct cognitive task analysis, which is an effective method for deriving interface design concepts and requirements [33]. Consequently, the decision ladder has been used to elicit requirements for quite some time. We observed that most of the studies focused on design requirements from the human users’ point of view. Several works that mentioned information requirements were highly related to the display or interface requirements of an information system [34]. An early study on information requirements elicitation as a part of interface design for complex production processes was proposed by [20]. Three cognitive systems engineering methods were compared to identify the information requirements, namely: Abstraction Hierarchy as a system-based analysis, Hierarchical Task Analysis, and Control Task Analysis using decision ladder, as two task-based analyses. This study showed that the information requirements extracted from the system- and task-based analyses were mutually reinforcing, leading to a more comprehensive set of information requirements. In our study, we also combined a system-based analysis and a task-based analysis.

The decision ladder was included as the final step in [33]’s four-step hybrid Cognitive Task Analysis (hCTA) framework aiming to generate information and display requirements for futuristic systems. Similar to our approach, the identification of tasks (or functions) involved in the work domain preceded the decision ladder modeling. The hCTA framework has several continued studies, for example, [35] used hCTA to generate display information requirements. A decision ladder is applied to guide the semi-structured interviews and to generate the information requirements for human-machine interfaces of radiotherapy equipment in [34]. The approach to dividing the task phases was not specified, whereas, in our study, we applied FRAM to identify the functions/tasks. This study also considered the distribution of the information requirements through time and space by analyzing when, where, and how the information shall be required by whom using heuristic analysis. FRAM can be applied to perform similar analyses.

FRAM and the decision ladder combination. FRAM has been combined with various methods, as presented in a non-exhaustive survey by [36]. The decision ladder has also been combined with various approaches or integrated as a framework, such as the Cognitive Work Analysis (CWA) framework [2]. Unlike FRAM which can be applied independently, the decision ladder requires a preceding analysis to identify the tasks in the work domain. For example, in the CWA, the decision ladder is used to perform control task analysis, the second step after work domain analysis using the Abstraction Hierarchy.

To the best of our knowledge, our study is the first attempt to combine FRAM and decision ladder to elicit requirements. In [37], the authors proposed a concept to combine FRAM with conceptual design and Cognitive Work Analysis (CWA) to specify information systems requirements. They described the roles of each approach, namely, contextual design as the process of information identification, CWA as the procedures of mental models identification, and FRAM as the method of functions modeling. The decision ladder was not mentioned explicitly, however, it is the default method for the second phase of CWA [2]. However, we could not find a continued study to verify the attempt to combine FRAM and the decision ladder.

FRAM and decision ladder trends. FRAM is a promising method to model a modern system that is complex, dynamic, and consists of technical–human–organizational interactions, the so-called complex socio-technical system. Lately, research about FRAM is growing in various directions; there are efforts to strengthen its scientific basis, such as the quantification of FRAM [38], to promote the practical use of FRAM, such as the integration of FRAM with HYSIS Dynamics simulators [39], and to expand the application domains of FRAM [13]. In the case of the decision ladder, despite being an early method, researchers still apply this method steadily for decision-making analysis, decision support system design, and as a new supporting tool to solve various problems. Recent examples are the pilots’ decision-making analysis during a new and unexpected type of malfunction in [27] and the effects of different rail maintenance strategies that depend on the available technologies in [40]. Moreover, [27] compared the decision ladder with other decision-making models and discovered that the decision ladder has the highest contributions to designing a decision support system.

2. FRAM and Decision Ladder Models’ Development

2.1. Models Development Approach

We developed the information requirements from the FRAM model and decision ladder model. From the FRAM model, we obtained the functions and their aspects; from the decision ladder model, we obtained the (information processing) activities and (states of) knowledge. Both models were created within the scope of severe accident management of NPPs, with SAMG as the main information source (a set of SAMG for a NPP in South Korea). We started with FRAM modeling to understand the work domain holistically and produced the interconnected functions and their aspects. Then, each function was matched to one or more decision ladder activities and recorded in a matrix form, called FRAM-Decision Ladder Matrix. From the mapped activities, we developed the decision ladder and analyzed the required or resultant knowledge. FRAM and decision ladder models were developed iteratively until consistency is reached. The functions’ aspects from the FRAM model and the activities’ knowledge from the decision ladder model formed the set of information requirements. The proposed information requirements development approach is shown in Figure 2.

2.2. FRAM Models

The FRAM model for severe accident management of NPPs is shown in Figure 3. We used the FRAM Model Visualizer tool [41] to create the model and the aspects’ names were hidden for presentation clarity. We observed 14 functions related to managing severe accidents of NPPs, listed in

Table 1. List of functions from FRAM Modeling Results.

No	Function Name	No	Function Name
F.1	Secure power	F.8	Decide the measures/methods to perform mitigation strategy
F.2	Perform control guideline (select mitigation strategy)	F.9	Instruct for plant recovery measures
F.3	Monitor power plant’s condition	F.10	Evaluate the results of mitigation strategy implementation
F.4	Identify the available measures/methods	F.11	Identify and evaluate the devices/facilities recovery measures
F.5	Identify the impacts of mitigation strategy	F.12	Identify and evaluate the measures to mitigate the occurred negative impacts
F.6	Evaluate the possible negative impacts from mitigation strategy	F.13	Evaluate the recovery measures
F.7	Decide whether to implement the mitigation strategy	F.14	Evaluate the alternative strategies

. In the following, we discuss the main insights from the FRAM model, i.e., (1) important functions with a higher number of aspects, (2) high workload function with a lack of SAMG content, (3) model development using the work-as-imagined concept, (4) absence of model instantiation, and (5) the FRAM model limitations.

(1) Important functions with a higher number of aspects. Provided the analysts possess the domain knowledge and consistent granularity in creating the FRAM model, the number of connections of a function shows its relative importance or complexity. In our model, functions with a high number of connections are: ‘F.2 Perform control guideline (select mitigation strategy)’, ‘F.7 Decide whether to implement the mitigation strategy’, and ‘F.11 Identify and evaluate the devices/facilities recovery measures’. F.2 and F.7 are both main decision-making activities in the model (F.11 is discussed next). F.2 selects a mitigation strategy among available strategies (in our reference SAMG, there are eight mitigation strategies) based on the current safety variables. After a certain strategy is chosen, the operators carefully examine the execution method and estimate the impacts of the strategy implementation on the accident. Then, the operators have the option to either proceed or cancel the strategy execution, as in F.7. As the main decision functions in severe accident management, we expect F.2 and F.7 to be performed cautiously by referring to a higher volume of information compared to the remaining functions. This indication can be well captured in the FRAM model.

(2) High workload function with lack of SAMG content. We found a function containing a high workload, cognitively and physically, but it has minimum description in the SAMG content. This function is the recovery measures taken after the operators decided not to perform the mitigation strategy, namely, ‘F.11 Identify and evaluate the devices/facilities recovery measures’. Two occasions may trigger this function, both refer to the two reasons the operators chose not to perform the mitigation strategy: (1) when there are no available measures/methods to carry out the mitigation strategy and (2) if the estimated negative impacts happened, they would not be able to be mitigated. F.11 implies these tasks: analyze why the devices/facilities were not available, identify how to fix or return them to available status, analyze why the negative impacts cannot be mitigated, identify how to recover the methods required to mitigate the negative impacts, evaluate the priority of the repair/recovery works based on the current workload, arrange the repair/recovery workflow (when and who), and finally, instruct and carry out the repair/recovery of the devices/facilities. The content in SAMG fails to capture the complexity of F.11, thus, we took a more detailed analysis of this function. By using FRAM modeling, we were able to represent the workload of F.11 through a high number of connections (refer to the previous finding).

Four evaluation functions carried out at the latter part of SAMG also imply a high cognitive workload, they are: ‘F.10 Evaluate the results of mitigation strategy implementation’, ‘F.12 Identify and evaluate the measures to mitigate the occurred negative impacts’, ‘F.13 Evaluate the recovery measures’, and ‘F.14 Evaluate the alternative strategies’. The high cognitive load is caused by the lack of details about the acceptable performance range or evaluation timing/schedule; only the target performances are given in the guidelines. The operators have to decide when to start and end the evaluation period, as well as the acceptable performance range. Additionally, F.10 entails the decision of whether to repeat the same strategy, while F.12, F.13, and F.14 involve whether to instruct the implementation of a certain recovery measure or an alternative strategy.

(3) Model development using the work-as-imagined concept. FRAM modeling principles do not require a predetermined or sequential order of functions, but rather encourage capturing the dynamic connections between functions as they occur in the real operation conditions (work-as-done, WAD), especially considering FRAM was initially developed for retrospective analysis. In our study, creating the FRAM model based on the WAD concept means modeling the already occurred severe accidents. While such analysis might be useful, it is not a suitable approach to our current prospective study. To match our intention of developing the information requirements for managing severe accidents, instead, we modeled using the work-as-imagined (WAI) concept, in particular by referring to the content of SAMG. The explicit information in SAMG is included in the model and the analysts searched and added supplementary information whenever required. Moreover, SAMG’s content is highly related to a certain NPP. The target NPP of our SAMG has not experienced any severe accidents, adding to our limitations to observe and develop the model based on WAD.

(4) Absence of model instantiation. We created one FRAM model for our study, without any instantiated version. System modeling methods usually proceed with model instantiation after creating the baseline model. In the case of FRAM for accident analysis, after modeling the work domain as a baseline model, it is instantiated to represent the specific accident scenario of interest. Or the analyst may create a baseline FRAM model from the WAI concept and instantiate it based on the WAD concept. The WAD-based accident model is then compared with the WAI-based version to analyze how the event unfolds and how to prevent it in the future. Presently we are not analyzing accidents, thus, we did not feel the need to instantiate the model. We included all the possible management scenarios, as mentioned in SAMG, in our FRAM model. The model that we created, however, can be used as a meta-model to analyze each mitigation strategy separately.

(5) FRAM model limitations. In our reference SAMG, there are two monitoring tasks for two sets of variables: safety variables and severe risk variables. Both sets of variables are monitored continuously and simultaneously, with higher priority given to the severe risk variables. While the operators are carrying out a certain mitigation strategy, they can be interrupted and instructed to carry out a different mitigation strategy when the severe risk variables monitoring implies so. In our model, however, we excluded this interruption workflow because it does not affect the information requirements elicitation. We suppose that this kind of interruption order shall be considered in the design of the alarm of an information system display.

Since our main data are SAMG, there are times when we opted to follow the content of SAMG strictly into the model. This decision may lead to the degradation of the model’s generality in creating the functions. In our case, we create a separate function ‘F.14 Evaluate the alternative strategies’ rather than including the alternative strategies in the ‘F.4 Identify the available measures/methods’ because the guideline has an inclusive definition of ‘alternative strategies’. This decision also caused the failure to reflect some high workload functions in the FRAM model as functions with a high number of aspects. We analyzed the high workload functions that are not reflected in the instructions of SAMG, i.e., F.11, and evaluation functions F.10, F.13, and F.14. From these functions, however, only F.11 has a high number of aspects compared with other functions. This failure to capture the high workload functions (or tasks from the workers’ point of view) in the FRAM model shall be complemented in the decision ladder model.

2.3. Decision Ladder Models

The functions from the FRAM model are used to populate the FRAM-Decision Ladder Matrix and the functions’ aspects are stored as information requirements. We evaluate and map the functions to the appropriate information processing activities in the decision ladder and elicit the information requirements by expanding the prompts and generic keywords composed by [42]. The matrix is completed through multiple iterations of FRAM and decision ladder analysis. The final version of the matrix is shown in

Table 2. FRAM-Decision Ladder Matrix.

Activities		Activation	Observe Info.	Identify State	Predict Conseqnc.		Evaluate Performnc	Predict Conseqnc.	Define Task	Formulate Procedure	Execute
	Knowledge	Alert	Info.	System State	Options	Goals	Chosen Goals	Target State	Task	Procedure
Function
F.1 Perform control guideline (select mitigation strategy)		O	O	O	O	O	O
F.2 Secure power						O	O	O	O	O	O
F.3 Monitor power plant’s condition		O	O	O
F.4 Identify the available measures/methods		O	O	O
F.5 Identify and evaluate the devices/facilities recovery measures		O	O	O	O	-	O	O	O	O	O
F.6 Identify the impacts of mitigation strategy					O
F.7 Evaluate the possible negative impacts from mitigation strategy					O
F.8 Decide whether to implement the mitigation strategy					O	O	O	O
F.9 Decide the measures/methods to perform mitigation strategy									O	O
F.10 Instruct for plant recovery measures											O
F.11 Evaluate the results of mitigation strategy implementation		O	O	O	O	-	O	O
F.12 Identify and evaluate the measures to mitigate the occurred negative impacts		O	O	O	O	-	O	O	O	O
F.13 Evaluate the recovery measures		O	O	O	O	-	O	O	O	O
F.14 Evaluate the alternative strategies		O	O	O	O	-	O	O	O	O

Notes: Cells containing ‘o’ represent the mapping of the functions from FRAM to the pairs of (information processing) activities and (states of) knowledge from the decision ladder.

. In the following, we discuss the main insights from the decision ladder model, i.e., (1) the function-to-activity mapping rule, (2) complex functions with a higher number of activity–knowledge pairs, (3) the ‘Goals’ state of the decision ladder model, (4) the ‘Execute’ activity of the decision ladder model, (5) linear progression without shortcuts, (6) decision ladder model limitations.

(1) The function-to-activity/knowledge mapping rule. As shown in the matrix (Table 2), a function in FRAM is mapped into one or multiple pairs of activity–knowledge of the decision ladder. This mapping result is based on the following analysis principles. First, we created the FRAM model by following the FRAM guidelines by its inventor in [12], thus the identified functions are related to the FRAM modeling philosophies. To maintain FRAM modeling philosophies and the resulting systemic property, the functions cannot be modified without restrictions. Second, we did not find any scientific reason to keep a fixed mapping rule, for example, one function must be mapped into one pair of activities–knowledge. Keeping this kind of mapping rule can unnecessarily clutter the FRAM model. Third, we focused on our goal of information requirements elicitation, so we did not complicate the models. A limitation of our heuristic approach is that the results are highly dependent on the analysts. In our team, the main model developer has three years of FRAM modeling experience and the developer’s work is supervised by an expert in this field with more than 30 years of experience. An example of a FRAM function and decision ladder mapping is shown in Figure 4 and the information requirements from the decision ladder analysis are listed in

Table 3. Information requirements elicitation from the mapped decision ladder.

Activity	Knowledge	Description	Prompts	Information Requirements (Duplicates Removed)
Activation	ALERT	Entering severe accident situation	- Has severe accident occurred? - Are the severe variables exceed the thresholds? - Has the mitigation strategy carried out?	- Severe accident’s entry condition - List of severe variables - List of severe variables’ threshold - Decision whether to implement the strategy
Observe information/data	INFORMA-TION	Monitoring the plant’s condition	- What is the status of the power supply? - What is the status of the safety variables and severe variables? - What is the status of the pressurizer manway and RV head? - How is the progress of mitigation strategy implementation?	- Power supply status - List of safety variables - List of safety variables’ threshold - Pressurizer manway status - RV head status
Identify state	SYSTEM STATE	Select mitigation strategy	- Which mitigation strategy should be performed based on current power plant condition and control strategy?	- Power plant’s operation mode - Severe accident mitigation control strategy

.

(2) Complex functions with a higher number of activity–knowledge pairs. Similar to the FRAM model analysis, complex functions are reflected in the matrix as having longer steps in the decision ladder. The functions that have a high number of activity–knowledge pairs are: ‘F.11 Identify and evaluate the devices/facilities recovery measures’, ‘F.12 Identify and evaluate the measures to mitigate the occurred negative impacts’, ‘F.13 Evaluate the recovery measures’, and ‘F.14 Evaluate the alternative strategies’, as shown in Table 2. These functions start from activation, for example, ‘F.11 Identify and evaluate the devices/facilities recovery measures’ is carried out after (1) the devices/facilities required for the strategy implementation are not available and need to be recovered, or (2) the operators decided not to proceed with the mitigation strategy because they believe that some devices/facilities are not in acceptable condition and need to be recovered. Then, the information processing steps in the decision ladder were followed linearly. Continuing the F.11 example, after activation, the operators observe the information related to the current strategy, the status of devices/facility involved, recovery measures, and other related information. Then, the operators proceed with identifying the current state and predict the consequences of the recovery measures on the power plant and the workload, and so on following the decision ladder. Functions F.11, F.12, F.13, and F.14 are also identified as high workload functions in the FRAM model analysis

(3) Including the ‘Goals’ state of the decision ladder model. Through FRAM analysis, we observed seven functions that have a relatively higher workload, shown by the functions’ higher number of aspects (F.2, F.7, F.11) and through systemic analysis (F.10, F.12, F13, and F.14). In the decision ladder model, however, only four of those functions are found to have many information processing steps, i.e., F.11, F.12, F.13, and F.14. In the following, we explain the remaining F.2, F.7, and F.10 mapping in the decision ladder model to support the same analysis result.

Both ‘F.2 Perform control guideline (select mitigation strategy)’ and ‘F.7 Decide whether to implement the mitigation strategy’ do not have long information processing steps in the decision ladder, however, they include the ‘Goals’ state in the ‘Evaluate performance’ activity to decide the ‘Chosen Goals’ (marked ‘o’ in the Goals column in FRAM-Decision Ladder Matrix). The inclusion of ‘Goals’ implies that the goal is being identified or modified from the preceding state while its exclusion means that the goal remains the same (within the same workflow). Specifically, the ‘Chosen Goals’ in F.2 are to evaluate the selected mitigation strategy from the ‘Goals’ to mitigate the severe accident and the ‘Chosen Goals’ in F.7 are either to (1) implement the mitigation strategy or (2) cancel the strategy and proceed with devices/facilities recovery from the ‘Goals’ to evaluate the selected mitigation strategy. These states and activities on the top of the decision ladder deal with goal evaluation to choose a feasible chosen goal based on the perceived options and the desired goal’s quality, which requires rigorous cognitive load [31]. Thus, even though F.2 and F.7 do not have long steps in the decision ladder, their complexities are reflected in the inclusion of the ‘Goals’ state. However, we cannot apply the same analysis to F.10 and this shall be explained in the decision ladder model limitations.

Moreover, recalling the analysis in the FRAM model, F.2 and F.7 are the main decision functions. Our analysis shows that in the decision ladder model, these main decision functions are reflected in the inclusion of the ‘Goals’ state. However, an exception to this analysis is applied for ‘F.1 Secure power’, which also covers the ‘Goals’ state but neither main decision functions nor identified as high workload functions. The reason is that F.1 is an independent, yet important, task from the central tasks of severe accident mitigation (the ‘Goals’ in F.1 is to secure power and the ‘Chosen Goals’ is the selected power supply strategy).

(4) The ‘Execute’ activity of the decision ladder model. Our decision ladder model has three ‘execute’ activities. ‘F.1 Secure power’ is an independent and supporting function that has to be performed during severe accident management, thus it has to be executed. The other two functions, ‘F.9 Instruct for plant recovery measures’ and ‘F.11 Identify and evaluate the devices/facilities recovery measures’ are the two outcomes from considering the mitigation strategies, namely, choosing to perform the mitigation strategy (execute in F.9) or choosing not to perform the mitigation strategy and proceed with recovering the devices/facilities (execute in F.11). Through this analysis, our decision ladder model captures the key outcomes of severe accident mitigation, that is, to carry out a mitigation strategy or not.

(5) Linear progression without shortcuts. Our decision ladder model shows linear progression without shortcuts, even though shortcuts are supported and usually the source of insights in the analysis of decision-making. Shortcuts are taken by experts based on their domain-specific experiences [43]. Severe accidents in commercial NPPs took place three times and the causes of the accidents were all different. Thus, the assumption that the unfamiliar and infrequent events of severe accidents are outside of the operators’ expertise [27], however experienced they are in the NPP normal operations domain, is acceptable. The operators shall follow the linear information-processing steps upon performing severe accident mitigation.

(6) Decision ladder model limitations. The same limitation in the FRAM model resulting from following the content of SAMG strictly also applies to the decision ladder model. Function ‘F.10 Evaluate the results of mitigation strategy implementation’ is one of the evaluation functions identified in FRAM and it was analyzed to have a high cognitive workload. However, this high workload characteristic cannot be explicitly observed in the FRAM or decision ladder model. A possible approach to handle this limitation is to create a separate model, building up from the current SAMG-based model, to represent the hidden (not mentioned explicitly in SAMG) functions, functions’ aspects, and information-processing steps. This separate model shall be able to represent the cognitive load more transparently. For current study, however, we predict that the separate model may be unnecessarily complicated, reducing its usability in information requirements development. A further trade-off study shall be required.

3. Information Requirements Development

The term ‘information requirements’ in our study refers to the general sets of information that are required by the operators to carry out their tasks. Specifically, in the event of severe accidents, the operators need to get certain information to perform the mitigation strategies, these are the target information requirements developed throughout this study. Additionally, the information requirements discussed here have a broader scope than the information requirements that are often developed together with display requirements, namely, the information required to be displayed. Our proposed information requirements can contribute to the work domain in various forms, not only as an information item in a system display but also might be in the personnel knowledge through training programs, in the content of the guidelines, and so on.

Information requirements generation is an important process for designing not only the decision support displays but also for the overall decision support systems, or any complex system, especially at an early stage of development [34,35]. A systematic approach is required to ensure that all the required information items are considered and implemented efficiently to achieve the desired performance of productivity, efficiency, safety, and so on [34]. The quality of decision-making depends on the information available to the decision-makers [44]. Nevertheless, by simply presenting more information, the quality of decision-making does not necessarily improve [42]. The correct information required by the tasks or functions being currently carried out shall support efficient decision-making.

Information requirements table. We collected the information requirements by taking the functions’ aspects from the FRAM model and the states of knowledge from the decision ladder model. The information requirements are arranged in tabular form. Table 4 shows the information requirements related to the ‘F2 Perform control guideline (select mitigation strategy)’. Besides the basics of information requirements, we included ‘Knowledge type’ and ‘Information provider’ to support the DSS development. The information requirements table contains the following information:

• Function: the functions from the FRAM model;
• Information requirements: the information requirements for each function. An information requirement can be repeated for multiple functions;
• Information requirements source, ‘model’ column: FRAM or decision ladder (DL) model where the information requirements are acquired. The ‘details’ column contains which aspects of FRAM function or which state of knowledge of decision ladder the information requirements are obtained;
• Knowledge type: the knowledge type of the information requirement. We defined the knowledge type as follows: Plans, Goals, Possibilities, Means, History, Relations, Procedures, Variables, States, Criteria, and Environments. An information requirement may have a different knowledge type depending on the functions;
• Information provider: the assumed place where the operators can obtain the information requirements. We defined the information provider as follows: Self (knowledge), Communications, Display, Information support systems, and Guidelines and procedures.

Table 4. Information requirements related to ‘F.2 Perform control guideline (select mitigation strategy)’.

Function	Information Requirements	Information Requirements Source		Knowledge Type	Information Provider
		Model	Details
F.2 Perform control guideline (select mitigation strategy)	Severe accident response team is ready	FRAM	Input	Environments	Communications
	Decision whether to implement the strategy	FRAM	Input	History	Communications
		DL’	Alert
	Long-term monitoring variables	FRAM	Input	Variables	Information support systems
		DL’	Alert
	Selected mitigation strategy	FRAM	Output	Goals	Communications
		DL’	System state
	Information about power plant condition and variables	FRAM	Precondition	Variables	Information support systems
	Power plant’s operation mode	FRAM	Resource	States	Communications
		DL’	Information
	Severe accident’s entry conditions	DL	Alert	Criteria	Guidelines and procedures
	List of severe variables	DL	Information	Variables	Guidelines and procedures
	List of severe variables’ threshold	DL	Information	Criteria	Guidelines and procedures
	List of safety variables	DL	Information	Variables	Guidelines and procedures
	List of safety variables’ threshold	DL	Information	Criteria	Guidelines and procedures
	Power supply status	DL	Information	States	Information support systems
	Pressurizer manway status	DL	Information	States	Communications
	RV head status	DL	Information	States	Communications
	Severe accident mitigation control strategy	DL	System state	Plans	Guidelines and procedures

Table 4. Information requirements related to ‘F.2 Perform control guideline (select mitigation strategy)’.

Function	Information Requirements	Information Requirements Source		Knowledge Type	Information Provider
		Model	Details
F.2 Perform control guideline (select mitigation strategy)	Severe accident response team is ready	FRAM	Input	Environments	Communications
	Decision whether to implement the strategy	FRAM	Input	History	Communications
		DL’	Alert
	Long-term monitoring variables	FRAM	Input	Variables	Information support systems
		DL’	Alert
	Selected mitigation strategy	FRAM	Output	Goals	Communications
		DL’	System state
	Information about power plant condition and variables	FRAM	Precondition	Variables	Information support systems
	Power plant’s operation mode	FRAM	Resource	States	Communications
		DL’	Information
	Severe accident’s entry conditions	DL	Alert	Criteria	Guidelines and procedures
	List of severe variables	DL	Information	Variables	Guidelines and procedures
	List of severe variables’ threshold	DL	Information	Criteria	Guidelines and procedures
	List of safety variables	DL	Information	Variables	Guidelines and procedures
	List of safety variables’ threshold	DL	Information	Criteria	Guidelines and procedures
	Power supply status	DL	Information	States	Information support systems
	Pressurizer manway status	DL	Information	States	Communications
	RV head status	DL	Information	States	Communications
	Severe accident mitigation control strategy	DL	System state	Plans	Guidelines and procedures

Information requirements elicited from the FRAM model. In the following, we explain the information requirements of ‘F.2 Perform control guideline (select mitigation strategy)’ as a representative of our analysis method. Function F.2 is one of the key functions in severe accident management and it covers the observation of NPP parameters and the selection of a mitigation strategy based on predetermined conditions. From the FRAM model, we obtained 6 information requirements, and from the decision ladder model, we obtained 13 information requirements, where 4 of them are duplicated, leading to a total of 15 information requirements.

The six information requirements from the FRAM model consist of three Input aspects, one Output, one Precondition, and one Resource aspect. The Input aspect of FRAM activates the function or it is transformed to produce the output. The first Input, ‘Severe accident response team is ready’, acts as the initial Input that activates F.2 for the first time. This information item is categorized as ‘Environments’ in the knowledge type because the response team availability represents the surrounding situation of severe accident management effort. The readiness of the response team is assumed to be known via communications among personnel. The other two inputs, ‘Decision whether to implement the strategy’ and ‘Long-term monitoring variables’, activate F.2 again after certain decisions are taken. The ‘Decision whether to implement the strategy’ refers to one of these two decisions: to implement the mitigation strategy or not to implement it. The Input that activates F.2 is the decision not to implement the strategy. When the decision taken is to implement the strategy, the related functions are activated, until finally, ‘Long-term monitoring variables’ are created at the end of the strategy implementation and it activates F.2 again for another strategy selection, if necessary. The ‘Decision whether to implement the strategy’ is a ‘History’ (knowledge type) because it only informs of the decision not to implement the strategy and it is known via communications. The ‘Long-term monitoring variables’ is a ‘Variables’ (knowledge type) and its readings can be obtained from information support systems.

The Output aspect of FRAM is the result of the function. The F.2′s Output is the ‘Selected mitigation strategy’ that is passed to the next (downstream) functions. Although, after careful considerations, the operators may decide not to perform the selected mitigation strategy, they are first expected to perform the selected mitigation strategy. Thus, the ‘Selected mitigation strategy’ is categorized as ‘Goals’ (knowledge type) and it is known via communications. The Precondition of FRAM is the conditions that must be satisfied before the function can be performed. The F.2 has one Precondition: ‘Information about power plant condition and variables’. This information has to be provided before a mitigation strategy can be selected. The knowledge type of ‘Information about power plant condition and variables’ is ‘Variables’ and it can be obtained from ‘Information support systems’. The last F.2′s information requirement from the FRAM model comes from a Resource aspect, i.e., ‘Power plant’s operation mode’. The Resource aspect of FRAM is the item that is needed or consumed by the function when it is active. The ‘Power plant’s operation mode’ is needed to select the right mitigation strategy. The NPP of our study predefined six operation modes, coded using the alphabet A through F. The ‘Power plant’s operation mode’ is a type of ‘States’ (knowledge type), not simply ‘Variables’ because the modes’ definition contains multiple variables readings or conditions. This information is known via communications from the personnel who deduct the current operation mode based on the criteria.

Before we continue to analyze the information requirements extracted from the decision ladder model, we briefly recall the nature of FRAM and decision ladder analysis. As described earlier, FRAM and decision ladder complement each other by having different perspectives. FRAM is a type of system-based analysis that creates a model of the whole system, whereas the decision ladder is a type of task-based analysis that focuses on the current task. Thus, in the next analysis, the perspective is shifted to the current exact task, not the whole system, which may lead to a different set of information requirements.

Information requirements elicited from the decision ladder model. The decision ladder model yields 13 information requirements from 3 states of knowledge: Alert, Information, and System state. Alert state, the result of Activation activity, refers to the triggers of the need for action [42]. For F.2, the Alert state represents the times the operators feel the need to select a mitigation strategy. The decision ladder model identifies three information requirements related to the Alert state. The first event is when the NPP enters the predefined conditions of the severe accident, which may differ per power plant (for example, when the core exit temperature exceeds 650 °C (1200 °F)). This event is reflected in the information requirement ‘Severe accident’s entry conditions’, which is categorized as Criteria (knowledge type) and specified in the guidelines, such as the Emergency Operations Plan or SAMG. The other two triggers causing the operators to select a mitigation strategy are the same with FRAM analysis, which is after the previous instruction of mitigation strategy has been ended (either performed or canceled).

The Information state of the decision ladder provides the highest number of information requirements, that is eight requirements, as the result of the ‘Observe information/data’ activity that observes the environment for related data. For F.2, data observation aims to support the next ‘Identify state’ activity. During NPP severe accident mitigation efforts, the meaningful definition of power plant states is the progress of the mitigation control strategy, in other words, the current mitigation strategy being implemented. Thus, the Information state covers the information required to select a mitigation strategy, which is highly related to the NPP’s design and content of SAMG. In our reference SAMG, to select a mitigation strategy, the operators should monitor two sets of variables: severe variables and safety variables, against the predetermined thresholds for each variable. Hence, these four information requirements are identified: ‘List of severe variables’, ‘List of severe variables’ threshold’, ‘List of safety variables’, and ‘List of safety variables’ threshold’. The knowledge type for the two variables is Variables and for the two thresholds is Criteria. The Variables knowledge type represents the equipment readings that may change from time to time as observed by the operators, whereas Criteria is a fixed predetermined value that the operators compare the variables with. All four information requirements are provided by the guidelines.

Besides the severe and safety variables, the operators need other supporting information to perform F.2. This supporting information highly depends on the NPP design and the SAMG content. In our case, we identified four information requirements, as follows. Two information requirements are related to the power supply of the NPP, i.e., ‘Power supply status’ and ‘Power plant’s operation mode’. The ‘Power supply status’ informs the condition of the power supply to the plant (load, source, availability, stability, etc.), and this information is included to determine the ‘Power plant’s operation mode’. The knowledge type of both information is States. The ‘Power supply status’ is assumed to be observable via power supply-related information systems and the ‘Power plant’s operation mode’, the same one with FRAM’s Resource, can be obtained from Communications. The remaining two information requirements are related to the technical design of the NPP. Referring to our target NPP, these are ‘Pressurizer manway status’ and ‘Reactor vessel head status’, specifically, whether the pressurizer manway and reactor vessel head are opened or closed. Both information requirements’ knowledge type is States and acquired from Communications from the operators who inspect the equipment.

The last state of the decision ladder model for F.2 is the System state, which represents the current state of the system as the result of the Identify state activity. As the meaningful NPP state during severe accident mitigation efforts refers to the current mitigation strategy being implemented, the ‘Selected mitigation strategy’ is identified as an information requirement, identical to the FRAM’s Output. The mitigation strategy is selected among a set of mitigation strategies specified in ‘mitigation guidelines’ by following a predefined control workflow written in the ‘control guideline’. For example, our reference SAMG provides eight mitigation guidelines, containing one mitigation strategy for each guideline, and one control guideline (plus several supporting guidelines). The operators need the information on the ‘control guideline’ to select a mitigation strategy. We called this information requirement ‘Severe accident mitigation control strategy’ and categorized it as Plans (knowledge type) and can be obtained from the SAMG ‘control guideline’.

Comparison between the information requirements elicited from the FRAM model and decision ladder model. Two of the three F.2′s FRAM Input aspects are identical to the decision ladder’s Alert state and the remaining one that was not detected using the decision ladder is ‘Severe accident response team is ready’. In FRAM analysis, ‘Severe accident response team is ready’ is the event that activates F.2 because, in the event of a severe accident in the NPP, SAMG mandates the creation of new severe accident response teams and shifts the responsibility of managing the accident to the new teams. FRAM, being a system-based analysis method, can perceive this condition. As a task-based analysis method, the decision ladder is unable to identify the organizational factor. On the other hand, decision ladder analysis contributes the information requirement ‘Severe accident’s entry conditions’ as Alert that was not identified by FRAM. From the viewpoint of operators performing the task, they feel the need to start F.2 upon detecting severe accident symptoms. The ‘Severe accident’s entry conditions’ were not identified as FRAM Input because the severe accident entry condition by itself does not directly activate F.2 nor it is transformed to produce the Output: ‘Selected mitigation strategy’. In FRAM perspective, ‘Severe accident’s entry conditions’ is more suitable as a Precondition of a function ‘Request the creation of severe accident response team’, currently not modeled.

The FRAM Precondition and Resource aspects of F.2 are related to the Information state of the decision ladder. Information requirement ‘Power plant’s operation mode’ is identified in both FRAM and decision ladder analysis. Decision ladder analysis provided another seven information requirements in the Information state, including severe and safety variables, variables’ threshold, power supply status, and technical requirements. These information requirements were able to be detected using the decision ladder because, in task-based analysis, they are directly required by the operators performing the task, as specified in SAMG. FRAM could not identify those detailed information requirements, however, FRAM Precondition is listed as ‘Information about power plant condition and variables’. We can assume that the seven information requirements detected by the decision ladder are covered in the FRAM Precondition’s term. However, this assumption is not guaranteed because from a systemic viewpoint, the operators might require other information outside of the seven information requirements. In short, the scope of the FRAM Precondition is larger than the decision ladder’s Information state. Therefore, we left the ‘Information about power plant condition and variables’ as a separate information requirement. This decision causes different granularity in the information requirements, however, for the current study, we prefer to maintain the granularity of the FRAM model. We plan to specify the information requirements to the level of granularity similar to the technical items (‘Pressurizer manway status’ and ‘RV head status’) for the modeling of the specific mitigation strategy.

Both models agreed that the result of function F.2 is the ‘Selected mitigation strategy’, as shown by FRAM’s Output and decision ladder’s final state for F.2, System state. The decision ladder has another System state, namely ‘Severe accident mitigation control strategy’. For the operators to be able to select a mitigation strategy, they have to know the criteria of each strategy selection, which is represented in the mitigation control strategy. The ‘Severe accident mitigation control strategy’ can be included as a control aspect in the FRAM model. However, from the FRAM’s modeling scope, adding this item as a Control aspect requires the creation of a new function because the Control aspect coming into F.2 should be an Output of a function (for example, the function name could be: ‘Provide mitigation control strategy’, which may further create the need of ‘Develop mitigation control strategy’). This new function currently does not align with the content of SAMG.

Summary. We described our analysis method of eliciting information requirements using FRAM and decision ladder models by explaining the F.2′s information requirements elicitation process in detail. We also showed how FRAM and decision ladder complement each other. While a part of the information requirements is identified by both models, some of them are only identified using FRAM’s system-based analysis or the decision ladder’s task-based analysis. By combining both models, we can develop a comprehensive set of information requirements for severe accident management in NPPs based on SAMG.

In total, we developed 57 information requirements from 14 functions: 21 from the FRAM model and 36 from the decision ladder model (duplicates removed). However, since the information requirements’ granularity levels are varied, the number of information requirements means less than our efforts to improve the requirements’ comprehensiveness by implementing two complementary approaches. At our current stage of the study, we do not perceive the effectiveness of maintaining the same level of granularity for information requirements because the scope of modeling is the entire severe accident mitigation (in this scope, the suitable granularity should be coarse level, but to include the contents of SAMG, we include some finer level of granularity). When we proceed to the analysis of each mitigation strategy, we can decide on a common level of information granularity.

4. Concluding Remarks

Through this research, we developed a set of information requirements for a decision support system (DSS) to manage severe accidents in NPPs. The information requirements identified here were intended as the first step of a DSS development. Although the design and development of the DSS are currently out of research scope, we presented some ideas to integrate and apply our findings. We observed four application methods, categorized in

Table 5. Information requirements application methods.

	For Information System-Based DSS	Otherwise
Relatively easy and quick	Method 1. Tweak the existing information system-based DSS, especially focusing on the display of information	Method 3. Gather the findings, especially the new ones, and compose them as a guidance document
Require longer planning and execution	Method 2. Create a new information system-based DSS that incorporates the complete set of information requirements	Method 4. Elaborate on the information requirements, especially the knowledge type, and create a training program

. These application methods can also be considered as the means to reduce the gap between work-as-imagined and work-as-done, which ultimately could affect system safety [29].

The dangerous consequences of a severe accident in NPPs prompt the expectation of swift and effective mitigation efforts. The operators are required to perform the mitigation tasks under time stress and uncertainty, leading to high cognitive load and physical fatigue. A set of Severe Accident Management Guidelines (SAMG) is followed for mitigating severe accidents. However, SAMG is usually provided in the form of documents and its content requires frequent and critical decision-making by the operators, creating the need for a decision support system (DSS) to alleviate the cognitive load and reduce the probability of human error. In this study, we aimed to develop the information requirements as a starting and important step of a DSS design.

Our study is the first attempt to develop requirements by combining the Functional Resonance Analysis Method (FRAM) and decision ladder approaches. Through both FRAM and decision ladder modeling, we covered both systemic and human decision-making perspectives, enabling the elicitation of a comprehensive set of information requirements. FRAM and decision ladder also complement each other in a similar way a system-based analysis complements a task-based analysis. By referring to an actual SAMG, our models capture the real situation of severe accident management, however, this also causes limitations. We explained our approach to extracting the information requirements from FRAM and the decision ladder in detail by presenting an example from a representative function. In the future, firstly, we plan to perform models verification and validation from the experts in the field of NPP severe accidents. Secondly, since the information requirements elicitation performed in this study is a part of a DSS development project, we plan to assist in the development of a DSS for managing severe accidents in NPPs. This may require additional efforts, such as keeping the same level of granularity and prioritization of information requirements.