JP2010204712A - Emergency command support server, scenario optimization method in emergency, computer program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide an emergency command support system for easily verifying optimization of a scenario. <P>SOLUTION: An emergency command support server 2 for transmitting/receiving data to/from a client terminal 3 includes: an emergency response scenario library 242 for storing a scenario specifying an instruction to prompt the user of the client terminal 3 to perform processing; and an emergency response scenario execution engine 22 for causing the client terminal 3 to sequentially display the instructions, and for sequentially receiving the certainty of the user to the processing corresponding to the instruction from the client terminal 3, and for causing an emergency response history DB 243 to store the certainty for each instruction, and for, when predetermined conditions are satisfied by the cumulative value of certainty values quantitatively showing the certainty, causing the client terminal 3 to display the list of the instructions whose certainty is determined to be low based on the certainty value, and for, when the correction of the instruction displayed in the list is requested from the client terminal 3, correcting the instruction of the scenario. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention makes it easy and efficient to formulate a scenario in accordance with the necessary workflow when a company or administrative body responds to a crisis management in response to a disaster such as an earthquake or fire, and makes a decision to make an actual response. Technical support for emergency command to assist

  Conventionally, there has been proposed an emergency command support system that presents necessary instructions and information at appropriate timings to a plurality of users each having a role in accordance with a workflow, or requests a judgment. Patent Documents 1 to 3 disclose techniques regarding such a conventional emergency command support system. The present applicant has also provided emergency command support systems such as AgADIS (registered trademark) and NoKeos (registered trademark).

JP-A-10-334078 Japanese Patent Laid-Open No. 11-15875 JP 2002-259877 A

  In the emergency command support system, a response policy is determined according to a scenario defined in advance according to a workflow, using information collected from the site where the disaster occurred or from various directions. “Scenario” stipulates responses and actions in an emergency, and combines the concept of time with response policies, manuals, experience, know-how, etc. necessary for emergency response according to the anticipated changes in the situation. Has been created.

  In the emergency command support system, it is necessary to make it possible to revise a scenario in order to cope with an unexpected scenario occurring in the event of an actual disaster or an incorrect judgment during the process. In addition, it is required to use the scenario by optimizing the scenario through actual training.

There are the following three ways to modify a scenario.
The first technique is a technique for creating a scenario in consideration of corrections and errors during the execution of processing according to the scenario. In this method, whether or not the input information is correct is confirmed, and if the information is incorrect, the correction process such as re-execution of the corresponding scenario is incorporated into the scenario. As a result, it is possible to describe a detailed corrective action to be taken. However, it is necessary to describe confirmation processing for each scenario, and it takes time to create the scenario.
The second method is a method in which the scenario control is forcibly transferred to a corresponding correction point and re-executed from there. In this method, the scenario is re-executed after the scenario control is forcibly transferred to an input location that needs to be corrected. This method is easy to implement because it only changes the scenario control. However, depending on the case, there is a possibility that an instruction contradicting the already executed processing may be performed, which is likely to cause confusion for the user.
The third method is a method for recreating a scenario on the spot at the timing when correction is desired. This method can flexibly handle situations that are not in the scenario. However, there is a possibility that correct scenario correction may not be possible due to work in an emergency, and in some cases instructions that contradict the processing already performed may be given, which may cause confusion to the user. high.

There are the following two methods for scenario analysis.
The first method is a method in which processing that takes a long time is extracted from each item included in the scenario, and each user remembers and analyzes the situation at that time. In this method, since the quantitative evaluation can be performed according to the required time, the bottleneck in the time axis direction can be extracted. However, because of the work in an emergency, the memory is ambiguous, and there is a high possibility that correct analysis cannot be performed. In addition, there is a possibility of omission of analysis for items with short time required for improvement.
The second method is to extract the processing that took a long time from each item included in the scenario, leave the memo when each user responds, and watch the memo at that time This is a method in which the user himself / herself remembers or others judge and analyze. In this method, since the quantitative evaluation can be performed according to the required time, the bottleneck in the time axis direction can be extracted. Also, by looking at the memo, information other than the required time can be obtained, and the situation at that time can be easily analyzed. However, there are individual differences in how to write memos, and there are uncertainties regarding whether or not they are understood correctly when others evaluate. Furthermore, since the contents of the memo are not quantified, items that need improvement cannot be automatically extracted, and it is necessary to call and determine the contents of each memo. Similar to the first method, there is a possibility of omission of analysis for an item with a short required time for improvement.

In an emergency such as the occurrence of an actual disaster, there are many highly urgent items that need to be quickly determined, and the user needs to proceed with the processing according to the scenario even for processing with low confidence.
In response to training and actual emergency situations, the work proceeds based on the judgments made once. There was a problem that a vicious circle such as being unable to make a judgment occurred or that it was not possible to cope with the case where it was desired to correct the judgment itself or the instructions.
Also, when looking back and analyzing the response history in training and actual emergency, the required time varies depending on the response items, so it is determined whether there is a problem in the response status of that part simply by taking a long time. There was a problem that it was not possible. Similarly, when verifying a scenario, it is not possible to determine whether it is necessary to improve the scenario for that part, whether it depends on the ability of the user, or was a time-consuming work in the first place. There was a problem.

  In the present invention, in view of the above problems, it is possible to quickly detect a situation in which a scenario to be corrected is progressing, to quickly correct the situation, and to make it possible to easily verify the optimization of the scenario. The main task is to provide time commanding support technology.

  In order to solve the above problems, the present invention provides an emergency command support server, an emergency scenario optimization method, and a computer program.

  The emergency command support server of the present invention is an emergency command support server capable of transmitting and receiving data to and from one or more client terminals. The emergency command support server includes: a first storage unit that stores a scenario in which an instruction for causing each user of the one or more client terminals to perform processing is stored; and the instruction is sequentially transmitted to a predetermined client terminal. In addition to displaying, the user's certainty of processing for the instruction is sequentially received from the client terminal, and the certainty is stored in a predetermined second storage unit for each instruction, and the certainty is expressed quantitatively. When the cumulative value of the certainty value satisfies a predetermined condition, a list of instructions determined that the certainty level is low by the certainty value is displayed on the client terminal, and is displayed on the list from the client terminal. And scenario execution means for correcting the instruction of the scenario when the instruction is requested to be corrected.

  The emergency command support server of the present invention assigns a certainty factor for each instruction, and makes it possible to quickly correct a scenario when the certainty factor reaches a certain condition. Therefore, it is possible to manage the progress of an appropriate scenario. Moreover, it becomes possible to extract a point that becomes a bottleneck of the scenario during training from the relationship between the input certainty factor and time, and it is possible to create a more effective scenario.

The scenario execution means displays the list on the client terminal of any one user together with the name of the user who performed the instructed process, and requests to modify the instruction displayed on the list from the client terminal. In such a case, a message requesting input of correction contents is transmitted to the client terminal of the user who issued the instruction, and when the correction contents are input from the client terminal, the instruction of the scenario is corrected. It may be configured. In such a configuration, it is easy for any one of the users (for example, the person in charge of supervision) to grasp the progress of the entire scenario and determine whether it has been corrected or not. I can judge.
In addition, the scenario execution unit stores the certainty factor for each user in the second storage unit, calculates a cumulative value of the certainty factor value for each user, and the calculated cumulative value is the predetermined value. If the condition is satisfied, the client terminal of the user may be configured to display a list of instructions processed by the user among instructions determined to be low in confidence by the confidence value. Good. In such a configuration, it becomes possible to directly accept a scenario modification request for each user, and the user can respond to his / her own processing at an early stage.

  According to the emergency scenario optimization method of the present invention, data can be transmitted / received to / from one or more client terminals, and instructions for causing each user of the one or more client terminals to execute processing are defined. This is a method executed by the emergency command support server that stores the recorded scenario. In this method, the instruction is sequentially displayed on a predetermined client terminal, and the certainty of the user to the processing for the instruction is sequentially received from the client terminal, and the certainty is stored for each instruction. And when the cumulative value of the certainty value that quantitatively represents the certainty condition satisfies a predetermined condition, a list of instructions determined to be low in certainty by the certainty value value is stored in the client terminal. And a step of correcting the instruction in the scenario when the client terminal requests correction of the instruction displayed in the list.

  The computer program of the present invention is capable of transmitting and receiving data to and from one or more client terminals, and stores a scenario in which instructions for causing each user of the one or more client terminals to perform processing are defined. A computer that sequentially displays the instructions on a predetermined client terminal, and the user's certainty of the process for the instruction is sequentially received from the client terminal, and the certainty is stored in a predetermined storage unit for each instruction. When the cumulative value of the certainty factor value that quantitatively represents the certainty factor satisfies a predetermined condition, the client terminal displays a list of instructions that are determined to have a low certainty factor based on the certainty factor value. Processing, when the client terminal requests correction of the instruction displayed in the list, the instruction of the scenario is corrected Management, is a computer program for execution.

  According to the present invention, a scenario is provided in which a certainty factor is given to an answer to an instruction, and the cumulative value of the certainty factor value quantitatively representing the certainty factor reaches a predetermined condition to accept a correction request from the client terminal. Can be corrected early. Also, scenario optimization can be easily verified.

1 is an overall configuration diagram of an emergency command support system of the present invention. It is an illustration figure of the model stored in an emergency response repository. FIG. 3A is an exemplary diagram of an emergency response scenario, FIG. 3A is a scenario summary table, FIG. 3B is a charge information table, FIG. 3C is a large item table, and FIG. 3D is a cumulative certainty limit table. FIG. 3E shows a node information table. It is an illustration figure of an emergency response log | history, Fig.4 (a) represents a node history table, FIG.4 (b) represents a certainty factor history table. FIG. 5A is a process flowchart of an emergency response scenario, in which FIG. 5A shows main processing and FIG. 5B shows situation confirmation processing. It is a flowchart of the process performed in an emergency command assistance server. It is a flowchart of the process performed in an emergency command assistance server. It is an illustration figure of the screen displayed on the client terminal of a headquarters. It is a figure showing a series of processes by the flowchart of FIG. 6a. It is a figure showing a series of processes by the flowchart of FIG. 6a. It is a figure showing a series of processes by the flowchart of FIG. 6a. It is an illustration figure of a confirmation node list. It is an illustration figure of a node history table. It is an illustration figure of the list of correction object and cancellation object processing. It is a figure showing a series of processes at the time of correction. It is a figure showing a series of processes at the time of correction. It is a figure showing a series of processes by the flowchart of FIG. It is an illustration figure of the list of correction candidates. It is a figure showing a series of processes at the time of correction. It is a figure showing a series of processes at the time of correction.

Embodiments of the present invention will be described below with reference to the drawings.
FIG. 1 is an overall configuration diagram of an emergency command support system according to the present invention.
The emergency command support system 1 is configured by connecting an emergency command support server 2 and one or more client terminals 3 via a network L. As long as the network L can transmit and receive data between the emergency command support server 2 and the client terminal 3, the network L can be a public line, a local line such as a LAN (Local Area Network), or a combination of these. Such a configuration may be used, and it does not matter whether it is wired or wireless.

  The client terminal 3 is provided for each user, and transmits and receives data to and from the emergency command support server 2 via the network L. In this embodiment, a client terminal 3 is provided for each user of the headquarters, fire fighting team, and rescue team. The client terminal 3 is a personal computer to which a display for displaying data sent from the emergency command support server 2 and an input device such as a keyboard and a mouse for enabling the user to input data are connected. And information processing apparatuses such as PDAs and mobile phones. The client terminal 3 is used as a scenario editing terminal for inputting data for formulation at the time of scenario formulation, and various information from the emergency command support server 2 is transmitted to the user as the scenario is executed at the time of emergency response. The terminal is used as an emergency response support terminal for transmitting the input from the user to the emergency command support server 2 and used as a history analysis terminal at the time of emergency response plan analysis.

The emergency command support server 2 includes a CPU (Central Processing Unit), a RAM (Random Access Memory), a ROM (Read Only Memory), and a storage device that stores the computer program of the present invention. Is supposed to run. The emergency command support server 2 has a built-in or external mass storage device. The emergency command support server 2 executes the computer program with the hardware configuration as described above, so that an emergency response scenario editor unit 21 for developing an emergency response scenario (emergency response scenario), an emergency response scenario The emergency response scenario execution engine 22 for executing the emergency response and the emergency response history analysis unit 23 for analyzing the execution result of the emergency response scenario are formed, and the database 24 is constructed in the mass storage device.
The database 24 includes an emergency response repository 241 for storing a template of a general emergency response plan for facilitating emergency response scenario creation, an emergency response scenario library 242 for storing the prepared emergency response scenarios, and a report. And an emergency response history database (hereinafter referred to as DB) 243 for recording an emergency response history.

  FIG. 2 is an exemplary diagram of templates stored in the emergency response repository 241. The emergency response repository 241 stores a process template for creating an emergency response scenario defined in accordance with an emergency workflow for each category classified into a large category, a medium category, and a small category. Using these templates, the user can identify the specific work to be performed during emergency response, determine the work procedure, set the basic items such as response items and response types, and create an emergency response scenario. create.

3A to 3E are illustrations of emergency response scenarios. The emergency response scenario includes a scenario summary table shown in FIG. 3A, a charge information table shown in FIG. 3B, a large item table shown in FIG. 3C, and a cumulative certainty limit upper table shown in FIG. And the node information table shown in FIG. 3 (e).
In the scenario summary table, the scenario name, version, creation date, edit date, and creator of the emergency response scenario are recorded.
In the charge information table, the affiliation of the user (person in charge) and, for example, the IP address of the client terminal 3 are recorded as the account of the client terminal 3 used by the user. The emergency command support server 2 can identify the client terminal 3 by an account, and when transmitting / receiving data, the client terminal 3 as a transmission / reception destination can be specified by the account.
In the large item table, item names of large items in which a series of operations executed in this emergency response scenario are collected are recorded. By recording large items, emergency response scenarios can be organized into several meaningful groups. This is because it is difficult to grasp the situation at the time of scenario creation, execution, and analysis when item names are arranged one by one, for example, in small items.
In the cumulative certainty factor upper limit table, the upper limit value of the cumulative certainty factor in the entire emergency response scenario is recorded. For example, set the upper limit of the cumulative value calculated by the combination of the value that quantifies the confidence level of the user's confidence in the processing and the number, and if the upper limit is exceeded, there is no confirmation to the user In addition, it is not possible to proceed to the subsequent processing.

In the node information table, a specific unit of processing executed by the user according to the emergency response scenario is set as a node, and the content is recorded as node information. In the node information, basic items such as corresponding items and answer types are set. Each item of node information is assigned an item ID, the name of the major item to which it belongs, the type of message (question, work instruction, reference information, etc.), the user to be executed (in charge), the message to be displayed, the answer type, the answer The item ID of the transition destination of the next flow for each type, presence / absence of certainty restriction, availability of cancellation restriction, and presence / absence of cancellation processing are recorded.
The certainty limit is displayed as “Yes” when the upper limit value of the cumulative certainty is set in the cumulative certainty limit upper table, and as “None” when not set. When the certainty limit is “Yes”, the upper limit value of the cumulative certainty level can be set in the node information. The cancellation limit sets whether or not to cancel the flow. For example, if the flow cannot be canceled, the flow cannot proceed beyond this node without confirmation from the user.
The cancel process is used when canceling a node that has already been executed by modifying the node state, the response content, etc., and the process set here is executed. When there is no setting, a cancellation notice, correction contents, a correction person, and a cancellation node list (message node only) are displayed to related users.

FIG. 4 is an exemplary diagram of an emergency response history. The emergency response history is composed of two tables, a node history table shown in FIG. 4A and a certainty history table shown in FIG.
The node history table records the history for each node information of the emergency response scenario. The item ID of each node information is the same as the item ID of the original emergency response scenario, and the degree of certainty and the certainty degree memo when the user (practitioner) executes are recorded respectively. The message display start time, execution end time, and the user who responds to the message are automatically recorded. Answers are recorded for questions and work instructions. Further, “waiting” is recorded when the message display state is waiting for a reply, and “done” is recorded when replying has been completed. The initial value of the retroactive prohibition flag is “permitted”, but when the node information for which the cancellation limit is set to “deny” is passed, “prohibited” is set to the node information before the node information. . In the correction memo, when the certainty factor or the flow retroactive process is executed during execution, the reason for the correction by the user who performed the correction is entered and recorded as a history. In the cancellation time, when the flow retroactive processing is executed, the processing time is recorded.
In the certainty history table, the cumulative result of each user's certainty is stored in order to calculate the cumulative certainty. The certainty factor is quantified as a certainty factor value by “frequency”, and a value obtained by adding all products of the frequency and the number of times of each certainty factor becomes the cumulative certainty factor. The cumulative certainty factor can be calculated for all users and for each user.

  In this embodiment, the cumulative certainty is the average of the frequency of the certainty multiplied by the number of times. In this case, the determination is made based on the proportion of responses with low confidence in the entire response. As another method, it is possible to make a determination based on the number of responses with low confidence. This directly sets an upper limit on the number of answers with low confidence. In that case, the certainty table further sets the upper limit for each degree of certainty.

<Processing procedure>
In such an emergency command support system 1, an emergency response scenario used for commanding an emergency, creation of an emergency response scenario during training or an actual emergency response, and analysis of the emergency response scenario are performed.

Creation of emergency response scenario The emergency response scenario is created by the emergency response scenario editor unit 21 of the emergency command support server 2 in response to an instruction from the client terminal 3. The emergency response scenario editor unit 21 starts creating an emergency response scenario by receiving a scenario creation request from the client terminal 3 functioning as a scenario editing terminal. When creating a scenario, the emergency response scenario editor unit 21 displays a creation screen for supporting scenario creation on the display of the client terminal 3. The client terminal 3 functioning as a scenario editing terminal may be any one of the headquarters, the fire fighting team, and the rescue team, but the client terminal 3 of the headquarter is usually used.

The user inputs at least necessary items including the affiliation (in charge) of the user who performs the processing indicated in the node information and transition information indicating the next node information to be transitioned, with reference to the template of the emergency response repository 241. To do. An emergency response scenario is created based on these input items and registered in the emergency response scenario library 242. At this time, a connection of a plurality of pieces of node information may be registered in the emergency response repository 241 as one template and edited.
The created emergency response scenario can be printed by the client terminal 3 in a table format or a flowchart format. The printed matter can be used as an emergency response manual.

-Response instruction at the time of training by the emergency response scenario or actual emergency response The response instruction at the time of training or actual emergency is performed using the emergency response scenario created in this way.
In this case, the emergency response scenario execution engine 22 reads out each message recorded in the node information table of the emergency response scenario read from the emergency response scenario library 242 in the order of the node information, and executes the processing of the user client. It is displayed on the terminal 3. Further, the emergency response scenario execution engine 22 receives the response status from the client terminal 3 and records it in association with the corresponding item ID in the node history table of the emergency response history 243.

  In order to give training or actual emergency response instructions, the client terminal 3 expresses an emergency response scenario in the form of a flowchart as shown in FIG. 5 so that each user can easily grasp the work in time series. You can also. FIG. 5A is a flowchart of the main process, and shows the process flow of the entire scenario. FIG. 5B is a flowchart of the status confirmation process. The status confirmation processing is indicated by item IDs 1-1 to 1-4 in FIG. 3E, and in FIG. 5B, it can be visually seen who is instructed by the processing indicated by each item ID. It has become. FIG. 5C is a flowchart of the site response process. The on-site processing is indicated by item IDs 2-1 to 2-6 in FIG. 3 (e), and in FIG. 5 (c), it is possible to visually recognize who the processing indicated by each item ID is directed to. It has become.

  In training or actual emergency response, message read processing, response processing, certainty determination processing, and correction processing are performed in accordance with an emergency response scenario. FIGS. 6A and 6B are flowcharts of processes executed in the emergency command support server 2 including these processes, and show a case where the emergency response scenario of FIG. 3 is executed. A series of processing of FIG. 6A is represented by FIGS. 8 to 10, and a series of processing of FIG. 6B is represented by FIG.

The emergency command support server 2 reads out the messages in the order of the item IDs from the emergency response scenario of “fire response” in the emergency response scenario library 242 by the emergency response scenario execution engine 22, and sends the messages to the client terminal 3 of the corresponding user. A screen like 7 is displayed. FIG. 7 is an exemplary view of a screen displayed on the client terminal 3 of the headquarters. In addition to scenario information such as the scenario name of the emergency response scenario and user information about the user, messages such as work instructions, questions to the user, and reference information are displayed on the screen. It also allows the input of answers to questions. Thus, questions, work instructions, and reference information are provided for each user (step S10). Further, when the emergency command support server 2 reads the message by the emergency response scenario execution engine 22, the item ID of the notified message, the message display start date and time, and the message display state “wait” are recorded in the node history table. .
Note that when the node information of the read emergency response scenario becomes the item ID 10-1, the process ends.

  The user takes action according to the message displayed by the client terminal 3. For example, on the screen of FIG. 7, the user presses an answer “Yes” button corresponding to the work instruction, and inputs a certainty factor and a certainty factor memo. The client terminal 3 transmits these input contents to the emergency command support server 2 together with the user name and the corresponding item ID. The emergency command support server 2 receives these input contents transmitted from the client terminal 3 by the emergency response scenario execution engine 22 (step S20), and records them in the corresponding item ID of the node history table. If the cancellation process is prohibited, the retroactive flag is recorded as non-permitted, and the node information is traced back and all retroactive flags are changed to non-permitted (step S30).

After recording in the node history table, the emergency response scenario execution engine 22 checks whether or not the cumulative certainty exceeds the threshold value. First, the cumulative certainty factor upper limit (threshold value) is read from the emergency response scenario library 242, and the certainty factor history table is read from the emergency response history 243. The accumulated certainty factor is expressed by, for example, the equation (1), and is calculated as an average of the frequency of the certainty factor in the certainty factor history table multiplied by the number of times (step S40). The determination is made based on the magnitude relationship between the calculated result and the threshold value. A determination is made every time there is an answer to each node for each user of the answered nodes and for all nodes.
Cumulative certainty factor = Σ (frequency × number of times) / Σ (number of times) (1)

  If it is determined by the determination of the cumulative certainty that the cumulative certainty is equal to or less than the threshold, the process returns to step 10 and the next instruction is presented to the user (step S50: below the threshold). The above series of processing is shown in FIG.

When it is determined by the determination of the cumulative certainty that the cumulative certainty exceeds the threshold value, there are two processing patterns.
First, when the cumulative certainty of the entire emergency response scenario being executed exceeds the cumulative value, a list of responses with low confidence is displayed to the person responsible for executing the emergency response scenario. This is a process in which the user confirms each user (FIG. 6A). In this embodiment, the general manager is a user of the headquarters. This process is shown in FIGS.
The other is a process of determining the cumulative certainty factor for each user and performing direct confirmation from the emergency command support server 2 only for the user whose cumulative certainty factor exceeds the threshold (FIG. 6B). )). This process is shown in FIG.

With reference to FIGS. 6A, 9, and 10, the case where the cumulative certainty exceeds the threshold value in step S <b> 50 and the supervisor in charge of the scenario performs confirmation processing will be described. The purpose of this is to determine whether the entire emergency response scenario should be confirmed and confirmed, and whether or not an appropriate response is being implemented in accordance with the emergency response scenario for the entire node. To do.
In response to the message of the node of item ID 2-2, which is a work instruction for the fire fighting team, “Please start fire fighting activities according to instructions from the headquarters”, the client terminal 3 of the fire fighting team has low confidence in answers and messages The process of steps S <b> 51 to S <b> 56 will be described by taking as an example the case where the judgment is input and the cumulative certainty factor in the certainty factor determination process exceeds the threshold value. Here, in calculating the cumulative certainty factor, the values for all users are summed and compared with a threshold value.

  In the certainty determination process, when it is determined that the cumulative certainty exceeds the threshold (step S50: exceeding the threshold), the emergency response scenario execution engine 22 determines the certainty among the nodes for which the retroactive flag of the node history table is permitted. Node information with a low is extracted and a confirmation node list is created. The confirmation node list may be created by extracting node information having a certain confidence level or less (for example, extracting the confidence level in comparison with a predetermined value in FIG. 4B), and all the node information. May be extracted and sorted in descending order of confidence (frequency comparison). FIG. 11 is a view showing an example of a confirmation node list created from the node history table of FIG. The emergency response scenario execution engine 22 notifies the client terminal 3 of the headquarters of a message such as “the cumulative certainty of the currently executed scenario has exceeded the threshold” and transmits the created confirmation node list. And displayed on the client terminal 3. In displaying, in order to make it easier for the user of the headquarters to grasp the processing relationship before and after, it may be presented together with a flowchart (steps S51 and S52).

When the user at the headquarters selects a node (for example, item ID 1-3) that requires confirmation from the confirmation node list presented to the client terminal 3, the item ID of the selected node is the emergency command support server. The second emergency response scenario execution engine 22 is notified.
The emergency response scenario execution engine 22 notifies the content confirmation request message to the client terminal 3 of the user who responds to the node (in this embodiment, the client terminal 3 of the fire fighting team) from the node information of the notified item ID. To do. Thus, a confirmation request is made to the user (step S53).

The user of the fire fighting team confirms the content confirmation request message on the client terminal 3 and confirms the inquiry from the headquarters. Here, the user selects any one of “change of confirmation content”, “change of certainty”, and “hold”.
If “hold” is selected, the node with the next lowest certainty is selected and the same processing is performed.
When the “change in certainty factor” is performed, the certainty factor is changed with respect to the history, and the certainty degree determination process is performed again in the emergency command support server 2. As a result, when it is determined that the certainty level does not exceed the threshold value, the emergency command support server 2 similarly extracts a list of nodes with low certainty levels and displays them on the client terminal 3 at the headquarters.
When the confirmation contents such as “Smoke tube was found and it was not a fire” were changed, an amendment message including at least the node ID, amendment contents, and memo was created and urgent from the client terminal 2 of the fire fighting team It is transmitted to the emergency response scenario execution engine 22 of the time command support server 2.
The processes in steps S52 and S53 are performed for all the nodes in the confirmation node list. When the processes of steps S52 and S53 for all the nodes are completed, the process proceeds to step S54.

The emergency command support server 2 determines whether or not the scenario is corrected based on the presence or absence of the correction message. When the correction message is not received, it is determined that the scenario is not corrected (step S54: No), and the process proceeds to step S10.
Upon receiving the correction message, the emergency command support server 2 determines that there is a scenario correction (step S54: present).

  The emergency command support server 2 receives the correction message, and responds to the history (item ID1-3) corresponding to the node ID by the emergency response scenario execution engine 22 with “Yes”. From "Yes" to "No." Confirmed that a smoke tube was found. It was not a fire. Change the answer from "Yes" to "No". ”Is written. In the node history table, as shown in the illustration of FIG. 12, the correction memo is recorded in the message of the corresponding ID and the cancellation date and time are recorded in the canceled message (step S55).

  When the node information is corrected, the emergency response scenario execution engine 22 extracts already executed node information after the corrected node information from the emergency response history, and sends the extracted node information to the client terminal 3 corresponding to “ “The smoke cylinder was found. It was confirmed that it was not a fire. The answer was changed from“ Yes ”to“ No ”. "apparently. "And a cancellation processing list. FIG. 13 is an exemplary diagram of a list of correction target and cancellation target processes.

  The emergency response scenario execution engine 22 reads the node information next to the corrected node information, displays a message on the screen of the client terminal 3 of the corresponding user, and returns to step S10 (step S56). In order to make it easier for the user to understand the processing relationship before and after, a flowchart representing a series of processing at the time of correction as shown in FIGS. 14 and 15 is displayed on the corresponding client terminal 3 during the above processing. Also good.

When the certainty level exceeds a certain threshold and the confirmation is performed as described above, a message may be transmitted to the client terminals 3 of a plurality of users at the same time even in the same emergency response scenario. . In that case, even if a message is returned from each user, reading of the next node information may be temporarily stopped, and the progress of the entire emergency response scenario may be stopped until a certain degree of certainty is exceeded.
Furthermore, when performing the certainty determination process for the entire emergency response scenario, whether or not there is a restriction on cancellation of node information of the message when the next message is read, not every time a response is returned from each user It may be executed only when the cancellation limit is “present”. In this way, the progress of the emergency response scenario can be efficiently corrected in the correct direction.

  When the cumulative certainty exceeds the threshold value in step S50 and direct confirmation from the emergency command support server 2 is performed only for the user whose cumulative certainty exceeds the threshold value in step S50 according to FIG. 6B and FIG. The process will be described. In this process, when the certainty level is extremely low locally, it is possible to detect an item to be confirmed early. The emergency command support server 2 confirms whether or not the correction is made, changes the “answer” of the question message having a low certainty level, and shows a process for changing the flow.

  As a result of the certainty determination process for the message "node information (item ID 2-2)" of the work instruction for the fire fighting team "Please start fire fighting activities according to instructions from the headquarters", the cumulative confidence of the fire fighting team exceeds the threshold If it is determined that the emergency response scenario execution engine 22 responds to the client terminal 3 of the fire fighting team, “An answer with low confidence has continued, but will you continue to execute the scenario as it is? A confirmation message with a content such as “Yes” or “No” if you want to make corrections retroactively ”is notified to the client terminal 3 of the fire brigade and displayed (step S61).

  The user of the fire fighting team selects either “Yes” or “No” in response to this notification and responds to the emergency response scenario execution engine 22. Based on this answer, the emergency response scenario execution engine 22 determines whether or not the user continues to execute the scenario (step S62).

When the emergency response scenario execution engine 22 receives the answer “Yes” from the client terminal 3 of the fire fighting team, it reads the next node information and continuously executes the emergency response scenario (Step S62: Continue, Step S10). ).
When the emergency response scenario execution engine 22 receives the answer “No” from the client terminal 3 of the fire fighting team, it subsequently receives a correction request message from the client terminal 3 of the fire fighting team (step S62: correction without continuing). Upon receiving the correction request message, the emergency response scenario execution engine 22 extracts an executed node with a low certainty factor of the fire fighting team as a correction candidate and displays it on the client terminal 3 of the fire fighting team (step S63). FIG. 17 is an exemplary diagram of a list of correction candidates.
The user of the fire fighting group selects the node to be corrected from the presented list by using the client terminal 3.

  Thereafter, as in FIG. 6A, when a node is corrected, the scenario execution engine extracts the executed nodes after the corrected node and notifies the person in charge corresponding to the node to that effect. (Steps S64 to 67). In order to make it easier for the user to grasp the processing relationship before and after, a flowchart representing a series of processing at the time of correction as shown in FIGS. 18 and 19 is displayed on the corresponding client terminal 3 during the above processing. Also good.

・ Emergency response scenario analysis processing Emergency response scenario analysis processing is performed as follows.
In the analysis process, node information that is a bottleneck is extracted, the message content in the node information is examined, node information is divided into multiple pieces, and editing such as changing the corresponding user is performed. . Specifically, the emergency response history analysis unit 23 reads the node history table from the emergency response history 243, performs various analyzes, and selects node information that is a specific candidate for review.

A user who analyzes an emergency response scenario accesses the emergency command support server 2 using the client terminal 3 functioning as a history analysis terminal, and starts a scenario creation analysis process. The client terminal 3 that functions as a history analysis terminal may be any one of the headquarters, the fire fighting team, and the rescue team, but the client terminal 3 at the headquarter is usually used.
The emergency response history analysis unit 23 reads node information executed in the past from the node history table, and the response time is long and the reliability is low from the response time obtained from the display time and the end time and the input reliability. Extract information.

The user edits the node information, such as changing the instruction information of the node information, dividing the node information, and deleting the node information. Here, each node information may be displayed on a graph having two axes of corresponding time and certainty factor, and may be selected by the user.
Various methods are conceivable for extracting node information to be edited. For example, from the emergency response history acquired at the time of multiple trainings, node information that has been particularly changed among the node information that has been modified by the certainty determination process, or that has been canceled a lot due to the change. You may extract based on the number of.

  DESCRIPTION OF SYMBOLS 1 ... Emergency command support system, 2 ... Emergency command support server, 3 ... Client terminal, 21 ... Emergency response scenario editor part, 22 ... Emergency response scenario execution engine, 23, Emergency response history analysis part, 24 ... Database, 241 ... Emergency response repository, 242 ... Emergency response scenario library, 243 ... Emergency response history database, L ... Network

Claims (5)

An emergency command support server capable of sending and receiving data to and from one or more client terminals,
First storage means for storing a scenario in which an instruction for causing each user of the one or more client terminals to perform processing is defined;
The instructions are sequentially displayed on a predetermined client terminal, and the user's certainty of processing for the instruction is sequentially received from the client terminal, and the certainty is stored in a predetermined second storage unit for each instruction. When the cumulative value of the certainty value that quantitatively represents the certainty factor satisfies a predetermined condition, the client terminal displays a list of instructions determined that the certainty factor is low by the certainty value, A scenario execution unit that corrects the instruction of the scenario when the client terminal requests correction of the instruction displayed in the list;
Emergency command support server. The scenario execution means includes
When the client terminal of any one user displays the list together with the name of the user who performed the instructed process, the client terminal requests correction of the instruction displayed in the list. Sending a message requesting input of correction contents to the client terminal of the user who made the instruction, and correcting the instruction when the correction contents are input from the client terminal,
The emergency command support server according to claim 1. The scenario execution means includes
When the certainty factor is stored for each user in the second storage means, the cumulative value of the certainty factor value is calculated for each user, and when the calculated cumulative value satisfies the predetermined condition, the use Display a list of instructions processed by the user among instructions determined to be low in confidence by the confidence value,
The emergency command support server according to claim 1. By an emergency command support server that can transmit / receive data to / from one or more client terminals and stores a scenario in which instructions for causing each user of the one or more client terminals to execute processing are defined A method to be implemented,
Sequentially displaying the instructions on a predetermined client terminal;
Sequentially accepting the certainty of the user for the processing for the instruction from the client terminal, and storing the certainty in a predetermined storage unit for each instruction;
When the cumulative value of the certainty value that quantitatively represents the certainty factor satisfies a predetermined condition, displaying a list of instructions that are determined to be low by the certainty value on the client terminal;
Correcting the instructions in the scenario when the client terminal requests correction of the instructions displayed in the list,
An emergency scenario optimization method. A computer that can transmit and receive data to and from one or more client terminals and stores a scenario in which instructions for causing each user of the one or more client terminals to perform processing are stored.
Processing for sequentially displaying the instructions on a predetermined client terminal;
A process of sequentially receiving from the client terminal the certainty of the user to the process for the instruction, and storing the certainty degree in a predetermined storage unit for each instruction;
A process for displaying, on the client terminal, a list of instructions that are determined to have low certainty by the certainty value when a cumulative value of certainty values that quantitatively represent the certainty satisfies a predetermined condition;
A process for correcting the instruction in the scenario when the client terminal requests correction of the instruction displayed in the list;
A computer program for running.

Images