Team-Communication Modeling Framework for Multi-Unit Nuclear Power Plant Accident Analysis

Featured Application

The modeling framework approach can be applied to analyze team communication in sociotechnical systems, and the modeling insights can be applied to improve the development of accident-training scenarios and task procedures/guidelines, the provision of required system/facility/tools, and the development of accident-management support systems in nuclear power plants.

Abstract

A multi-unit nuclear accident is an accident that damages the nuclear core and occurs in multiple units simultaneously in a nuclear power plant. Its massive consequences have triggered extensive studies on accident prevention and mitigation. In this study, we are interested in the emergency-response teams involved in multi-unit accident management. Multiple emergency-response teams need to interact with each other during multi-unit accident-management tasks, and the basis of team interactions is communication. Thus, we propose a team-communication modeling framework consisting of three models, i.e., a team-communication investigation model, process model, and performance-factor model. The methods used to develop each model are described. Also, an analysis methodology is provided to guide the application of the modeling framework, and a case study based on a multi-unit accident scenario is performed to confirm the feasibility of our study. The final results of the case study are four specialized models developed by applying the functional resonance analysis method (FRAM), each covering a specific scope of the accident scenario, with the functions and aspects elaborated to support team-communication analysis. Modeling insights are collected and can be applied to improve accident-training scenarios, procedure/guideline development, and accident-management support systems.

1. Introduction

In the nuclear industry, an accident is called a severe accident when the damage degrades the nuclear core [1], which is in the reactor building. The reactor building is also called a reactor unit, and one nuclear power plant site can contain multiple reactor units. When severe accidents happen simultaneously in more than one unit, it is called a multi-unit accident. The risk of a multi-unit accident was mentioned as early as the 1980s; however, it has not received enough attention because of its extremely low occurrence probability [2,3]. Following each occurrence of a severe accident (the Three Mile Island accident and the Chernobyl accident), more safety measures are taken. After the Chernobyl accident, severe accidents in large nuclear power plants (NPPs) did not occur for almost 25 years, i.e., the Fukushima Daichi accident in 2011. However, the Fukushima accident was not only severe; it was also the first multi-unit accident, where four of the six units encountered a nuclear core meltdown [3]. Multi-unit accidents carry higher consequences in health and economy compared to a single-unit accident, as well as more difficult accident mitigation [4]. The massive consequences of the Fukushima accident caused safety measures to prevent a multi-unit accident to be eagerly revisited since more than 70% of nuclear power plant sites contain more than one unit [5]. Likewise happened in South Korea, where this research was conducted, and which has the highest density of NPPs—up to 8 units per site [2].

To include the concern of multi-unit accidents in nuclear safety analysis, the International Atomic Energy Agency has developed a multi-unit probabilistic safety assessment (PSA) methodology by building on the single-unit PSA [6]. It has provided the technical assumptions, started with the single-unit PSA, proceeded to the initiating event analysis (the triggers of severe accidents) and the multi-unit analysis, such as the multi-unit accident sequence model, multi-unit system analysis model, etc., and ended with the results integration/interpretation of the quantification of multi-unit core-damage sequences. Shifting the focus away from the quantification of multi-unit risk, the multi-unit risk assessment aimed to provide insights into reducing risk through accident-management programs [3]. It identified many technical issues and challenges of risk assessment of multi-unit accidents. Other methods were also proposed [2,5,7]. Despite the various technical solutions proposed to include and reduce the risk of multi-unit accidents, a study analyzing the past three severe accidents found that their root causes lay in the non-technical aspects, namely the poor safety management and poor safety culture [8].

The importance of non-technical aspects has been acknowledged, especially in organizations dealing with high-risk emergencies, such as NPP emergency-response teams (ERTs) [9,10]. In the case of multi-unit accidents, the most critical factors were the reactor unit locations and the shared safety features between units, and the most common shared feature between reactor units was the organizational aspects, which comprised 44% of the inter-unit dependencies [3]. A significant element of the organizational aspect is operators’ non-technical skills (NTSs). Among the non-technical skills, the importance of communication has been emphasized in the reports of major NPP accidents since the 1980s, and the Fukushima accident study also concluded that the reduced communication capability seriously hindered the accident responses, which amplified the accident consequences [11]. Thus, in this study, we focused on team communication, as it is also the first principle of effective emergency response.

2. Methods and Data

2.1. Background and Related Works

Especially in countries with multiple reactor units per NPP site, multi-unit accidents have been under intense study since the Fukushima accident proved its possibility and massive consequences [12]. A descriptive study was carried out by interviewing the employees who were directly involved in the accident, and five multi-unit risk factors were identified [11]. Although this study’s results were highly specific to the Fukushima NPP design and accident characteristics, the insights can be generalized for other NPPs. Also, the suggestions pointed at both technical and non-technical aspects, such as maintaining operator knowledge, personnel planning, training personnel, improving communication capabilities, planning for emergencies, etc. We found that 13 of the 29 suggested activities were non-technical. Another study analyzing the three severe accidents found that, although the causes of accidents and accident sequences were different, the root causes were in the “system deficiencies indicative of poor safety management and poor safety culture” [8]. Thus, the non-technical aspects are as important as the technical ones in multi-unit NPP accidents.

A part of the non-technical aspects mentioned above can be categorized as the non-technical skills (NTS) of the operators. The significance of operator NTS has been mentioned for at least 20 years [10]. Especially in high-risk domains such as NPP, safe accident countermeasures are very dependent on the NTS of the operators. Failures of NTS were reported to be the causes of most of the aviation, medical, and industrial accidents [13]. Likewise, in the nuclear industry, the lack of NTS contributed to most accidents, either directly or indirectly [14].

The skills listed as NTS varied between studies; however, the following skills were included most of the time: situation awareness, leadership, teamwork, and communication [10,15,16]. Various recent studies have reported the significance of NTS [14,17,18,19]. In multi-unit accidents, one of the two most critical factors was the shared safety features between units, and the most common shared feature was the organizational aspects [3]. Another study classified the risks of multi-unit NPP into six classes, and two of them were human and organizational dependencies [20]. For organizations to perform safely during emergencies, accurate communications must be guaranteed. In the Fukushima accident, reduced communication seriously hindered the accident response, which amplified the accident consequences [11]. The failures in communication were reported to be responsible for nearly 60% of mistakes in safety-critical domains [16]. Especially in emergency response, there were times when the interactions between team members were more important than their domain knowledge [16]. Thus, communication is of the utmost importance; there is no alternative to safety management, and it is the basis of operator interactions [14].

In this study, we focused on the team communication of NPPs’ emergency-response teams (ERTs) during emergencies since multiple teams must cooperate and the possibility for poor team performance is particularly high during stressful situations [21]. The necessity to investigate communication under a stressful environment such as an accident is also mentioned in other studies [21,22,23]. Moreover, even highly trained teams were found to function ineffectively, with significant variability in their performance during emergencies [24]. Effective communication was first mentioned as the first principle of effective emergency response in 1990 [10].

In the nuclear industry, the concerns of verbal communication during accidents have been raised since the 1990s [25,26]. When a control room is modified, its impact on team communication is analyzed [27]. However, communication failures and the accidents caused by them were still reported and unresolved as recently as 2020 [17,28]. In our previous study, we collected the influencing factors of team communications in NPPs’ emergencies and organized them into five elements; these elements and the relationships between them formed our preliminary team-communication model [29].

While several studies proposed teamwork-related models in NPP, we found limited works proposing a team-communication model in particular. An analytic framework for communication called the H-H-S framework was proposed [30]. However, its main focus was to support the operators in adapting to the human–machine interfaces in the advanced NPP control room. One of the early works on operator performance models classified the performance-influencing factors into four groups—human, system, task, and environment—in which team communication was included in the environment group [31]. A team-interaction model was proposed by [32], in which “the team-interaction relationships are constituted by the communication between team members”, and a team-process model to evaluate performance was adopted [33], consisting of input, team process (cooperation, information exchanges, communication, etc.), and output. Recent studies proposed conceptual models for team situation awareness [34] and team decision-making [35]; the former was a causal model, whereas the latter divided the model elements into input, process, and output of team decision-making. These NPP team- and performance-related modeling studies showed that the efforts had become more elaborated, from simply listing the influencing factors and classifying them in exclusive groups to considering the relationships between factors as causal or the input–process–output of performance. Various approaches to team communication in the NPP were studied [29].

2.2. Research Methods

Upon scrutinizing the existing team-communication studies, we realized that there is a need to examine team communication in NPP from multiple perspectives. Thus, we decided to explore NPP team communication from three perspectives. The first one is the team-communication influencing factors of listing and categorization [29]. The second is the team-communication process, consisting of input, output, and communication functions, and the third is the team-communication outcome. To the best of our knowledge, our proposed team-communication analysis framework for NPP covering these three perspectives is the first of its kind. While including the three perspectives in our framework improves its comprehensiveness, we also realized that we need to expand our references into the general system models, especially the ones that consider human workers, their interaction, and work in a systemic approach.

Various models to describe human workers and their interactions in sociotechnical systems have been proposed, such as the Input–Process–Output framework, Input–Mediator–Outcome input framework [19], the work-system framework [36], the systems-engineering initiative for patient safety model [37], and so on [38,39]. Among these models, we are particularly interested in the systems-engineering initiative for patient safety (SEIPS) model, which was developed to understand the structure, processes, and outcomes in healthcare. SEIPS was upgraded to SEIPS 2.0 and SEIPS 3.0, and recently, a practice-oriented SEIPS model was also provided [40,41,42]. It became our reference model because of its comprehensiveness, steady improvement, and interest until recently. However, our proposed modeling framework refined the SEIPS model (hereafter the reference model) in several major ways, as presented in Section 3.4.

2.3. Research Data

We incorporated different types of data for the development and evaluation of the team-communication models. For the investigation model, the team-communication influencing factors were collected from a vast literature repository using a combined method of systematic literature review and text mining, as reported in our previous study [29]. Those influencing factors are considered together with the resilience engineering principles, reflected in the six aspects of the function in the functional resonance analysis method (FRAM) [43], to develop the performance-factor model. Lastly, the process model is mainly an application of FRAM for team communication during an NPP multi-unit accident. Thus, we refined the multi-unit accident scenarios from subject-matter experts and created a case study of the process model to evaluate its feasibility.

3. Results and Analysis

The proposed team-communication modeling framework consists of three models: the team-communication investigation model, the team-communication process model, and the team-communication performance-factor model.

3.1. Team-Communication Investigation Model

The investigation model aims to identify all the influencing factors of intra- and inter-team communication. We developed this model by collecting the factors influencing team communication through a systematic survey combined with text mining. In total, we identified 223 influencing factors distributed across five elements: individual, team, communication, NPP tasks, and external elements. The details of the model and its development methodology were reported in our previous study [29]. The investigation model is comparable with the work system of the SEIPS model (hereafter, the reference model). Since our research is about team communication, we created a team element and a communication element, to replace the organization and technologies and tools components in the reference model. We identified more comprehensive influencing factors for a specific application domain. The application scenarios of this model are to be used as references for human reliability analysis (in a general approach, compared to the specific approach of the performance-factor model), FRAM variability analysis, and team/organization performance research [9,13,16].

3.2. Team-Communication Process Model

While the investigation model contains all the factors influencing team communication, there is no description of the occurrences or the ways communications take place. Team communication is an information exchange process between at least one sender to one receiver, regardless of the medium [9], and it is performed to properly accomplish tasks [15]. Thus, we created the process model to represent the information exchange between teams of NPP operators in performing multi-unit accident-management tasks. Ideally, this model will contain the whole team-communication process of multi-unit accident management; however, since we aim to analyze the intra- and inter-communication of the operators, the information of interest is very detailed (request, report, order, etc.), thus modeling the entire accident-management tasks was highly complicated and ineffective. Instead, we performed a task analysis and divided the model into several levels, as will be explained with examples in the case study.

We decided to develop the process model in the form of a functional resonance analysis method (FRAM) model [43]. FRAM is a system-modeling method that has gained high interest, especially in the field of accident modeling [44,45]. In this method, the target system or work domain is represented through functions that are linked to each other via the function’s six aspects, i.e., Input, Time, Precondition, Control, Resources, and Output. We chose FRAM since it was developed by considering the principles of resilience engineering, namely the equivalence of failures and successes, the approximate adjustments, emergence, and resonance. Resiliency is the ability to handle unexpected situations safely. Thus, NPP operators must be equipped with high resiliency during accident management [46]. Also, FRAM accommodates a high degree of freedom in the modeling process. There is no predefined sequence of the functions in the FRAM meta-model level; the sequence of functions is defined in the instantiations of the model. There is also no limitation on the number of items for each aspect, and, using a software called the FRAM model visualizer Version 3.1.0, there is no constraint on the placement of the functions [47]. We found this modeling freedom to be beneficial to model team communication because we can capture the high number of possibilities in both communication flow (e.g., the same content can be sent to multiple receivers) and items of information exchanges (request, report, order, etc.).

The reference model (SEIPS) also has a work process, which was elaborated to cover physical, cognitive, and social/behavioral performance processes and was the center of its latest improvement, SEIPS 3.0, showing the importance of a process analysis [41]. This work process is comparable to our team-communication process model; however, while we opted to apply a specific modeling method, i.e., FRAM, the reference model did not; it merely provided guidance tools such as a journey map and systems story. Since our research domain is specific, we were able to specify a modeling method and the modeling hierarchy, which improves the applicability of the team-communication process model.

As a type of FRAM, the process model covers its application scenarios, namely retrospective analysis (accident analysis) and prospective analysis (risk assessment) [44]. Application of the process model as an accident analysis can guide the analyst to find problematic team communication, such as incorrect content, off timing, and unsuitable communication methods. For risk assessment, the insights extracted from the analysis of the process model offer safety improvement insights.

3.3. Team-Communication Performance-Factor Model

This model contains the factors influencing the performance of team communication in a certain accident/risk assessment scenario (which is comparable to the performance-influencing factors in [31]). It consists of standard performance factors derived from the model, which we developed by referring to FRAM modeling principles, and it may refer to the complete set of influencing factors from the investigation model when needed.

Since we decided to aim for resiliency by implementing FRAM, we developed the performance-factor model by following its concept of variability [43]. In FRAM, there are three types of variabilities: internal, external, and the coupling variability resulting from the upstream functions’ Output received through Input, Precondition, Resource, Control, and/or Time aspects. (In the FRAM instantiation model, the preceding function is called the upstream function, i.e., the function that provides Output, and the latter function is called the downstream function, i.e., the function that receives the Output from the upstream function as Input, Precondition, Resource, Control, or Time. In the FRAM general/meta-model, there is no sequence. Thus, there is no upstream or downstream function). We applied this variability concept to develop the team-communication performance-factor model by considering each type of variability as the standard set of performance factors, namely the factors that are almost always present to influence the team-communication performance. Thus, we identified the internal, external, and coupling factors, which were defined in terms of input, precondition, resource, control, and time factors, by following the definition of Input, Precondition, Resource, Control, and Time aspects of FRAM.

Table 1. The performance factors from the team-communication performance-factor model.

Reference to FRAM’s Variability Concept	Category	No.	Performance Factors
Internal variability	Internal factors	1	Work experience
		2	Level of stress
		3	Level of principal knowledge
		4	Level of procedural knowledge
		5	Level of non-technical skills
External variability	External factors	6	Physical work environment
		7	Education and training level
		8	Member familiarity with the team
		9	Leader’s leadership
		10	The quality of the human–machine interface of the task support system
		11	Guidelines related to communication
Coupling variability	Input factors	12	Communication message complexity
		13	Communication message accuracy
		14	Communication message delivery timing
	Time factors	15	Time allowed for communication (duration)
		16	Predefined sequences to process the message
		17	Time required to process the message
		18	Time duration required to maintain the message
	Control factors	19	Protocol required to transmit the message
		20	Message processing guidelines
		21	Regulations regarding communication
	Precondition factors	22	Required condition to process the message
		23	Team member role definition related to communication
		24	Permission required to process the message
	Resource factors	25	Media and tool to receive and send messages
		26	Required knowledge to understand the message
		27	Reference material to process ambiguous message
		28	Support from other team members

listed the 28 performance factors, their categorization, and references to the original FRAM’s concept of variability, as described in the FRAM guidelines.

This model is comparable to the reference model (SEIPS) work outcomes, which consist of employee and organizational outcomes and patient outcomes. In our research, the direct outcome of team communication is the communication/information exchanges between team members; however, it is more useful to examine the performance of the communication rather than the exact utterances. The communication performance differs for each occasion. Thus, we decided to identify the factors influencing the performance using a model-based approach. The reference model also listed the performance factors/elements of its work outcomes; however, we developed our performance factors by applying the resilience engineering concepts that were incorporated in the FRAM modeling principles [43].

The main application scenario of the performance-factor model is the human reliability analysis (HRA), a safety assessment in the nuclear industry. The performance factors in this model can be applied as the performance-influencing factors that are included as contributors to unsafe human actions [31].

3.4. Comparison to the Reference Model

In summary, although the three models and their characteristics were influenced by the reference model (SEIPS) [37,40,41], our proposed team-communication modeling framework is different from and refines the reference model in several major ways.

First, our modeling framework is developed to be applied during multi-unit NPP accident management, which makes the application domain-specific and the research outcomes practical. On the other hand, a drawback might be that the outcomes were highly domain- and situation-specific; however, in NPP operation, the significance of team-communication analysis and support is particularly needed during accident management [21,30]. Our research approach can be adapted to other domains requiring communication analysis.

Second, the influencing factors contained in the investigation model were collected from a combined systematic literature review and text mining. Thus, they are comprehensive and reliable [29]. The process model was developed using FRAM, which is a modeling method and contains the concepts of resilience engineering [43]. We also designed a methodology to apply FRAM for communication analysis. The performance factors in the performance-factor model were developed by referring to FRAM principles, which served as its scientific basis.

Also, the reference model was refined twice and supplemented with seven tools [42]; however, while the tools were useful, an overall methodology to apply the model was not evidently provided. This might be caused by the model’s broad analysis scope. We developed our models to analyze team communication during multi-unit nuclear accident management. This specification made us able to define the analysis methodology using the modeling framework. In summary, the three team-communication models, their relationships in the framework, and the team-communication analysis methodology support the practicality of our research results.

3.5. The Relationships of the Models

The relationships of the three team-communication models are illustrated in Figure 1. The investigation model provides analysis requirements to the process model and the full set of influencing factors to the performance-factor model. The process model receives the analysis requirements from the investigation model and uses them to refine the functions’ aspects to ensure the comprehensiveness of the communication analysis. It provides the performance-factor model with the basis of the selection of performance factors from the full set of influencing factors to analyze the performance of an accident scenario. Then, it receives back the suitable performance factors to perform a team-communication analysis.

The performance-factor model receives the complete set of communication influencing factors from the investigation model and combines them with its standard performance factors. Next, the suitable performance factors can be selected based on the basis given by the process model that specifies a certain accident scenario. The selected performance factors are then returned to the process model to be used to perform communication analysis.

While the investigation and performance-factor model can be updated, they are generally static and act as influencing/performance factors providers to the process model. The process model is the main part of team-communication analysis, and it is developed based on FRAM, with modifications and additions to suit the communication analysis.

3.6. Team-Communication Analysis Methodology

At the center of our team-communication analysis is the process model using FRAM. A systematic review paper in 2020 listed many applications of FRAM; however, among the 193 studies, there was only one that involved communication in the analysis method [44]. That study proposed to include communication as the seventh aspect of FRAM function, and although we agreed on the importance of communication and appreciated the novel approach, the addition of a new aspect is a major modification to the method and should thus be supported with deep understanding of FRAM’s and resilience engineering’s theoretical foundation and strong scientific background, which the study failed to report [48]. We found that there are two general approaches to include the analysis of communication in FRAM. The first one was, during the function identification, when a certain communication was considered a required function, it was included as a function and analyzed in the same way as other functions. For example, a study on the safety of offshore platforms created such communication-related functions [49]. Another approach was the application of the so-called “common performance conditions” during variability characterization, which listed “communication quality” as one of its 11 conditions [50].

As illustrated in Figure 2, the proposed team-communication analysis methodology using the modeling framework consists of three steps: (1) FRAM modeling of multi-unit accident-management tasks, (2) communication functions identification, and (3) team-communication analysis.

The methodology starts with the FRAM modeling of multi-unit accident-management tasks, i.e., FRAM’s basic application of function analysis and characterization. The result is a FRAM model containing functions during multi-unit accident management and connections between functions through the six aspects. As there are many functions during multi-unit accident-management tasks, this initial “FRAM model” will contain a lot of functions and aspects. Although completely covering the accident scenario, we found this model to be overly complicated and impractical. Thus, we decided to generalize the functions, creating a “generalized FRAM model”. Then, since the goal is to analyze team communication, which is fine-grained information, either the analysis scope should be redefined/narrowed, or the model should be divided. We decided to redefine the scope and select the target functions to be analyzed. A detailed model, called the “specialized FRAM model”, is created. These three types of FRAM models create a three-level modeling abstraction. Assignments of function performer and output variability in terms of time and precision are carried out by following the FRAM guidelines [43].

In the identification of communication functions, to ensure consistent identification, the following conditions are applied. (1) A function is a communication function if it is either an intra- or inter-communication function. (2) An intra-communication function is decided for each function by deciding whether communication is explicitly required in performing that function. For example, a function discussing the need for equipment is an intra-communication function, whereas the operator’s movement to the desired location is not. (3) An inter-communication function is decided for a pair of functions (two connected functions) by deciding whether communication is explicitly required in performing both functions. For example, a pair of functions where one sends a request and the other receives/processes it is an inter-communication function, whereas a pair of functions where one purchases equipment and another stores it is not an inter-communication function. Based on these conditions, the communication functions are identified.

For team-communication analysis, the aspects of the communication functions are refined by considering the performance factors from the performance-factor models. Then, for variability analysis, we modified the original simple version of the FRAM analysis by taking into account the nature of communication. We decided that the ultimate goal of team communication is to deliver the right information in the right way at the right time. The “right information” requirement leads to a new content variability, the “right way” requirement changes the definition of the existing precision variability, and the “right time” requirement is identical to the existing time variability. The time variability is manifested into too early, on time, too late, and not at all; the precision variability is manifested into precise, acceptable, and imprecise; and the newly added content variability is manifested into relevant, correct, irrelevant, and none. Figure 3 illustrates the addition to the original FRAM variability analysis.

3.7. Case Study

The team-communication modeling framework and analysis methodology are developed to be applied to multi-unit NPP accident management. To evaluate their feasibility and functionality, we consulted with five subject-matter experts (a nuclear engineering professor, a nuclear industry project leader, and three senior researchers in the nuclear science research center) and obtained two multi-unit accident scenarios. We also analyzed the materials (local nuclear industry meeting presentations, local research papers, and reports) on multi-unit accident management in South Korea to complement the information on the accident scenarios, and we justified our modeling decisions (such as the decision to focus on mobile equipment modeling) to the experts. In this paper, due to content limitation, we reported one multi-unit accident scenario and our FRAM model development.

3.7.1. Background Information

Some background information is needed to increase the readability of the accident scenario and the FRAM-based process model. We briefly described the emergency-response teams and the emergency mobile equipment as follows.

The NPP operation in South Korea is divided per reactor unit [46,51,52]. One reactor unit is operated by one team called the main control room (MCR) team, consisting of the leader, shift supervisor, and four members: a reactor operator, a turbine operator, an electrical operator, and a shift technical advisor. MCR may request support from field operators (FO). Upon emergencies, MCR requests the creation of emergency-response teams (ERTs) at the safety center (SC). The ERTs consist of an operating support center (OSC), a technical support center (TSC), and an emergency operation facility (EOF). The ERTs are active when the team leader is present. The characteristics of the ERTs are as follows (we provided the ERT descriptions based on the latest obtainable information; however, these descriptions might change as the accident-management plan is updated from time to time).

An operating support center (OSC) covers one NPP site. It performs emergency maintenance, material acquisition, fire extinguishment, and personnel rescue. By default, OSC takes orders from TSC. When TSC is not yet active, it may take orders from EOF or decide by itself or by discussions with MCR and SC. Fire extinguishing and rescue tasks require OSC to interact with multiple teams, such as the medical team, field operators, and the local fire department. A technical support center (TSC) is responsible for one reactor unit and one dedicated TSC for one MCR. TSC takes the decision-making authority from MCR and hands it over to EOF when EOF is active. If EOF is not assembled or not yet active, TSC receives the requests from MCR, analyzes them, decides and orders countermeasures back to MCR or OSC/SC, and then updates the plant status to the public. When EOF is active, TSC recommends countermeasures to EOF to support EOF decision-making. By default, TSC relays the EOF decisions to other teams since EOF has a large work scope. Besides that, TSC performs radioactive analysis, distributes protective equipment to the personnel in the field, restricts access to dangerous areas, and orders radiation decontamination tasks to field operators. An emergency operation facility (EOF) covers one NPP site and it is located outside of the site (off-site). EOF holds the highest authority upon activation, and it is responsible for returning the NPP to safety. Critical decisions such as emergency-phase selection, habitability evaluation, resident evacuation, medical support, information sharing with the media, and personnel management are taken by the EOF. It receives status updates from TSC by default and orders accident countermeasures such as the deployment of mobile equipment. It may interact with all internal emergency-response teams as well as external organizations and communities. It interacts with NPPs in other locations to request support. In general, EOF is the contact point for external interactions.

The Fukushima accident brought new concerns to the safety regulations of the nuclear industry; thus, countermeasures were prepared [53]. One of them is the multi-barrier accident coping strategy (MACST) developed in South Korea, in accordance with the United States’ “Diverse and Flexible Coping Strategy”, which aims to prevent and mitigate nuclear core damage by implementing multiple fixed and mobile equipment to recover/maintain power supply, restore the safety functions (core cooling), and complete the safe shut-down of the plant. MACST contains three phases, starting from Phase 1 to Phase 3, and mobile equipment can be requested when Phase 2 starts. The major pieces of mobile equipment used in Phase 2 are a 1 MW mobile generator, high-pressure mobile pump, and low-pressure mobile pump; in Phase 3, they are a 3.2 MW mobile generator and high-flow-rate sea-water pump. A study reported the development status of the MACST operating guidelines, which consist of 14 guidelines, while details on MACST and its operations were being determined and tested for feasibility [54,55,56]. However, the task flow of deploying the mobile equipment (which should be different per equipment type) was not yet determined nor reported in official information. Through discussions with subject-matter experts, we were able to obtain the estimated task flow of mobile equipment deployment, and we referred to that information to create the FRAM-based process model. For example, the mobile equipment driver moves the equipment to the required location, the OSC operators prepare and install it, and the FO operates it. However, this task flow and the performers might be updated in the future.

3.7.2. The Multi-Unit Accident Scenario

During our research project, a group of NPP accident prevention experts developed a few multi-unit accident scenarios and using those scenarios, we were able to test the feasibility of our modeling framework and methodology. We selected one scenario to be the case study in this paper; however, we are unauthorized to disclose the full details.

Thus, we describe the accident scenario based on its main events, as follows. A certain NPP has six reactors. Due to an earthquake of 0.3 G scale, the power supply to all reactors is lost. The automatic shut-down and power loss are confirmed; an accident type called “loss of off-site power/LOOP” is decided. The operational status of some emergency power supply equipment (emergency diesel generator, turbine-driven auxiliary feed-water pump, etc.) is checked. Part of the equipment appears to be not working, and field operators are sent to operate them on site. MCR starts the procedure to diagnose the accident and, upon finding that all AC power sources are lost, proceed to the indicated emergency procedure. Countermeasures, such as opening dump valves, are taken. Reports from the field operators are received, which mention that the power generators are not operable. The accident has entered a prolonged power loss state, and it is decided to be a type called “extended loss of AC power/ELAP”. MCR follows the corresponding accident guideline to stop unnecessary power load requests for multiple pieces of mobile equipment to the SC, which receives the requests and calls the drivers located outside the site. The drivers arrive at the mobile equipment storage and prepare and drive them to the installation location. SC checks the road for damages and starts removing the debris. TSC is active and oversees the mobile equipment assignments. OSC is active and assigns members to move to mobile equipment installation locations and prepares for installation. EOF is active and takes over the mobile equipment assignments. TSC requests additional mobile equipment for EOF. EOF requests additional mobile equipment to other NPP sites, through SC. SC reports that the other NPP sites agree to send the equipment and EOF assigns the mobile equipment for the whole site. MCR stops the unnecessary load; however, the nuclear core temperature reaches 649 °C, which is an entry condition to severe accident-management guidelines. While MCR is following the guidelines, mobile equipment arrives (driven by SC drivers) and is installed (with the help of OSC), with permissions from TSC, who acquired the assignments from EOF. Mobile equipment from other NPP sites arrives and is received by SC drivers, who take them to the installation location. The operation of the mobile equipment (by field operators) is successful, the power supply is recovered, and the core cooling is ongoing. The situation is stable, and the accident scenario is finished.

3.7.3. The Application of Team-Communication Modeling Framework

Among the three models in the framework, two of them, the team-communication investigation model and the performance-factor model, are mostly static, and the remaining process model is dynamic, which represents the specific communication process of an NPP emergency. Although the three models interact (Figure 1), the investigation model and performance-factor model mainly provide input to the process model as influencing and performance factors, respectively (the feedback loops were created to maintain consistency in case the process model contains new influencing/performance factors). The three model concepts were developed at the same time; however, the contents of the investigation model were developed first [29] and followed by the contents of the performance-factor model (Table 1). The contents of the process model depend on the communication activities, which depend on an accident scenario. Thus, the accident scenario described above mainly affects the FRAM-based team-communication process model. We applied the three-step team-communication analysis methodology described in Section 3.6 as follows.

The first analysis, FRAM modeling of multi-unit accident-management tasks, consists of the following:

• Initial FRAM model development
• Generalized FRAM model development (and definition of analysis scope)
• Specialized FRAM model(s) development
• Function performer and variability assignments

The initial FRAM model covers the entire multi-unit accident scenario. We identified the functions and connected them using the functions aspects (Input, Time, Precondition, Control, Resources, and Output) and specified their performers (whenever possible). Basically, we performed the function identification by following the FRAM guidelines [43]. Modeling the entire accident scenario led to a model with many interconnected functions; this model ended up with 79 functions. Although comprehensive, this model was overly complicated and impractical. The initial FRAM model is generalized in the next analysis.

The generalized FRAM model is a compact version of the initial FRAM model but still covers the entire accident scenario. We performed generalization by combining two or more functions into one when (1) the nature of the functions was similar, and they were performed by the same performer/ERT, or (2) the flow of functions indicated an integrated goal. For example, functions “Announce emergency code white”, “Announce emergency code blue”, and “Announce emergency code red” were performed by MCR, and they were combined into a function named “Announce emergency code: white/blue/red”. Multiple functions related to the 1 MW mobile generator were combined into a function named “Move~operate 1 MW mobile generator”. We also combined or withdrew several background functions that did not contribute to our interest (a foreground function is the one being analyzed, whereas a background function is the one that affects, as context or environment of, the foreground function. In this paper, the term function generally refers to the foreground function). For example, background functions “Provide computer-based procedure” and “Provide paper-based procedure” were combined into “Provide procedures”, and functions related to local resident evacuation were eliminated.

Table 2. The number of functions in the generalized FRAM model.

Performers/ERT	Number of Functions (Including Background Functions)	Function Examples
MCR	6	Confirm reactor shut-down; Diagnose accident; Perform accident countermeasures (as described in the procedures).
FO	2	Check the field; Perform countermeasures on the field.
SC	2	Check the debris condition on the road; Remove the debris on the road.
External SC	1	External SC drivers move to the site.
OSC	3	Start OSC (not yet active); Activate OSC, distribute personnel, provide equipment.
TSC	4	Perform severe accident-management tasks; Activate TSC, comprehend situation.
EOF	3	Start EOF (not yet active); (EOF) perform tasks on mobile equipment.
Undecided	1	Request to activate TSC/OSC/EOF.
Multiple teams	4	Cooperation to connect AAC DG; Move~operate 3.2 MW mobile generator.
(Background functions)	(14)	Decide the need for AAC DG; Manage/provide FO personnel; Make the tractor remove the debris on the road; Provide procedures; Provide on-site–off-site communication tools.
	26 (40)

lists the number of functions per performer/ERT and function examples. In total, this model consisted of 40 functions, of which 14 background functions supported 26 foreground functions.

While creating the (previous) initial FRAM model, we discovered that the tasks related to the emergency equipment (three mobile and one fixed piece) took a considerable part of the entire accident-management tasks. We confirmed this finding while we revisited the initial FRAM model to create the generalized FRAM model. Simultaneously, those emergency equipment-related functions also involved the highest number of teams who needed to work together. The task related to the 1 MW mobile generator, represented by the function named “Move~operate 1 MW mobile generator”, required MCR to send a request for the equipment, SC to process the request, TSC or EOF to grant the request and approve the equipment operation, external SC drivers to move the equipment, OSC to support the installation, FO to operate the equipment, and back to MCR to confirm the equipment operation’s effect and report to TSC or EOF. From discussions with subject-matter experts, the tasks related to mobile equipment are currently of high interest, and procedures defining those tasks are being tested/updated. Thus, in this study, we decided to set the analysis scope of team communication to the four emergency equipment-related functions, namely: the “Cooperation to connect AAC DG” function, the “Move~operate 1 MW mobile generator” function, the “Move~operate low-pressure mobile pump” function, and the “Move~operate 3.2 MW mobile generator” function. The generalized FRAM model is shown in Figure 4, where the four emergency equipment-related functions are marked with a dashed line shape. These functions have denser connections compared to others (except the supporting background functions), reflecting their importance. Thus, they were selected as the analysis target.

For each of the four functions included in the analysis (hereafter, we used the term “parent function”), a specialized FRAM model was created, with its scope matched to the parent function, not the entire accident scenario.

Table 3. Naming of function and specialized FRAM model.

(Parent) Function Name	Specialized FRAM Model Name
Cooperate to connect AAC DG	AAC DG operation
Move~operate 1 MW mobile generator	1 MW mobile generator operation
Move~operate low-pressure mobile pump	Low-pressure mobile pump operation
Move~operate 3.2 MW mobile generator	3.2 MW mobile generator operation

lists each parent function’s name and its corresponding FRAM model name. Following the FRAM guidelines, the name of a function is in a verb form, and the name of a model is in a noun form. Due to space limitations, we mainly present the result of the low-pressure mobile pump operation model.

The concept of the three model types, i.e., the initial, generalized, and specialized FRAM models, is illustrated in Figure 5. The initial and generalized FRAM model had the same analysis scope, namely the entire NPP accident. However, the scope of the specialized FRAM model is smaller; it covers one pre-selected function of the generalized model. In total, four specialized FRAM models were created, one for each of the parent function. These specialized FRAM models allow us to perform team-communication analysis without overcomplicated functions and aspects.

Two steps of model development were carried out to create the specialized FRAM model. We performed the same model development method for all four specialized FRAM models and described the method in detail using the “Low-pressure mobile pump operation” model.

The first step of model development is to revisit the initial FRAM model and return the parent function to the original functions. The parent function “Move~operate low-pressure mobile pump” in the generalized FRAM model was returned to the series of functions it represented in the initial FRAM model, namely “Decide equipment allocation”, “Prepare equipment transport (on-site)”, “Transport equipment”, and so on. We examined all the aspects of the parent function and included them in the aspects of the specialized FRAM model. For instance, one of the inputs of the “Move~operate low-pressure mobile pump” function is “Request/re-request equipment”. This aspect is included in the specialized FRAM model. Then, since the “Low-pressure mobile pump operation” model covered only one piece of equipment, its functions were specialized. The accident scenario involved two types of low-pressure mobile pumps, one for primary cooling (reactor cooling system) and another for secondary cooling (steam generator). Based on our discussions, both pumps are almost always requested together (as in the scenario); however, since they are different function-wise, we differentiated them in the model, adding the words “primary” and “secondary”. The functions in the “Low-pressure mobile pump operation” model were specialized as follows: “Decide equipment allocation” became “Request mobile pump”, “Prepare equipment transport (on-site)” became “Prepare mobile pump for transport—primary” and “Prepare mobile pump for transport—secondary”, and so on. This first step of model development merely returned the parent functions into their initial forms with some adjustments; to increase the value of the model and the subsequent team-communication analysis, we applied the principle of work-as-imagined versus work-as-done.

The second step of specialized FRAM model development is the application of the principle of work-as-imagined versus work-as-done (WAI vs. WAD) [57]. WAI is the series of works to achieve a certain goal that is planned by the systems designers, and they are usually described and provided to the workers/operators through procedures, guidelines, training course content, manuals, etc. However, the operators may perform the works differently and still achieve the prescribed goal; those works are WAD. Although FRAM can contain both WAI and WAD, its value is higher when it represents WAD because then real variabilities could be reflected and analyzed, and practical improvements could be suggested.

So far, the initial FRAM model and the generalized FRAM model have been developed by following WAI, namely the “imagined” accident scenario. This is inevitable since WAD specifications will require real multi-unit accident-management experiences, which are unavailable at the moment in South Korea’s nuclear industry. For the specialized FRAM model, we made efforts to apply the WAD principle whenever possible and reliably, with feedback from the subject-matter experts. Our strategies in applying WAD principles to the specialized FRAM model are summarized in

Table 4. Applying the WAD principle to the specialized FRAM model.

Strategy	Strategy Application Sample		Justification
	Before	After
Consider a preceding function that affects communication	Only equipment request	Added a decision-making function	Decision-making may involve team briefing and discussion
Add required functions for smooth operation, although not mentioned in the accident scenario	MCR requests equipment, it arrives, FO installs it	Added functions to indicate that MCR monitored the status of its request and order FO to be ready on site	FO should be called and moved to the equipment location for efficient equipment installation
Include possibilities considering RT activation status	MCR requests equipment to SC when TSC/EOF dare not active	Added Resource aspect about ERTs’ activation status so that MCR is aware of it	MCR can request equipment both before and after TSC/EOF becomes active. The knowledge of TSC/EOF status affects (redirect, delay, etc.) MCR decision
Include possibilities considering the emergency situation	External SC personnel are called, they arrive on site	Added a response function by the external SC personnel	The call may not be received; the personnel may be unable/refuse to go to the site due to personal safety concerns
Add required function that contributes to accident-management analysis	External SC personnel are called, they arrive on site	Added a function to indicate that the external SC personnel may need transportation media	The transportation media for external personnel was undecided
Add required aspects regarding knowledge that contribute to accident-management analysis	Not explicitly mentioned in the accident scenario	Added aspects of knowledge when they are definitely required, such as knowledge of equipment storage location, equipment operation method, etc.	This information may contribute to personnel training content
Add required functions by the equipment that can contribute to accident-management analysis	The mobile equipment is installed and operated	Added functions to indicate the supply and maintenance of the water tank for low-pressure mobile pump operation	This information may contribute to equipment maintenance tasks and risk assessment strategy

, along with the changes in the model and the justification of the strategy.

The resulting “Low-pressure mobile pump operation” model after the first step and second step of model development is shown in Figure 6. After the second step of model development, in which we applied the WAD principle, additional functions and aspects were found to be necessary and added, as shown in Figure 6b’s higher number of functions and denser connections between functions.

Figure 6. The “Low-pressure mobile pump operation” specialized FRAM model (a) After the first step of model development; (b) After the second step of model development.

Figure 6. The “Low-pressure mobile pump operation” specialized FRAM model (a) After the first step of model development; (b) After the second step of model development.

The function performers were confirmed, and the variabilities were assigned by following the FRAM guidelines, which described that variability has consequences in terms of time and precision. To support team-communication analysis, we added content variability as the third variability.

Table 5. Examples of variability assignments.

Function (ERT)	Category *	Main Output	Variability			Rationale
			Time	Precision	Content
Decide the need for mobile pump (MCR)	O	Decision on the need for mobile pump	n/a	n/a	n/a	It is a background function, by following the FRAM guideline and FMV tool support, background functions do not have variability assignment.
Request mobile pump—primary (MCR)	H	Mobile pump request—primary	On time	Precise	Correct	Request task is not complicated, and the content is brief.
Move to site (FO)	H	FO personnel arrived	Too late	Precise	Correct	Emergency situation may delay personnel movement, but the location is well known, and the content is brief.
Activate mobile pump—primary (FO)	H	Mobile pump is activated	Too late	Acceptable	Correct	The content is brief, but lack of experience in handling emergency equipment may cause delay and lower precision.
Process mobile pump request (SC)	O	Approved mobile pump request	Too late	Acceptable	Relevant	SC received multiple equipment requests; thus, the output may be delayed, and possible confusion may cause lower precision. The content is not brief (which equipment to which MCR); lower accuracy may be expected.
Call mobile pump drivers (SC)	H	Call to external SC personnel	On time	Acceptable	Relevant	Call task is not complicated, but emergency situation and multiple requests may lower precision and content accuracy.
Response to the call (External SC)	H	Response to the call	Too late	Acceptable	Relevant	The response may be too late due to high telecommunication load during an emergency, and lower precision and content accuracy may be expected due to confusion.
Supervise mobile pump connection—primary (OSC)	H	Mobile pump connection start	Too late	Imprecise	Irrelevant	OSC personnel is at the equipment connection site but must confirm the connection approval to the OSC leader (or TSC/EOF). Thus, output may be delayed. The connection task involved multiple personnel from different ERTs, and the content was not brief.
Order mobile pump connection (TSC)	H	Mobile pump connection order—primary	On time	Imprecise	Correct	The task is clear, and the content is brief, but the lack of experience may cause imprecise decisions prior to order.

* H: Human, O: Organization.

lists examples of variability assignments. The function “Request mobile pump—primary” is performed by one of the MCR members. Thus, the category is “Human”. This function can have multiple outputs, but it has one main output, namely “Mobile pump request—primary”. The variabilities are assigned to this main output. In this case, we decided that this function is performed on time, precisely, and with correct content. The rationale of these variabilities’ assignments is that the requested task is not complicated, and the content is brief.

In the identification of communication function, we identified the functions related to team communication from the specialized FRAM model using the conditions described in Section 3.6. The result is the specialized FRAM models with communication functions marked, without any function or aspect modification.

In team-communication analysis, the aspects of the communication functions are elaborated by considering the communication performance factors from the performance-factor models (Section 3.3), and required functions are added.

There are two strategies to implement the team-communication performance factors. The first strategy is to include the performance factors as aspects of the FRAM model. Those performance factors under the categories of precondition, resource, control, and time factors can be modeled as respective aspects. For example, in the “Low-pressure mobile pump operation” model, the “Request mobile pump—primary” function has been identified as a communication function. By consulting the performance factors, we were able to elaborate the function to analyze team communication. This function’s aspect elaboration is carried out for all identified communication functions.

Table 6. An example of aspects elaboration for team-communication analysis.

	Before Team-Communication Analysis	Added on Team-Communication Analysis	Performance-Factor Name
Function:	Request mobile pump—primary
Function aspects:
Input	Decision that mobile pump is needed	(no addition)	n/a
Output	Mobile pump request—primary	(no addition)	n/a
	Need to call FO
	Condition: mobile pump request has been sent
Precondition	Information on mobile equipment decision-making authority	(aspect matched to performance factor)	Permission required to process the message (no. 24)
	Condition: communication media can be used		Required condition to process the message (no. 22)
	Knowledge of mobile equipment operation	Knowledge of mobile equipment operation and personnel roles/responsibilities	Team member’s role definition related to communication (no. 23)
		Condition: MCR leader’s approval is obtained	Permission required to process the message (no. 24)
Resource	Satellite phone or similar	(aspect matched to performance factor)	Media and tool to receive and send messages (no. 25)
	TSC was not active	(no addition)
	EOF was not active
	n/a	Result of mobile pump request
Control	Emergency equipment operating guideline	(no addition)	Message processing guidelines (no. 20)
		Information included in the request: name of equipment, location, severity, etc.	Protocol required to transmit the message (no. 19)
		Communication feedback mechanism for this type of communication (2-way, 3-way)	Regulations regarding communication (no. 21)
Time	(n/a)	Function that must be carried out immediately	Time allowed for communication (duration) (no. 15)
		Information on task priority (in the case of multiple tasks)	Predefined sequences to process the message (no. 16)
		Time of equipment arrival	Time duration required to maintain the message (no. 18)

shows the aspects elaboration of a “Request mobile pump—primary” function. Each aspect was analyzed and added when needed. The Input and Output aspects have no addition, while the remaining aspects require few additions. This function has three Preconditions, and two of them are matched to the performance factors. They were not revised. The third precondition, “Knowledge of mobile equipment operation”, was elaborated to include the “Team member’s role definition related to communication” performance factor (no. 23); and a new Precondition was added by referring to “Permission required to process the message” performance factor (no. 24), and named “Condition: MCR leader’s approval is obtained”.

Figure 7a shows the “Low-pressure mobile pump operation” model after communication functions were identified, which are marked in red while the functions and aspects were unchanged from the previous version shown in Figure 6b. Figure 7b shows the “Low-pressure mobile pump operation” model after team-communication analysis, where the previously identified communication functions’ aspects were elaborated. Seven functions were also found to be necessary as the provider of the new aspects and they were added, marked in yellow.

Figure 7. The “Low-pressure mobile pump operation” specialized FRAM model (a) The communication functions are marked after communication functions identification (step 2 analysis); (b) Additional functions are marked after team-communication analysis (step 3 analysis).

Figure 7. The “Low-pressure mobile pump operation” specialized FRAM model (a) The communication functions are marked after communication functions identification (step 2 analysis); (b) Additional functions are marked after team-communication analysis (step 3 analysis).

The second implementation strategy is to utilize the remaining performance factors that could not be added as aspects of a communication function to update the function variability. For example, the performance factor of work experience tends to aggravate the variability since the personnel of ERTs have limited hands-on experience in multi-unit NPP accidents.

4. Discussion

We have presented our research results, i.e., the three models that form the team-communication modeling framework, and analyzed them through a case study by following the analysis methodology. In this section, we discussed the insights from the analysis and the limitations of our current study.

4.1. Main Insights from Case Study Analysis

From the FRAM model development based on the accident scenario, we discovered various insights that can be applied to improve the accident-training scenario, procedure/guideline development, and the provision of required system/facility/tools, as well as to develop an accident-management support system. We report the two main insights, as follows, and summarize them in at the end of this subsection.

4.1.1. Unspecified Functions Observations

While creating the FRAM model from the accident scenario, we added functions that were not explicitly specified in the scenario but were required in the accident-management tasks; these functions are called unspecified functions. The reasons those unspecified functions were not mentioned in the scenario are summarized in

Table 7. Unspecified functions samples and backgrounds.

No	Category	Reason the Unspecified Functions Were Not Mentioned Explicitly in the Accident Scenario	Example of Unspecified Functions (in Model *)	Remarks
1	Accident handling
1.1	Personnel deployment	Some operators were assumed to be ready in the desired location when needed.	“Deploy mobile pump drivers” (Model C)	Personnel allocation is difficult when there is a lack of personnel.
1.2	Call for personnel		“Call OSC personnel” (Model B)	The call can be disrupted in case of natural disaster.
1.3	Response to call		“Response to call (by equipment drivers)” (Model C)	Off-site personnel may delay or refuse to enter the NPP site.
1.4	Personnel movement		“Move to site (FO)” (model A)	Movement requires time, knowledge of required tools and target location, and personal protective equipment.
1.5	Monitor personnel movement		“Monitor mobile pump drivers’ location” (Model C)	Re-allocation may be needed upon personnel absence.
1.6	Personnel transportation method		“Provide personnel transportation method” (model B)	Providing personal mobility, pick up, etc. can be considered.
1.7	Personnel on standby	The operators are assumed to perform their tasks upon arrival on the field.	“Stand by to operate equipment” (Model C)	Effective personnel allocation can avoid idle personnel.
1.8	Field supervisor		“Supervise field task” (model B)	When multiple ERTs cooperate, supervisor role improves work efficiency.
1.9	Request support regarding equipment	Out of scope of the accident scenario.	“Request field support on AAC DG (FO)” (model A)	Added by considering occurrence possibility and team-communication performance-factor model.
1.10	Requested equipment monitoring	Operators are assumed to observe the required information.	“Monitor the status of requested mobile pump” (model C)	Repeated requests may be needed for delayed response.
1.11	Equipment-related task completion	Operators are assumed to perform the required task.	“Confirm power supply” (model D)	(n/a)
2	Communication
2.1	Request for approval	Operators are assumed to perform communication when needed.	“Request approval to connect AAC DG” (model A)	Approval and order are differentiated in our model
2.2	Give orders		“Order to connect mobile pump” (model C)
2.3	Discussions		“Discuss the need for a 3.2 MW mobile generator between units” (model D)	(n/a)
3	Equipment-related
3.1	Equipment operation	Overlooked in the scenario but acknowledged during discussions.	“Operate mobile pump”	In the case of mobile pump, an operator must be present to monitor its flow.
3.2	Cooperation with other NPP sites	Operators are assumed to perform the required task.	“Decide with site to request for equipment” (model D)	(n/a)
3.3	Equipment from other NPP sites		“Transport the requested equipment” (model D)	The location of the other NPP sites can be very far; transportation plan and required facilities should be prepared.
3.4	Equipment problem	Out of scope of the accident scenario.	“Handle equipment operation failure” (model B)	Equipment failure is a possibility.
3.5	Equipment maintenance		“Perform maintenance on AAC DG” (model A)	Poor maintenance increases the equipment failure possibility.
3.6	Other facility related to the equipment		“Provide water for pumps” (model C)	Emergency equipment such as mobile pump relies on other facilities to be operable.
4	Management task during accident
4.1	Personnel management during accident	Out of scope of the accident scenario.	“Manage FO personnel” (model A)	Added as a background function
4.2	Decision-making and work system of ERT		“Develop ERT decision-making and work system” (Model A)
5	Operators’ cognitive ability
5.1	Situational awareness	Operators are assumed to observe the required information.	“Observe the AAC DG operation time” (Model A)	Added as a background function
5.2	Decision-making	Decision-making is assumed to be included in the task.	“Decide the need for 1 MW mobile generator” (Model B)
6	NPP management
6.1	Operator training	Out of scope of the accident scenario.	“Perform operators training on emergency equipment” (Model A)	Added as a background function
6.2	Information system		“Provide personnel contact information” (model B)
6.3	Guidelines development		“Develop emergency personnel management guidelines” (Model B)
6.4	Procurement		“Procure emergency equipment” (Model B)
6.5	Workspace and facility		“Provide ERT workspace and facility”

* Model A: “AAC DG operation” specialized FRAM model; Model B: “1 MW mobile generator operation” specialized FRAM model; Model C: “Low-pressure mobile pump operation” specialized FRAM model; Model D: “3.2 MW mobile generator operation” specialized FRAM model.

, along with their categorization and samples of the added functions. For example, in the category of accident handling, specifically personnel deployment, some operators were assumed to be ready in a certain location when they were needed. In the FRAM model, we created a new function called “Deploy mobile pump drivers” that was unspecified in the accident scenario. This function can be critical during an emergency/accident when the number of required personnel might be more than available ones.

When these unspecified functions are addressed, they can contribute to better NPP accident management. For example, after acknowledging the possibility of equipment failure, then the conditions to declare the equipment is faulty, the ERT responsible for the repair, and so on, need to be specified and tested so that efficient equipment repair procedures can be prepared.

Some unspecified functions are already being considered in the NPP accident management. They are not explicitly mentioned in the accident scenario [54,55,56]. Those known issues being studied, for example, are the ones regarding off-site personnel. When off-site personnel are required, they are called to enter the NPP site. For the off-site personnel to arrive at the site, however, first, they must respond to the call. Since a multi-unit accident may be triggered by a natural disaster, and considering that the off-site personnel live moderately close to the NPP site, they may hesitate or refuse to enter the site because of safety concerns or other priorities. When the off-site personnel respond affirmatively and decide to enter the NPP site, there is a question about how they approach the site. This issue is being analyzed through numerical analysis and simulation.

The overlooked unspecified functions may require simple procedure modification, e.g., to call FO personnel to be ready to receive the mobile equipment. However, other unspecified functions may require more complex, definite solutions. The need for clear roles during equipment connection has been recognized since multiple ERTs are involved. Roles are being defined. For instance, OSC will lead the equipment connection task. However, since multiple ERTs with distinct tasks are gathered in one location, we observed that there is a need to decide when the personnel can return to their team/post. For example, the mobile equipment drivers’ task is to deliver the equipment to the target location, but it is not clear when they can return to their post; will they return as soon as the equipment is delivered, or will they wait for specified personnel to formally hand over the equipment or, will they wait for the equipment to be successfully connected and operated (in case it needs to be relocated)? These decisions are required to improve work efficiency, especially during emergencies when personnel are scarce and the possibility of confusion is high. Other examples of overlooked issues, and their contributions to NPP accident management when they are solved, are included in

Table 8. Samples of analysis results and their contributions to NPP accident management.

Analysis Results	Contributions to NPP Accident Management	Contributions Type
Assembly of off-site personnel	Procedure to assemble the off-site personnel (by whom, contact priority, what to do when the call fails, monitor off-site personnel movement, etc.) Off-site personnel respond and assembly training Off-site personnel movement monitoring system Off-site personnel mobility support (dedicated or communal vehicle)	Procedures/guidelines development Accident-training scenario Accident-management support system Required system/facility/tools
Transport of mobile equipment by the driver	Procedure to transport the mobile equipment (preparation, transport, return to post) Driver mobility support to return to post	Procedures/guidelines development Required system/facility/tools
Possibility of equipment failure	Conditions to declare that the equipment is faulty during accident Decision-making guidelines upon equipment failure (to wait for repair or request other equipment) Procedure to repair the equipment during accident (by which ERT, how, until when, etc.)	Procedures/guidelines development
Personnel management during accident	Personnel management procedure (how to assemble ERT, how to request additional personnel, etc.) Personnel status monitoring system (who is doing what)	Procedures/guidelines development Accident-management support system
Maintenance of equipment and equipment-supporting facility	Equipment maintenance procedure Equipment maintenance system (budget, facility and tools, personnel, schedule, etc.)	Procedures/guidelines development Required system/facility/tools
Effect of ERTs’ distributed locations	Dedicated communication system	Accident-management support system
ERT member familiarity and authority change adaptability	Multi-unit accident training Procedure to cope with authority changes	Accident-training scenario Procedures/guidelines development

.

4.1.2. Challenges of ERT Cooperation in a Multi-Unit Accident

We became aware of the ERT challenges during mobile equipment handling and identified three main challenges, as follows: distributed work locations, on-demand team creations, and authority changes.

ERTs are in separate locations, both on-site and off-site, of the NPP. For instance, TSC is located on-site, while EOF, with higher authority, is located off-site [51,52]. The cooperation between teams in distributed locations relies on team communication; however, in the case of a natural disaster-driven multi-unit accident, the telecommunication services might be disrupted. A technical solution is to prepare for a telecommunication media that will work in any disaster event and/or a strategy to recover the telecommunication services rapidly. In the accident scenario for our case study, the utilization of satellite phones is considered. However, the possibility of intermittent telecommunication services should not be overlooked.

In general, the members of an MCR team are fixed, and this high familiarity is favorable to the team’s work performance. In emergency situations, multiple ERTs are assembled, and when their members are absent, they are replaced. These on-demand and ad-hoc teams do not frequently work together (only during training), and the members may not be familiar with each other’s expertise/experience [58], which makes emergency management more difficult.

Last but not least, authority and role changes add to the confusion and time pressure of urgent accident-management tasks. Clear authority and roles are a must in multi-team work [59,60]; however, at the beginning of multi-unit accident management, the roles of ERTs change depending on their activation status. MCR acts as a decision-maker when other ERTs are not yet assembled. When TSC is active, TSC becomes the decision-maker, and the MCR role shifts to implementer. When EOF is active, the highest authority is given to it. These authority and role changes, although predefined and trained, may cause inefficiencies and mistakes. Moreover, the criticality of multi-unit accidents leaves no room for idly waiting for the higher authority ERTs to activate. The active teams should perform accident-management tasks while simultaneously monitoring the status of the higher authority ERT and swiftly adapting to the new work setting.

4.2. Limitations and Future Works

Although we have studied the topic of team-communication modeling for NPP emergencies comprehensively, there are issues to be further considered. First, communication skill is tightly connected to other NTS such as decision-making and situation awareness [10,14,15]. In the research background, we explained our decision to tackle team communication first; however, through team-communication model development, especially the investigation model, we reconfirm the relationship of communication with other cognitive skills. Thus, to improve team-communication skills, other NTS must be improved as well, or rather, to train for better NTS as a whole.

In this study, we limited the team communication to the communication between operators, both intra- and inter-team. Consequently, our models were developed to suit direct (face-to-face) communication and reliable indirect communication. We considered the use of communication tools (included as influencing and performance factors), especially those prepared for NPP emergencies, such as satellite telephones; however, in this study, we decided to exclude the possibility of communication technology’s poor performance and interface-induced human errors. The addition of human–machine interaction will make the models overly complicated; however, it is necessary to consider that kind of interaction, especially for hazardous scenarios [13,61].

The analysis of human–machine interaction, however, will have its highest contributions when the machine/system is specific. Thus, for our next study, we are aiming to design a team-communication support system, combining telecommunication media and a decision support system [62], based on our models and case study findings, aiming to alleviate ERT challenges during multi-unit NPP accident management. We are collecting the system requirements, applicable advanced technologies (virtual reality, digital twins) [63,64], and analysis methods (social network, activity theory) [65,66] that match the challenges of ERT cooperation. The team-communication support system, if it is in a software form, can be used to transmit messages from ERTs in different locations. Each personnel’s tasks and related information are provided to improve familiarity, and a role-changing algorithm is embedded to rapidly adapt when a new ERT becomes active.

5. Conclusions

With the issue in mind that effective communication is a key factor for improving team performance in multi-unit accident situations, we developed a team-communication modeling framework consisting of three models, i.e., team-communication investigation model, process model, and performance-factor model. The team-communication analysis methodology was provided to guide the application of the modeling framework, and a case study was performed to confirm the feasibility of the modeling framework and analysis methodology. The final results of the case study were four specialized FRAM models, each covering a specific scope of the accident scenario, with the functions and aspects elaborated to support team-communication analysis.

The insights from FRAM modeling can be applied to improve the accident-training scenario, procedure/guideline development, and the provision of required system/facility/tools, as well as to develop an accident-management support system. For example, our analysis results on the assembly of off-site personnel revealed the need for a procedure to perform the task efficiently, the possible negative responses from the personnel required accident-training scenarios that cover such events, the monitoring of the personnel movement may require an accident-management support system, and their mobility may be supported by the provision of vehicles (see more in the Section 4 and Table 8).

We can summarize the original contributions of our study as follows. The team-communication modeling framework is comprehensive compared to the model/framework with a similar purpose. The framework concept was explained, its contents were created as the three team-communication models, and an analysis methodology was provided. Although this framework was developed for the nuclear industry, the approach (the three models, their content, and interactions) is applicable to other safety-critical domains operated by multiple teams. For the nuclear domain, our work broadens the references of performance-influencing factors for human reliability analysis and adds the perspective of the process model, i.e., the need to understand how tasks are performed and interconnected. Through the case study, we developed FRAM models based on a multi-unit accident scenario and discovered insights that direct to practical improvements in accident management. For our next study, we are pursuing the team-communication support system, which would be able to alleviate ERT challenges during multi-unit accident management.