WO2021005686A1 - 自動連携装置、自動連携方法、および自動連携プログラム - Google Patents

自動連携装置、自動連携方法、および自動連携プログラム Download PDF

Info

Publication number
WO2021005686A1
WO2021005686A1 PCT/JP2019/027002 JP2019027002W WO2021005686A1 WO 2021005686 A1 WO2021005686 A1 WO 2021005686A1 JP 2019027002 W JP2019027002 W JP 2019027002W WO 2021005686 A1 WO2021005686 A1 WO 2021005686A1
Authority
WO
WIPO (PCT)
Prior art keywords
scenario
scenarios
cooperation
automatic
alm
Prior art date
Application number
PCT/JP2019/027002
Other languages
English (en)
French (fr)
Inventor
愛子 尾居
高田　篤
Original Assignee
日本電信電話株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 日本電信電話株式会社 filed Critical 日本電信電話株式会社
Priority to JP2021530378A priority Critical patent/JP7273341B2/ja
Priority to PCT/JP2019/027002 priority patent/WO2021005686A1/ja
Priority to US17/625,382 priority patent/US11775367B2/en
Publication of WO2021005686A1 publication Critical patent/WO2021005686A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0677—Localisation of faults
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793—Remedial or corrective actions
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0604—Management of faults, events, alarms or notifications using filtering, e.g. reduction of information by using priority, element types, position or time
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery

Definitions

  • the present invention relates to an automatic linkage device, an automatic linkage method, and an automatic linkage program.
  • NW network
  • APL application
  • a service provider that provides services to end users provides a service provider's own service by combining services provided by a wholesale service provider without owning assets.
  • NW service is a service using a network such as a wide area L2 (Ethernet "registered trademark") service, an IP-VPN (Internet Protocol Virtual Private Network) service, and a MVNO (Mobile Virtual Network Operator).
  • the cloud service is a service based on the Infrastructure as a Service (IAAS) platform.
  • IAAS Infrastructure as a Service
  • the APL service is a service in the form of providing software in which necessary functions related to communication are used as services as much as necessary.
  • Each wholesale service provider publishes one communication service via API (Application Programming Interface). Therefore, for example, when a service provider who provides a communication service to a user wants to use the communication function of the NW service, he / she accesses an API that publishes the NW service. If you want to use the communication function of the cloud service, access the API that publishes the cloud service. If you want to use the communication function of the APL service, access the API that publishes the APL service. In this way, the service provider uses one communication service disclosed by one wholesale service provider to provide the user.
  • API Application Programming Interface
  • Patent Document 1 A device for constructing a collaborative service is known (see Patent Document 1). According to the technology of Patent Document 1, it is possible to collectively construct and provide a cooperative service that combines various communication services of a plurality of wholesale service providers in response to an order request of a communication service provider.
  • Patent Document 1 Since the technology (orchestrator) of Patent Document 1 focuses on service construction work, it is good at system cooperation along a simple work flow that is defined in advance and has few conditional branches, but it is good at failure handling work. There is a problem that they are not good at system cooperation along a complicated business flow such as. That is, in the failure handling business, since the content / method of the next process changes according to the result of each process, the business flow becomes fluid and has many conditional branches. When applying the conventional technology, it is necessary to specify the failure response business flow that describes the comprehensive conditional branching in the catalog / cooperation rule (scenario), so the specified amount becomes enormous and the system performance of the conventional technology deteriorates. May occur.
  • the failure response business starts failure response (executes a scenario) when an alarm (ALM) is issued from the device, but there is a dependency relationship (main factor ALM and ripple ALM, etc.) between ALMs.
  • ALM alarm
  • main factor ALM and ripple ALM, etc. main factor ALM and ripple ALM, etc.
  • the scenario should be executed independently for each ALM.
  • ALM of the transmission layer is the main factor ALM
  • the ALM of the transfer layer is the ripple ALM.
  • the scenario for the ripple ALM on the transfer layer side needs to be interrupted or the content of the scenario needs to be changed. In this way, management and control across multiple scenarios is required, but this has not been considered in the prior art. From the above, the conventional technology is not suitable for failure handling work.
  • the present invention has been made in view of the above circumstances, and an object of the present invention is to provide an automatic cooperation device, an automatic cooperation method, and an automatic cooperation program that can be applied to a failure handling business.
  • the automatic cooperation device of one aspect of the present invention includes a scenario creation unit that creates a scenario, a scenario cooperation unit that links the scenarios, and a scenario management execution unit that manages and executes the scenario, and shares failure handling operations.
  • a scenario creation unit that creates a scenario
  • a scenario cooperation unit that links the scenarios
  • a scenario management execution unit that manages and executes the scenario, and shares failure handling operations.
  • Classify into work and individual work define a parent scenario or child scenario for a work group that combines the classified work or multiple work, divide the scenario, and from the relationship between each scenario and the execution status of each scenario. Management is performed across the scenarios, and the scenarios are interrupted or changed according to the failure handling process and contents.
  • the automatic cooperation device executes a scenario creation step for creating a scenario, a scenario cooperation step for linking the scenarios, and a scenario management execution step for managing and executing the scenario.
  • a scenario creation step for creating a scenario
  • a scenario cooperation step for linking the scenarios
  • a scenario management execution step for managing and executing the scenario.
  • Classify fault handling tasks into common tasks and individual tasks define a parent scenario or child scenario for a task group that combines the classified tasks or multiple tasks, divide the scenario, and the relationships between each scenario. Management is performed across the scenarios from the execution status of each scenario, and the scenario is interrupted or changed according to the failure handling process and the content.
  • One aspect of the present invention is an automatic linkage program that causes a computer to function as the automatic linkage device.
  • an automatic cooperation device an automatic cooperation method, and an automatic cooperation program that can be applied to a failure handling business.
  • FIG. 1 is a configuration diagram showing the entire communication system according to the embodiment of the present invention.
  • FIG. 2 is a block diagram showing a configuration of an automatic cooperation device.
  • FIG. 3 is a diagram showing a failure handling business flow and an example of each process constituting the flow.
  • FIG. 4A is a conceptual diagram in the case of automatically creating a parent scenario and classifying child scenarios.
  • FIG. 4B is a conceptual diagram in the case of automatically creating a parent scenario and classifying child scenarios.
  • FIG. 5 is a flowchart showing an operation example when determining whether or not to execute a coping scenario and which coping scenario is to be executed.
  • FIG. 6 is a diagram showing items and a list of outputs of the pre-confirmation scenario.
  • FIG. 1 is a configuration diagram showing the entire communication system according to the embodiment of the present invention.
  • FIG. 2 is a block diagram showing a configuration of an automatic cooperation device.
  • FIG. 3 is a diagram showing a failure handling business flow and an example of each process
  • FIG. 7 is a diagram showing a primary determination condition ID for each ALM and a list of results.
  • FIG. 8 is a diagram showing a primary judgment condition as to whether or not a countermeasure is necessary, depending on the output combination of the prior confirmation scenario.
  • FIG. 9 is a diagram showing a method of determining the content of the coping scenario (selection of the coping scenario).
  • FIG. 10 is a diagram showing a scenario interruption (case 1) due to layer cooperation.
  • FIG. 11 is a diagram showing a scenario change (case 2) by layer cooperation.
  • FIG. 12 is a flowchart showing an operation example of the automatic cooperation device.
  • FIG. 13 is a flowchart showing an operation example of the automatic cooperation device.
  • FIG. 14 is a hardware configuration diagram of the automatic cooperation device.
  • An embodiment of the present invention relates to an automatic cooperation technique for a maintenance operation system.
  • an orchestrator By automatically linking maintenance operation systems using an orchestrator, we aim to automate failure response operations related to simple system failures and reduce operator operations.
  • FIG. 1 is a configuration diagram showing the entire communication system 10 according to the embodiment of the present invention.
  • the communication system 10 includes a terminal 21 of a service provider 20, an automatic cooperation device 30, and servers 41, 51, 61 of a plurality of wholesale service providers 40, 50, 60.
  • the terminal 21 of the service provider 20 is connected to the automatic cooperation device 30 via the NW (network) 81 and the GW (gateway) 71.
  • the automatic cooperation device 30 is connected to the servers 41, 51, 61 of the wholesale service providers 40, 50, 60 via the NW 82 and the GW 72, 73, 74.
  • the server 41 and the server 51 are connected to each other via GW75, NW83, and GW76.
  • the server 51 and the server 61 are connected via GW77, NW84, and GW78.
  • the GW 71 between the terminal 21 and the automatic cooperation device 30 performs a process of determining whether or not the order request, which is an order for the communication service from the terminal 21, is a previously permitted request.
  • the automatic cooperation device 30 transmits a request such as acquisition of one or a plurality of communication services corresponding to the order request to the servers 41, 51, 61.
  • Whether or not the request to the servers 41, 51, 61 is a request from the pre-authorized automatic cooperation device 30 for the GWs 72, 73, 74 between the automatic cooperation device 30 and the wholesale service providers 40, 50, 60.
  • the GWs 75 to 78 between the servers 41, 51, 61 perform an authentication process for connecting the servers 41, 51, 61 with the NW 83, 84.
  • Each wholesale service provider 40, 50, 60 publishes different communication services in API.
  • the server 41 of the wholesale service provider 40 is equipped with the NW service API 41a that publishes the NW service.
  • the server 51 of the wholesale service provider 50 is equipped with a cloud service API 51a that publishes a cloud service.
  • the server 61 of the wholesale service provider 60 is equipped with the APL service API 61a that publishes the APL (application) service.
  • the service provider 20 provides the user with its own communication service by using one or more of the various communication services published by the wholesale service providers 40, 50, 60.
  • the automatic cooperation device 30 is requested to order one or more communication services to acquire the communication service.
  • the automatic cooperation device 30 controls APIs 41a, 51a, 61a of various communication services in an integrated manner.
  • failure response tasks are classified into common and individual tasks, and parent scenarios and child scenarios are defined for the classified tasks to divide the scenarios, and the scenarios are straddled based on the relationships and status between each scenario (parent scenario).
  • it manages and interrupts or changes the scenario according to the failure response process / content. This makes it possible to select the next suitable scenario according to the result of each process (scenario).
  • ripple ALM by interrupting the scenario at the time when it is estimated that the ripple is from the main factor, unnecessary processing can be omitted and efficient processing becomes possible.
  • FIG. 2 is a block diagram showing the configuration of the automatic cooperation device 30.
  • the automatic cooperation device 30 includes a business API unit 31, a scenario management execution unit 32, a business resource management unit 33, an adapter unit 34, a status management DB 30A, a scenario cooperation management unit 30B, and the like. It includes a scenario cooperation control unit 30C, a parent scenario generation unit 30D, an API generation history DB 30E, a scenario selection / change unit 30F, and a scenario selection rule DB 30G.
  • the business API unit 31 receives an order request for troubleshooting, and processes the API according to the content of the request so that the scenario management execution unit 32 executes an appropriate scenario.
  • the order request for troubleshooting is issued by the operator when the device alarm is issued, or the system receives the device alarm, analyzes the alarm message, and automatically issues the late request.
  • the scenario management execution unit 32 manages and executes individual scenarios.
  • the business resource management unit 33 manages business resources.
  • the adapter unit 34 is connected to the servers 41, 51, 61 of the wholesale service providers 40, 50, 60.
  • the status management DB 30A is a database that manages the status for each scenario (countermeasure ALM).
  • the scenario cooperation management unit 30B manages relationships, statuses, etc. between scenarios.
  • the scenario cooperation control unit 30C executes control across scenarios.
  • the parent scenario generation unit 30D automatically generates a parent scenario.
  • the ALM occurrence history DB30E is a database that manages the ALM occurrence history.
  • the scenario selection / change unit 30F selects and combines an appropriate scenario from a plurality of scenarios with reference to the scenario selection rule DB 30G.
  • the scenario selection rule DB30G is a database that manages scenario selection rules.
  • the scenario management execution unit 32 includes a batch construction scenario 32a, a failure response scenario 32b, a response A scenario 32c, a response B scenario 32d, and the like. These are also simply referred to as scenarios 32s. Each scenario 32s is realized by API.
  • the failure response scenario 32b corresponds to the parent scenario shown in FIG. Further, as the coping A scenario 32c, the “coping A scenario” in the “individual work child scenario” shown in FIG. 4 corresponds.
  • the business resource management unit 33 includes a catalog management unit 36 and a cooperation rule management unit 35.
  • the catalog management unit 36 manages the catalog. Each catalog is used at the time of execution processing in the scenario management execution unit 32.
  • the cooperation rule management unit 35 manages the cooperation rule. Each cooperation rule is used at the time of execution processing in the scenario management execution unit 32.
  • the status management DB 30A, the scenario cooperation management unit 30B, and the scenario cooperation control unit 30C may be collectively referred to as the "scenario cooperation unit 200".
  • the parent scenario generation unit 30D, the ALM occurrence history DB 30E, the scenario selection / change unit 30F, and the scenario selection rule DB 30G may be collectively referred to as the “scenario creation unit 100”. It may be considered that the scenario creation unit 100 includes a failure response scenario 32b, a response A scenario 32c, and a response B scenario 32d.
  • a new functional unit (scenario cooperation unit 200) is provided to manage the relationship and status between each scenario and instruct control such as interruption and change for each scenario. Therefore, cooperation between scenarios will be realized, and failure handling will be made more efficient. It is the scenario cooperation management unit 30B that determines the scenario interruption / change, and the scenario cooperation control unit 30C that controls the scenario interruption / change. In addition, by dividing the scenario (cooperation rule) and newly providing a function unit (scenario creation unit 100) for selecting / changing the scenario, not only can the scenario be flexibly changed according to the situation, but also scenario management. The amount of cooperation scenarios read by the execution unit 32 is reduced, and performance is improved.
  • FIG. 3 is a diagram showing a failure handling business flow and an example of each process constituting the flow.
  • the occurrence of device alarms is used as a trigger to disassemble and sort the alarms, isolate the failure, estimate the suspected location, perform pre-confirmation before countermeasures, implement countermeasures, and post-confirm after countermeasures. .. It is necessary to determine the implementation content of the next process according to the processing result in each work process.
  • ALM occurrence is used as a trigger for a failure response scenario, but a user report or anomaly detection of traffic may be used as a trigger.
  • step S1 when an alarm occurs, the alarm is first disassembled and sorted, and key information required in the subsequent steps is collected (steps S1 ⁇ S2).
  • step S2 the construction status is confirmed, and if the construction is underway, the construction is completed, and if the construction is not underway, the suspected failure location is narrowed down (steps S3 ⁇ S4).
  • the failure-related list create a suspected device list, narrow down the suspected device, narrow down the suspected part, and the like.
  • step S5 a preliminary confirmation before the countermeasure is performed.
  • the handling history is confirmed, the failure handling status is confirmed, the device status is confirmed, the user report is confirmed, the traffic status is confirmed, and the failure history of the lower layer is confirmed.
  • a coping decision is made (step S6). For example, the necessity / content of countermeasures is selected / determined from the result of the prior confirmation scenario and the judgment rule. Then, a countermeasure is taken (step S7). For example, request analysis, arrange on-site, arrange spare equipment, create well-known text, etc. Finally, post-confirmation is performed (step S8). For example, ALM occurrence history confirmation, device status confirmation, user declaration confirmation, traffic status confirmation, and the like are performed.
  • the failure handling business flow is an example, and each process may be added / deleted or the order of the processes may be changed.
  • FIGS. 4A and 4B are conceptual diagrams in the case of automatically creating a parent scenario and classifying child scenarios.
  • the failure handling work is classified into common / individual work, and a part of the classified work is made into a child scenario to realize the division of the cooperation rule.
  • Business classification and division of cooperation rules may be performed manually.
  • the parent scenario generation unit 30D automatically creates the parent scenario.
  • Common work is a work item that is commonly performed regardless of the content of the failure, and it is considered that the frequency of correction of the work content (scenario) is low. Therefore, the maintainer should focus on creating / editing the scenario of the individual work. Further, since the common work is not a sequential process, it is possible to further improve the performance by performing the parallel process.
  • the common work refers to the failure handling work that is generally required for all failure patterns. For example, the occurrence of a device alarm (ALM) triggers the start of failure handling work. In any failure, it is necessary to disassemble the ALM and analyze why the ALM occurred, which device issued the ALM, etc., so it is classified as a common work.
  • the individual work refers to a failure handling work determined for each failure pattern.
  • the scenario refers to a scenario defined as a series of operations by combining two or more failure response operations (common work / individual work). Rules such as passing parameters between each work are described in the cooperation rule.
  • the parent scenario refers to a combination of two or more scenarios (defined as a child scenario) and failure response work, and defined as a series of work.
  • common work is defined in advance as a common item of all parent scenarios.
  • Child scenarios sinarios for narrowing down suspected failure locations, countermeasure scenarios
  • DB30G the "scenario selection rule DB30G” defined in advance while proceeding with countermeasures, and the parent scenario.
  • FIG. 5 is a flowchart showing an operation example when determining whether or not to execute a coping scenario and which coping scenario to execute.
  • the automatic cooperation device 30 receives the result of the pre-confirmation scenario for each ALM, it determines whether or not a countermeasure is necessary for each ALM (steps S11 ⁇ S12). At this time, if it is determined that immediate action is required, the rule ID associated with the ALM ID is extracted, the action method and the current execution order are selected and determined, and the action is executed (step S13 ⁇ S14 ⁇ S15 ⁇ S16).
  • step S17 the type and number of occurrences of the ALM within a certain period of time are counted (step S17 ⁇ S18), and the process returns to step S12 for determining the necessity of the countermeasure for each ALM. If it is determined that no action is required, the process ends without taking any action (step S19).
  • FIG. 6 shows the items and output list of the pre-confirmation scenario.
  • FIG. 7 shows the primary judgment condition ID for each ALM and the result list. If the ALM ID is "-", it means that it applies to all ALMs.
  • FIG. 8 shows the primary judgment conditions for the necessity of countermeasures based on the output combination of the prior confirmation scenario. If the output value of the item number is "-”, it means that the output value is arbitrary.
  • the conditions necessary for the necessity of countermeasures and the content judgment are prepared and registered in advance from the implementation results of each item described in the prior confirmation scenario.
  • FIG. 9 shows a method of determining the content of a coping scenario (selection of a coping scenario).
  • Selection of a coping scenario Prepare and register in advance the conditions necessary for determining the necessity of countermeasures and content judgment (secondary judgment) using the ALM occurrence history.
  • the ALM that has been put on hold as a result of the primary judgment is linked to the action content / scenario in light of the above conditions.
  • An ALM ID is defined for each device ALM that is subject to failure handling.
  • the combination of the output patterns of each action item in the prior confirmation scenario is defined as the primary judgment condition for the necessity of countermeasures, and an ID is assigned.
  • the primary judgment result by the combination of the ALM ID and the primary judgment condition ID is defined.
  • the ALM ID, the primary judgment condition ID, the action content according to the primary judgment result, and the action scenario ID associated with the action content are defined in advance. If necessary, describe the ALM occurrence history condition, and define the countermeasure content, secondary judgment, and countermeasure scenario ID in consideration of the condition.
  • Failure ALMs may occur by affecting each other. For example, it is conceivable that a failure ALM (spillover ALM) will occur in the transfer layer due to the spread of the failure that occurs in the transmission layer. In this case, the failure response scenario is activated for each ALM generated in the transmission layer and the transfer layer, but when the ALM on the transfer layer side is determined to be a ripple ALM, the failure response scenario on the transfer layer side is interrupted or Change the scenario. As a result, it is possible to omit unnecessary processing that is originally unnecessary and to carry out efficient processing.
  • a failure ALM spikeover ALM
  • FIG. 10 shows a scenario interruption (case 1) due to layer cooperation.
  • the transfer layer has a ripple effect
  • the transmission layer notifies the transfer layer (service for mass) to that effect (A2).
  • the transmission layer continues to deal with it (A3-1).
  • processing is continued until "preliminary confirmation” and then interrupted (A3-2). Further, depending on the result of the subsequent confirmation on the transmission layer side, the processing interruption of the transfer layer may be restored (A3).
  • FIG. 11 shows a scenario change (case 2) due to layer cooperation.
  • the transfer layer has a ripple effect
  • the transmission layer notifies the transfer layer (corporate service) to that effect (B2).
  • the transmission layer continues to deal with it (B3-1).
  • some measures in the middle are skipped and only "well-known B” is implemented (B3-2).
  • B3-2 it is estimated that the external device "has spread to the transfer layer” in the process of "narrowing down the suspected failure location” in the scenario on the transmission layer side.
  • FIG. 12 is a flowchart showing an operation example of the automatic cooperation device 30.
  • an operation example of the automatic cooperation device 30 in Case 1 will be described with reference to FIGS. 10 and 12.
  • the adapter unit 34 receives information indicating "there is a spread to the transfer layer", which is the estimation result, from the external suspected part estimation system, and notifies the scenario execution management unit 32 (step S21).
  • the scenario management execution unit 32 writes the countermeasure result and status of the "failure suspected location narrowing down" process into the status management DB 30A (step S22), and scenarios the information indicating "spillover to the transfer layer” and the ripple ALM information.
  • the cooperation management unit 30B acquires the scenario status information and the like for the notified ripple ALM information from the status management DB 30A (step S24).
  • the scenario cooperation management unit 30B acquires the corresponding countermeasure rule information for the ripple ALM from the scenario selection rule DB 30G (step S25).
  • the scenario cooperation management unit 30B determines the interruption of the scenario for the corresponding ripple ALM from the status of the running scenario and the referenced rule, and notifies the scenario cooperation control unit 30C (step S26).
  • the scenario cooperation control unit 30C executes an interrupt order for scenario interruption for the corresponding ripple ALM (step S27).
  • the scenario management execution unit 32 executes the interruption of the corresponding ripple ALM scenario (step S28).
  • the adapter unit 34 executes the interruption of the corresponding transfer layer side scenario (step S29).
  • step S25 corresponds to "Confirmation of failure history of lower layer: Yes" in FIG.
  • the condition of item No. 60 in FIG. 6 is "whether a failure has occurred in the lower layer".
  • the primary determination condition 20 of FIG. 8 is applicable.
  • the primary judgment result with the primary judgment condition ID of 20 is "no action required", and the secondary judgment result is "finished”. Therefore, the scenario for ripple ALM is changed from running to ending (suspended).
  • the transmission layer side scenario notifies that there is a ripple ALM information (including ALM ID), etc.
  • the corresponding countermeasure rule information for the ripple ALM is acquired.
  • the interruption of the scenario for the corresponding ripple ALM is determined from the coping rule information (primary determination condition ID: 20 in FIG. 9).
  • FIG. 13 is a flowchart showing an operation example of the automatic cooperation device 30.
  • an operation example of the automatic cooperation device 30 in the case 2 will be described with reference to FIGS. 11 and 13.
  • steps S31 to S35 in FIG. 13 are the same as steps S21 to S25 in FIG.
  • the scenario cooperation management unit 30B instructs the scenario selection / change unit 30F to select / change the scenario
  • the scenario selection / change unit 30F responds to the corresponding ripple ALM from the status of the running scenario and the referenced rule.
  • Select a scenario (only known B is implemented) (step S36).
  • the scenario cooperation management unit 30B decides to change the scenario (implemented only for the well-known B) for the corresponding ripple ALM, and notifies the scenario cooperation control unit 30C (step S37).
  • the scenario cooperation control unit 30C executes an interrupt order for changing the scenario for the corresponding ripple ALM (step S38).
  • the scenario management execution unit 32 executes the change of the corresponding ripple ALM scenario (step S39).
  • the adapter unit 34 executes the change of the corresponding transfer layer side scenario (step S40).
  • step S36 corresponds to "Confirmation of failure history of lower layer: Yes" in FIG.
  • the condition of item No. 60 in FIG. 6 is "whether a failure has occurred in the lower layer".
  • the primary determination condition 90 in FIG. 8 is applicable.
  • the primary judgment result with the primary judgment condition ID of 90 is "immediate action required", and the action content is "well-known B". Therefore, the scenario (only known B is implemented) for the ripple ALM is changed.
  • the transmission layer side scenario notifies that there is a ripple ALM information (including ALM ID), etc.
  • the corresponding countermeasure rule information for the ripple ALM is acquired.
  • the change of the scenario for the corresponding ripple ALM is determined from the coping rule information (primary determination condition ID: 90 in FIG. 9).
  • FIG. 14 is a hardware configuration diagram of the automatic cooperation device 30.
  • the automatic linkage device 30 for example, includes a CPU (Central Processing Unit, processor) 301, a memory 302, a storage 303 (HDD: Hard Disk Drive, SSD: Solid State Drive), a communication device 304, and an input device 305.
  • a general-purpose computer system including an output device 306 can be used.
  • the memory 302 and the storage 303 are storage devices. In this computer system, each function of the automatic cooperation device 30 is realized by executing a predetermined program loaded on the memory 302 by the CPU 301.
  • the automatic cooperation device 30 may be mounted on one computer or may be mounted on a plurality of computers. Further, the automatic cooperation device 30 may be a virtual machine mounted on a computer.
  • the program for automatic linkage can be stored in a computer-readable recording medium such as HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), DVD (Digital Versatile Disc), or distributed via the network. You can also do it.
  • a computer-readable recording medium such as HDD, SSD, USB (Universal Serial Bus) memory, CD (Compact Disc), DVD (Digital Versatile Disc), or distributed via the network. You can also do it.
  • the automatic cooperation device 30 includes a scenario creation unit 100 for creating a scenario, a scenario cooperation unit 200 for linking scenarios, and a scenario management execution unit 32 for managing and executing scenarios. Is classified into common work and individual work, a parent scenario or child scenario is defined for a work group that combines the classified work or multiple work, the scenario is divided, the relationship between each scenario (parent scenario) and each It manages across scenarios from the execution status of the scenario, and suspends or changes the scenario according to the failure response process and contents. As a result, it is possible to provide the automatic cooperation device 30 that can be applied to the failure handling business.
  • next scenario is dynamically selected according to the result of each failure response process, and the scenario is interrupted or changed when it is estimated that the main cause of the failure is a ripple effect. This eliminates unnecessary processing and enables efficient processing.
  • the automatic cooperation device 30 executes a scenario creation step for creating a scenario, a scenario cooperation step for linking scenarios, and a scenario management execution step for managing and executing a scenario. Then, the failure response work is classified into common work and individual work, a parent scenario or child scenario is defined for the work group that combines the classified work or multiple work, the scenario is divided, and between each scenario (parent scenario). It manages across scenarios based on the relationship between the two and the execution status of each scenario, and suspends or changes the scenario according to the failure response process and contents. This makes it possible to provide an automatic cooperation method that can be applied to failure response work.
  • the automatic cooperation program according to the embodiment of the present invention is an automatic cooperation program that causes a computer to function as the automatic cooperation device 30. As a result, it is possible to provide an automatic cooperation program that can be applied to failure response work.
  • the embodiment of the present invention uses an orchestrator to automatically link maintenance operation systems and realize automation of failure handling operations.
  • a plurality of scenarios are divided into cooperation rules that require a huge amount of conditional branching, a plurality of child scenarios associated with the rules can be dynamically combined, and a plurality of scenarios are considered in consideration of the dependency between the scenarios. Enables straddling management and control. As a result, not only the failure handling work is automated, but also the performance of the orchestrator is improved.
  • a method of inter-scenario cooperation that controls from one scenario to the other (processing interruption / return from interruption) and changes the scenario in the middle between scenarios that have dependencies.
  • the cooperation rule is divided, a child scenario is generated for each divided cooperation rule, multiple child scenarios are dynamically selected and combined, and a parent scenario automatic creation method for generating a parent scenario for failure handling business automation is realized. ..
  • a child scenario classification method is realized in which pre-confirmation and post-confirmation scenarios are classified as common child scenarios, and failure suspected locations are narrowed down and countermeasure scenarios are classified as individual child scenarios.

Abstract

自動連携装置３０は、シナリオを作成するシナリオ作成部１００と、シナリオを連携させるシナリオ連携部２００と、シナリオを管理および実行するシナリオ管理実行部３２とを備え、故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、シナリオを分割し、各シナリオ間の関係性および各シナリオの実行ステータスからシナリオを跨いだ管理を行い、故障対応工程および内容に応じてシナリオの中断または変更を行う。

Description

自動連携装置、自動連携方法、および自動連携プログラム
　本発明は、自動連携装置、自動連携方法、および自動連携プログラムに関する。
　現在、ネットワーク（ＮＷ）サービス、クラウドサービス、及びアプリケーション（ＡＰＬ）サービスといった各種サービスを提供している卸サービス事業者が出て来ている。これに伴い、エンドユーザにサービスを提供するサービス事業者が、自社で資産を保有せずに卸サービス事業者が提供するサービスを組合せてサービス事業者の独自サービスを提供する形態も出て来ている。ＮＷサービスは、広域Ｌ２（イーサネット「登録商標」）サービス、ＩＰ-ＶＰＮ（Internet Protocol Virtual Private Network）サービス、ＭＶＮＯ（Mobile Virtual Network Operator）等のネットワークを利用したサービスである。クラウドサービスは、ＩａａＳ（Infrastructure as a Service）基盤等によるサービスである。ＡＰＬサービスは、必要な通信に係る機能を必要な分だけサービスとして利用するようにしたソフトウェアの提供形態によるサービスである。
　各々の卸サービス事業者は、１つの通信サービスをＡＰＩ（Application Programming Interface）で公開している。このため、ユーザに通信サービスを提供するサービス事業者は、例えば、ＮＷサービスの通信機能を使用したい場合、ＮＷサービスを公開するＡＰＩにアクセスする。また、クラウドサービスの通信機能を使用したい場合、クラウドサービスを公開するＡＰＩにアクセスする。また、ＡＰＬサービスの通信機能を使用したい場合、ＡＰＬサービスを公開するＡＰＩにアクセスする。このようにサービス事業者は、１つの卸サービス事業者が公開する１つの通信サービスを利用してユーザに提供している。
　この種の技術として、通信の卸サービスの仕様が記述されたカタログと、各種の通信サービスの連携を定めた連携ルールとを保持し、当カタログ及び連携ルールに基づき、サービスＡＰＩを一括に連携させて連携サービスを構築する装置が知られている（特許文献１参照）。特許文献１の技術によれば、通信のサービス事業者のオーダ要求に応じて、複数の卸サービス事業者の各種通信サービスを組合せた連携サービスを一括で構築して提供することができる。
特開２０１８－３２８９７号公報
　特許文献１の技術（オーケストレータ）は、サービス構築業務に着目しているため、予め規定された固定的かつ条件分岐の少ない単純な業務フローに沿ったシステム連携は得意とするが、故障対応業務等の複雑な業務フローに沿ったシステム連携は不得意であるといった課題がある。すなわち、故障対応業務においては、各工程の結果に応じて次の工程の内容／方法が変わるため、流動的かつ条件分岐の多い複雑な業務フローとなる。従来技術を適用する場合、カタログ／連携ルール（シナリオ）に、網羅的な条件分岐を記した故障対応業務フローを規定する必要があるため、規定量が膨大になり、従来技術のシステム性能において劣化が生じる可能性がある。また、故障対応業務は、装置からのアラーム（ＡＬＭ）発出を契機に故障対応を開始する（シナリオを実行する）が、ＡＬＭ同士には依存関係（主要因ＡＬＭと波及ＡＬＭ等）が存在するため、ＡＬＭ毎に独立してシナリオを実行すればよいという訳ではない。例えば、伝送レイヤにて発生した故障が原因で、伝送レイヤに留まらず、上位レイヤである転送レイヤにおいてもＡＬＭが波及的に発生することがある。この場合、伝送レイヤのＡＬＭは主要因ＡＬＭ、転送レイヤのＡＬＭは波及ＡＬＭとなる。ＡＬＭ個々に対して、既にシナリオを実行している場合、転送レイヤ側の波及ＡＬＭに対するシナリオは中断、またはシナリオの内容を変更する必要がある。このように、複数シナリオ跨いだ管理・制御が必要であるが、従来技術では考慮されていない。以上より、従来技術では故障対応業務には適さない。
　本発明は、上記事情に鑑みてなされたものであり、本発明の目的は、故障対応業務に適用することが可能な自動連携装置、自動連携方法、および自動連携プログラムを提供することである。
　本発明の一態様の自動連携装置は、シナリオを作成するシナリオ作成部と、前記シナリオを連携させるシナリオ連携部と、前記シナリオを管理および実行するシナリオ管理実行部とを備え、故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、前記シナリオを分割し、各シナリオ間の関係性および各シナリオの実行ステータスから前記シナリオを跨いだ管理を行い、故障対応工程および内容に応じて前記シナリオの中断または変更を行う。
　本発明の一態様の自動連携方法は、自動連携装置が、シナリオを作成するシナリオ作成ステップと、前記シナリオを連携させるシナリオ連携ステップと、前記シナリオを管理および実行するシナリオ管理実行ステップとを実行し、故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、前記シナリオを分割し、各シナリオ間の関係性および各シナリオの実行ステータスから前記シナリオを跨いだ管理を行い、故障対応工程および内容に応じて前記シナリオの中断または変更を行う。
　本発明の一態様は、上記自動連携装置として、コンピュータを機能させる自動連携プログラムである。
　本発明によれば、故障対応業務に適用することが可能な自動連携装置、自動連携方法、および自動連携プログラムを提供することができる。
図１は、本発明の実施形態の通信システムの全体を示す構成図である。 図２は、自動連携装置の構成を示すブロック図である。 図３は、故障対応業務フローと、当該フローを構成する各工程の例を示す図である。 図４Ａは、親シナリオ自動作成、子シナリオ分類を行う場合の概念図である。 図４Ｂは、親シナリオ自動作成、子シナリオ分類を行う場合の概念図である。 図５は、対処シナリオの実行要否、および、どの対処シナリオを実行するかを判断する場合の動作例を示すフローチャートである。 図６は、事前確認シナリオの項目と出力一覧を示す図である。 図７は、ＡＬＭ別一次判断条件ＩＤと結果一覧を示す図である。 図８は、事前確認シナリオの出力組み合わせによる、対処要否の一次判断条件を示す図である。 図９は、対処シナリオの内容判断方法（対処シナリオの選択）を示す図である。 図１０は、レイヤ連携によるシナリオ中断（ケース１）を示す図である。 図１１は、レイヤ連携によるシナリオ変更（ケース２）を示す図である。 図１２は、自動連携装置の動作例を示すフローチャートである。 図１３は、自動連携装置の動作例を示すフローチャートである。 図１４は、自動連携装置のハードウェア構成図である。
　以下、図面を参照して、本発明の実施形態を説明する。図面の記載において同一部分には同一符号を付し説明を省略する。
　［実施形態］
　本発明の実施形態は、保全系オペレーションシステムの自動連携技術に関する。オーケストレータを用いて、保全系オペレーションシステム群を自動連携することで、単純系故障に関する故障対応業務を自動化し、オペレータの稼働削減を目指す。
　具体的には、膨大な条件分岐を要する連携ルールを分割し、これに紐づく子シナリオを動的に複数組み合わせることを可能とする。また、シナリオ間の依存関係を考慮した、複数シナリオを跨いだ管理・制御を可能とする。その結果、故障対応業務を自動化するだけでなく、オーケストレータの性能向上を実現する。
　（通信システムの全体構成）
　図１は、本発明の実施形態の通信システム１０の全体を示す構成図である。この通信システム１０は、サービス事業者２０の端末機２１と、自動連携装置３０と、複数の卸サービス事業者４０，５０，６０のサーバ４１，５１，６１とを備える。サービス事業者２０の端末機２１は、ＮＷ（ネットワーク）８１及びＧＷ（ゲートウェイ）７１を介して自動連携装置３０に接続されている。自動連携装置３０は、ＮＷ８２及びＧＷ７２，７３，７４を介して各卸サービス事業者４０，５０，６０のサーバ４１，５１，６１に接続されている。サーバ４１とサーバ５１とは、ＧＷ７５、ＮＷ８３及びＧＷ７６を介して接続されている。サーバ５１とサーバ６１とは、ＧＷ７７、ＮＷ８４及びＧＷ７８を介して接続されている。
　端末機２１と自動連携装置３０間のＧＷ７１は、端末機２１からの通信サービスの注文であるオーダ要求が予め許可された要求か否かを判断する処理を行う。自動連携装置３０は、許可されたオーダ要求の場合、そのオーダ要求に応じた１又は複数の通信サービスを取得する等の要求をサーバ４１，５１，６１へ送信する。自動連携装置３０と各卸サービス事業者４０，５０，６０間のＧＷ７２，７３，７４は、サーバ４１，５１，６１への要求が、予め許可された自動連携装置３０からの要求であるか否かを判断する処理を行う。各サーバ４１，５１，６１間のＧＷ７５～７８は、各サーバ４１，５１，６１をＮＷ８３，８４で接続するための認証処理を行う。
　各卸サービス事業者４０，５０，６０は、各々が異なる通信サービスをＡＰＩで公開している。卸サービス事業者４０のサーバ４１には、ＮＷサービスを公開するＮＷサービスＡＰＩ４１ａが搭載されている。卸サービス事業者５０のサーバ５１には、クラウドサービスを公開するクラウドサービスＡＰＩ５１ａが搭載されている。卸サービス事業者６０のサーバ６１には、ＡＰＬ（アプリケーション）サービスを公開するＡＰＬサービスＡＰＩ６１ａが搭載されている。
　サービス事業者２０は、各卸サービス事業者４０，５０，６０が公開する各種の通信サービスを１又は複数利用して独自の通信サービスをユーザに提供する。サービス事業者２０が通信サービスを利用する場合、自動連携装置３０に１又は複数の通信サービスを取得するためのオーダ要求を行って通信サービスを取得する。
　特許文献１の技術では、ＡＰＩを介して、複数の卸サービスを連携させる。一方、本発明の実施形態では、ＡＰＩを介して、複数のオペレーションシステムを連携させる。
　自動連携装置３０は、各種通信サービスのＡＰＩ４１ａ，５１ａ，６１ａを統合的に制御する。また、故障対応業務を共通、個別作業に分類し、分類した作業に対し親シナリオ、子シナリオを定義してシナリオを分割すると共に、各シナリオ（親シナリオ）間の関係性やステータスからシナリオを跨いだ管理を行い、故障対応工程／内容に応じてシナリオの中断や変更等を行う。これにより、各工程（シナリオ）の結果に応じて、適した次のシナリオを選択可能とする。また、波及ＡＬＭに対しても、主要因からの波及との推定された時点でシナリオを中断することで、不要な処理を省き効率的な処理を可能とする。
　（自動連携装置の構成）
　図２は、自動連携装置３０の構成を示すブロック図である。自動連携装置３０は、図２に示すように、業務ＡＰＩ部３１と、シナリオ管理実行部３２と、業務リソース管理部３３と、アダプタ部３４と、ステータス管理ＤＢ３０Ａと、シナリオ連携管理部３０Ｂと、シナリオ連携制御部３０Ｃと、親シナリオ生成部３０Ｄと、ＡＬＭ発生履歴ＤＢ３０Ｅと、シナリオ選択／変更部３０Ｆと、シナリオ選択ルールＤＢ３０Ｇとを備える。
　業務ＡＰＩ部３１は、故障対応のオーダ要求を受け付け、要求内容に応じたＡＰＩの処理により、シナリオ管理実行部３２で適切なシナリオが実行されるようにする。例えば、故障対応のオーダ要求は、装置アラームの発出を契機にオペレータが発行するか、もしくは、装置アラームをシステムが受信し、アラームメッセージ等を分析の上、自動で故発行する。シナリオ管理実行部３２は、個々のシナリオを管理・実行する。業務リソース管理部３３は、業務リソースを管理する。アダプタ部３４は、各卸サービス事業者４０，５０，６０のサーバ４１，５１，６１に接続されている。ステータス管理ＤＢ３０Ａは、シナリオ（対処ＡＬＭ）別にステータスを管理するデータベースである。シナリオ連携管理部３０Ｂは、シナリオ間の関係性やステータス等を管理する。シナリオ連携制御部３０Ｃは、シナリオを跨いだ制御を実施する。親シナリオ生成部３０Ｄは、親シナリオを自動生成する。ＡＬＭ発生履歴ＤＢ３０Ｅは、ＡＬＭ発生履歴を管理するデータベースである。シナリオ選択／変更部３０Ｆは、シナリオ選択ルールＤＢ３０Ｇを参照して複数のシナリオの中から適切なシナリオを選択・組合せる。シナリオ選択ルールＤＢ３０Ｇは、シナリオ選択ルールを管理するデータベースである。
　シナリオ管理実行部３２は、一括構築シナリオ３２ａ、故障対応シナリオ３２ｂ、対処Ａシナリオ３２ｃ、対処Ｂシナリオ３２ｄ等を備える。これらは単に、シナリオ３２ｓとも称す。各シナリオ３２ｓは、ＡＰＩで実現される。なお、故障対応シナリオ３２ｂとしては、図４に示される親シナリオが該当する。また、対処Ａシナリオ３２ｃとしては、図４に示される「個別作業 子シナリオ」の中の「対処Ａシナリオ」が該当する。
　業務リソース管理部３３は、カタログ管理部３６及び連携ルール管理部３５を備える。カタログ管理部３６は、カタログを管理している。各カタログは、シナリオ管理実行部３２での実行処理時に用いられる。連携ルール管理部３５は、連携ルールを管理している。各連携ルールは、シナリオ管理実行部３２での実行処理時に用いられる。
　なお、以下の説明では、ステータス管理ＤＢ３０Ａと、シナリオ連携管理部３０Ｂと、シナリオ連携制御部３０Ｃとを一括して「シナリオ連携部２００」という場合がある。また、親シナリオ生成部３０Ｄと、ＡＬＭ発生履歴ＤＢ３０Ｅと、シナリオ選択／変更部３０Ｆと、シナリオ選択ルールＤＢ３０Ｇとを一括して「シナリオ作成部１００」という場合がある。シナリオ作成部１００には、故障対応シナリオ３２ｂ、対処Ａシナリオ３２ｃ、対処Ｂシナリオ３２ｄが含まれると考えてもよい。
　このように、本実施の形態では、各シナリオ間の関係性やステータスを管理し、個々のシナリオに対して中断や変更等の制御を命令する機能部（シナリオ連携部２００）を新たに設けることで、シナリオ間の連携を実現させ、故障対応を効率化させる。シナリオ中断／変更を決定するのはシナリオ連携管理部３０Ｂであり、シナリオ中断／変更の制御を実施するのはシナリオ連携制御部３０Ｃである。また、シナリオ（連携ルール）を分割し、シナリオを選択／変更する機能部（シナリオ作成部１００）を新規に設けることで、状況に応じて柔軟にシナリオを変更可能とするだけでなく、シナリオ管理実行部３２が読み取る連携シナリオの量を削減し、性能の向上を実現する。
　（故障対応業務フローの例）
　図３は、故障対応業務フローと、当該フローを構成する各工程の例を示す図である。故障対応業務では、装置アラームの発生等をトリガーとして、アラームの分解・選別、故障切り分け、被疑箇所の推定、対処前の事前確認、対処実施、対処後の事後確認等の作業を実施している。各作業工程での処理結果に応じて、次の工程の実施内容を判断する必要がある。ここでは、「ＡＬＭ発生」を故障対応シナリオのトリガーとしているが、ユーザ申告やトラヒックの異常検知をトリガーとしてもよい。
　具体的には、図３に示すように、まず、アラームが発生すると、そのアラームを分解・選別し、以降の工程で必要なｋｅｙ情報を収集する（ステップＳ１→Ｓ２）。次いで、工事状況を確認し、工事実施中である場合は終了し、工事実施中でない場合は故障被疑箇所を絞り込む（ステップＳ３→Ｓ４）。例えば、故障関連リスト参照、被疑装置リスト作成、被疑装置絞り込み、被疑部位絞り込み等を行う。次いで、対処前の事前確認を行う（ステップＳ５）。例えば、対処履歴確認、故障対応状況確認、装置状態確認、ユーザ申告確認、トラヒック状態確認、下位レイヤの故障履歴確認等を行う。次いで、対処判断を行う（ステップＳ６）。例えば、事前確認シナリオの結果と判断ルールから対処要否・内容を選択・決定する。次いで、対処を行う（ステップＳ７）。例えば、解析依頼、現地手配、予備機手配、周知文作成等を行う。最後に、事後確認を行う（ステップＳ８）。例えば、ＡＬＭ発生履歴確認、装置状態確認、ユーザ申告確認、トラヒック状態確認等を行う。尚、当該故障対応業務フローは一例であり、各工程を追加/削除したり、工程の順序を入れ替えたりする場合もある。
　（親シナリオ自動作成方法、子シナリオ分類方法）
　図４Ａおよび図４Ｂは、親シナリオ自動作成、子シナリオ分類を行う場合の概念図である。図４Ａおよび図４Ｂに示すように、故障対応業務を共通／個別作業に分類し、分類した作業の一部を子シナリオ化することで連携ルールの分割を実現する。業務の分類、連携ルールの分割（子連携ルールの作成）は人手で実施してもよい。親シナリオの自動作成は、親シナリオ生成部３０Ｄが実施する。共通作業は故障内容に因らず共通的に実施する作業項目であり、作業内容（シナリオ）の修正頻度は低いと考えられるため、保守者は個別作業のシナリオ作成/編集に注力すればよい。また、共通作業は、シーケンシャルな処理ではないため、並列処理することで、更なる性能の向上が実現できる。
　なお、共通作業とは、おおよそ全故障パターンに共通的に必要となる故障対応作業を指す。例えば、装置アラーム（ＡＬＭ）の発生は故障対応業務の開始トリガーとなる。どんな故障においても、ＡＬＭを分解し、なぜＡＬＭが発生したのか、どの装置がＡＬＭを出したのか等を解析する必要があるため、共通作業に分類される。また、個別作業とは、故障パターン毎に決まる故障対応作業を指す。また、シナリオとは、２つ以上の故障対応作業（共通作業／個別作業）を組み合わせ、一連の作業として定義したものを指す。各作業間のパラメータの引き渡し等のルールは、連携ルールに記載する。また、親シナリオとは、２つ以上のシナリオ（子シナリオと定義）、故障対応作業を組み合わせ、一連の作業として定義したものを指す。本実施の形態では、共通作業を全親シナリオの共通項目として予め定義しておく。個別作業に該当する子シナリオ（故障被疑箇所絞り込みシナリオ、対処シナリオ）は、対処を進める中で、予め定義しておいた「シナリオ選択ルールＤＢ３０Ｇ」を参照することで、自動で選択し、親シナリオを完成させる。
　（対処シナリオの実行要否判断方法、内容判断方法）
　対処シナリオの実行要否、および、どの対処シナリオを実行するかについては、事前確認シナリオの処理結果（一次判断）と、ＡＬＭ発生履歴（二次判断）を組み合わせて決定する必要がある。一次判断のみで対処シナリオの実行要否・内容を判断できる場合もあれば、二次判断まで必要となる場合がある。例えば、あるマイナーＡＬＭ（重要でないＡＬＭ）が１ヶ月以内に２回以上発生すればメジャーＡＬＭ（故障発生となる重要ＡＬＭ）が発生する、といった経験値（もしくは装置仕様）があるとする。この場合は、当該マイナーＡＬＭが１回しか発生していなければ「対処保留」、１ヶ月以内に２回以上発生すれば、たとえ前記メジャーＡＬＭが発生していない場合でも「対処要」となる。
　図５は、対処シナリオの実行要否、および、どの対処シナリオを実行するかを判断する場合の動作例を示すフローチャートである。図５に示すように、まず、自動連携装置３０は、ＡＬＭ毎の事前確認シナリオの結果を受領すると、ＡＬＭ毎に対処要否を判断する（ステップＳ１１→Ｓ１２）。このとき、即時対処要と判断した場合は、ＡＬＭ ＩＤに紐づくルールＩＤを抽出し、対処方法と当実行順序を選択・決定し、対処を実行する（ステップＳ１３→Ｓ１４→Ｓ１５→Ｓ１６）。また、対処保留と判断した場合は、一定時間内における発生ＡＬＭの種別と回数をカウントし（ステップＳ１７→Ｓ１８）、ＡＬＭ毎に対処要否を判断するステップＳ１２に戻る。また、対処不要と判断した場合は、対処を実行することなく終了する（ステップＳ１９）。
　図６は、事前確認シナリオの項目と出力一覧を示している。図７は、ＡＬＭ別一次判断条件ＩＤと結果一覧を示している。ＡＬＭ ＩＤが“－”であるものは、全てのＡＬＭに適用という意味である。図８は、事前確認シナリオの出力組み合わせによる、対処要否の一次判断条件を示している。項番の出力値が“－”であるものは、出力値は任意という意味である。図６～図８に示すように、事前確認シナリオに記載されている各項目の実施結果から、対処要否・内容判断（一次判断）に必要な条件を事前に準備・登録しておく。
　図９は、対処シナリオの内容判断方法（対処シナリオの選択）を示している。ＡＬＭ発生履歴を用いた、対処要否・内容判断（二次判断）に必要な条件を事前に準備・登録しておく。一次判断の結果で「対処保留」になったＡＬＭについては、上記条件に照らし、対処内容／シナリオに紐付ける。
　これにより、以下の手順で対処シナリオの実行要否判断、内容判断を行う。
　（１）：故障対応の対象となる装置ＡＬＭ毎にＡＬＭ ＩＤを定義しておく。また、事前確認シナリオにおける各実施項目の出力パターンの組み合わせを対処要否の一次判断条件として定義し、ＩＤを付与する。ＡＬＭ ＩＤと一次判断条件ＩＤの組み合わせによる一次判断結果を定義しておく。
　（２）：（１）に該当するＡＬＭが発生した場合、事前確認シナリオを実行し、結果を保持する。
　（３）：（２）の結果に一致する一次判断条件ＩＤを導出し、ＡＬＭ ＩＤと併せ、一次判断結果を導出する。
　（４）：ＡＬＭ ＩＤ、一次判断条件ＩＤ、一次判断結果に応じた対処内容と、当該対処内容に紐付く対処シナリオＩＤを事前に定義しておく。必要に応じて、ＡＬＭ発生履歴条件を記載し、当該条件を考慮した対処内容、二次判断、対処シナリオＩＤを定義しておく。
　（５）：（３）の結果に応じた対処を実施する。二次判断が必要な場合は、条件に応じて対処を保留し、二次判断する。
　（シナリオ間連携方法）
　故障ＡＬＭは互いに影響し合って発生していることがある。例えば、伝送レイヤで発生した故障の波及により、転送レイヤでも故障ＡＬＭ（波及ＡＬＭ）が発生することが考えられる。この場合、伝送レイヤおよび転送レイヤで発生した各ＡＬＭに対して故障対応シナリオを発動するが、転送レイヤ側のＡＬＭが波及ＡＬＭと判断できた時点で、転送レイヤ側の故障対応シナリオを中断、もしくはシナリオを変更する。その結果、本来は不要である無駄な処理を省き、効率的な処理を実施することが可能となる。
　すなわち、従来技術では、個々のシナリオ管理しかできないため、波及ＡＬＭに対しても不要な処理が実施されてしまう。それに対して、本実施の形態では、シナリオを跨いだ管理を可能とするため、不要な処理の中止や、柔軟なシナリオ変更が可能となる。
　図１０は、レイヤ連携によるシナリオ中断（ケース１）を示している。図１０に示すように、伝送レイヤ側で「転送レイヤに波及あり」と推定し（Ａ１）、その旨を伝送レイヤから転送レイヤ（マス向けサービス）に通知する（Ａ２）。この場合、伝送レイヤでは対処継続する（Ａ３－１）。一方、転送レイヤでは「事前確認」まで処理継続し、以降は中断する（Ａ３－２）。また、伝送レイヤ側の事後確認の結果によっては、転送レイヤの処理中断を復帰させる（Ａ３）。
　図１１は、レイヤ連携によるシナリオ変更（ケース２）を示している。図１１に示すように、伝送レイヤ側で「転送レイヤに波及あり」と推定し（Ｂ１）、その旨を伝送レイヤから転送レイヤ（法人向けサービス）に通知する（Ｂ２）。この場合、伝送レイヤでは対処継続する（Ｂ３－１）。一方、転送レイヤでは途中の一部対処をスキップ、「周知Ｂ」のみ実施する（Ｂ３－２）。このケース２では、伝送レイヤ側のシナリオにおける「故障被疑箇所絞り込み」工程にて、外部装置が「転送レイヤに波及あり」と推定する。当該結果を受領したシナリオ管理実行部３２がシナリオ連携管理部３０Ｂに通知することで、転送レイヤ側のシナリオを変更することが可能となる。
　（動作例）
　図１２は、自動連携装置３０の動作例を示すフローチャートである。以下、図１０、図１２を参照しながら、ケース１における自動連携装置３０の動作例について説明する。
　まず、アダプタ部３４は、外部の被疑箇所推定システムから、推定結果である「転送レイヤへの波及あり」を示す情報を受け取り、シナリオ実行管理部３２へ通知する（ステップＳ２１）。次いで、シナリオ管理実行部３２は、「故障被疑箇所絞り込み」工程の対処結果やステータスをステータス管理ＤＢ３０Ａに書き込み（ステップＳ２２）、「転送レイヤへの波及あり」を示す情報と波及ＡＬＭ情報等をシナリオ連携管理部３０Ｂに通知する（ステップＳ２３）。次いで、シナリオ連携管理部３０Ｂは、通知された波及ＡＬＭ情報に対するシナリオのステータス情報等をステータス管理ＤＢ３０Ａから取得する（ステップＳ２４）。次いで、シナリオ連携管理部３０Ｂは、波及ＡＬＭに対する該当する対処ルール情報をシナリオ選択ルールＤＢ３０Ｇから取得する（ステップＳ２５）。次いで、シナリオ連携管理部３０Ｂは、実行中シナリオのステータスと、参照したルールから該当する波及ＡＬＭに対するシナリオの中断を決定し、シナリオ連携制御部３０Ｃに通知する（ステップＳ２６）。次いで、シナリオ連携制御部３０Ｃは、該当する波及ＡＬＭに対するシナリオ中断の割り込みオーダを実行する（ステップＳ２７）。次いで、シナリオ管理実行部３２は、該当する波及ＡＬＭシナリオの中断を実行する（ステップＳ２８）。最後に、アダプタ部３４は、該当する転送レイヤ側のシナリオの中断を実行する（ステップＳ２９）。
　なお、ステップＳ２５は、図６の「下位レイヤの故障履歴確認：有り」が該当する。ここでは、図６中の項番６０の条件は「下位レイヤに故障が発生しているか」となっている。この条件に対する出力が「有り」となる場合は、図８の一次判断条件２０が該当する。更に、図９に示すように、一次判断条件ＩＤが２０の一次判断結果は「対処不要」、二次判断結果は「終了」となっている。従って、波及ＡＬＭに対するシナリオは、実行中→終了（中断）と変更する。
　以上のように、伝送レイヤ側のシナリオから「波及あり」と波及ＡＬＭ情報（ＡＬＭ ＩＤ含む）等が通知されると、波及ＡＬＭに対する該当の対処ルール情報を取得する。これにより、対処ルール情報（図９の一次判断条件ＩＤ：２０）から、該当する波及ＡＬＭに対するシナリオの中断を決定するようになっている。
　図１３は、自動連携装置３０の動作例を示すフローチャートである。以下、図１１、図１３を参照しながら、ケース２における自動連携装置３０の動作例について説明する。
　まず、図１３のステップＳ３１～ステップＳ３５は、図１２のステップＳ２１～ステップＳ２５と同様である。ここで、シナリオ連携管理部３０Ｂがシナリオ選択／変更をシナリオ選択／変更部３０Ｆに指示を出すと、シナリオ選択／変更部３０Ｆは、実行中シナリオのステータスと、参照したルールから該当する波及ＡＬＭに対するシナリオ（周知Ｂのみ実施）を選択する（ステップＳ３６）。次いで、シナリオ連携管理部３０Ｂは、該当する波及ＡＬＭに対するシナリオ（周知Ｂのみ実施）の変更を決定し、シナリオ連携制御部３０Ｃに通知する（ステップＳ３７）。次いで、シナリオ連携制御部３０Ｃは、該当する波及ＡＬＭに対するシナリオ変更の割り込みオーダを実行する（ステップＳ３８）。次いで、シナリオ管理実行部３２は、該当する波及ＡＬＭシナリオの変更を実行する（ステップＳ３９）。最後に、アダプタ部３４は、該当する転送レイヤ側のシナリオの変更を実行する（ステップＳ４０）。
　なお、ステップＳ３６は、図６の「下位レイヤの故障履歴確認：有り」が該当する。ここでは、図６中の項番６０の条件は「下位レイヤに故障が発生しているか」となっている。この条件に対する出力が「有り」となる場合は、図８の一次判断条件９０が該当する。更に、図９に示すように、一次判断条件ＩＤが９０の一次判断結果は「即時対処要」、対処内容は「周知Ｂ」となっている。従って、波及ＡＬＭに対するシナリオ（周知Ｂのみ実施）の変更を実行する。
　以上のように、伝送レイヤ側のシナリオから「波及あり」と波及ＡＬＭ情報（ＡＬＭ ＩＤ含む）等が通知されると、波及ＡＬＭに対する該当の対処ルール情報を取得する。これにより、対処ルール情報（図９の一次判断条件ＩＤ：９０）から、該当する波及ＡＬＭに対するシナリオの変更を決定するようになっている。
　（自動連携装置のハードウェア構成例）
　図１４は、自動連携装置３０のハードウェア構成図である。自動連携装置３０には、例えば、CPU（Central Processing Unit、プロセッサ）３０１と、メモリ３０２と、ストレージ３０３（HDD：Hard Disk Drive、SSD：Solid State Drive）と、通信装置３０４と、入力装置３０５と、出力装置３０６とを備える汎用的なコンピュータシステムを用いることができる。メモリ３０２およびストレージ３０３は、記憶装置である。このコンピュータシステムにおいて、CPU３０１がメモリ３０２上にロードされた所定のプログラムを実行することにより、自動連携装置３０の各機能が実現される。
　なお、自動連携装置３０は、１つのコンピュータで実装されてもよく、あるいは複数のコンピュータで実装されても良い。また、自動連携装置３０は、コンピュータに実装される仮想マシンであっても良い。
　自動連携用のプログラムは、HDD、SSD、USB（Universal Serial Bus）メモリ、CD（Compact Disc）、DVD（Digital Versatile Disc）などのコンピュータ読取り可能な記録媒体に記憶することも、ネットワークを介して配信することもできる。
　（自動連携装置の特徴的な構成およびその効果）
　本発明の実施形態の自動連携装置３０は、シナリオを作成するシナリオ作成部１００と、シナリオを連携させるシナリオ連携部２００と、シナリオを管理および実行するシナリオ管理実行部３２とを備え、故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、シナリオを分割し、各シナリオ（親シナリオ）間の関係性および各シナリオの実行ステータスからシナリオを跨いだ管理を行い、故障対応工程および内容に応じてシナリオの中断または変更を行う。これにより、故障対応業務に適用することが可能な自動連携装置３０を提供することができる。
　具体的には、各故障対応工程の結果に応じて次のシナリオを動的に選択し、故障の主要因からの波及との推定された時点でシナリオを中断または変更する。これにより、不要な処理を省き効率的な処理を可能とする。
　また、本発明の実施形態の自動連携方法は、自動連携装置３０が、シナリオを作成するシナリオ作成ステップと、シナリオを連携させるシナリオ連携ステップと、シナリオを管理および実行するシナリオ管理実行ステップとを実行し、故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、シナリオを分割し、各シナリオ（親シナリオ）間の関係性および各シナリオの実行ステータスからシナリオを跨いだ管理を行い、故障対応工程および内容に応じてシナリオの中断または変更を行う。これにより、故障対応業務に適用することが可能な自動連携方法を提供することができる。
　また、本発明の実施形態の自動連携プログラムは、自動連携装置３０として、コンピュータを機能させる自動連携プログラムである。これにより、故障対応業務に適用することが可能な自動連携プログラムを提供することができる。
　以上説明したように、本発明の実施形態は、オーケストレータを用いて、保全系オペレーションシステム群を自動連携し、故障対応業務の自動化を実現する。本発明の実施の形態によれば、膨大な条件分岐を要する連携ルールを分割し、これに紐づく子シナリオを動的に複数組み合わせ可能とし、更にシナリオ間の依存関係を考慮した、複数シナリオを跨いだ管理・制御を可能とする。その結果、故障対応業務を自動化するだけでなく、オーケストレータの性能向上を実現する。
　具体的には、依存関係が存在するシナリオ間で、一方のシナリオから他方のシナリオへの制御（処理中断／中断復帰）や、シナリオの途中変更を実施するシナリオ間連携方法を実現する。また、連携ルールを分割し、分割した連携ルール毎に子シナリオを生成し、複数の子シナリオを動的に選択・組み合わせ、故障対応業務自動化の親シナリオを生成する親シナリオ自動作成方法を実現する。また、故障対応業務自動化の親シナリオにおいて、共通の子シナリオとして事前確認と事後確認シナリオ、個別の子シナリオとして故障被疑箇所絞り込みと対処シナリオに分類する子シナリオ分類方法を実現する。また、事前確認シナリオの処理結果（一次判断）とＡＬＭ発生履歴（二次判断）を組み合わせて、対処シナリオの実行要否を判断、並びに対処シナリオを選択する対処シナリオ実行要否・内容判断方法を実現する。
　３０　：自動連携装置
　３０Ａ：ステータス管理ＤＢ
　３０Ｂ：シナリオ連携管理部
　３０Ｃ：シナリオ連携制御部
　３０Ｄ：親シナリオ生成部
　３０Ｅ：ＡＬＭ発生履歴ＤＢ
　３０Ｆ：シナリオ選択／変更部
　３０Ｇ：シナリオ選択ルールＤＢ
　３１　：業務ＡＰＩ部
　３２　：シナリオ管理実行部
　３３　：業務リソース管理部
　３４　：アダプタ部
　１００：シナリオ作成部
　２００：シナリオ連携部
 

Claims (4)

  1. 　シナリオを作成するシナリオ作成部と、
    　前記シナリオを連携させるシナリオ連携部と、
    　前記シナリオを管理および実行するシナリオ管理実行部とを備え、
    　故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、前記シナリオを分割し、各シナリオ間の関係性および各シナリオの実行ステータスから前記シナリオを跨いだ管理を行い、故障対応工程および内容に応じて前記シナリオの中断または変更を行う自動連携装置。
  2. 　各故障対応工程の結果に応じて次のシナリオを動的に選択し、故障の主要因からの波及との推定された時点で前記シナリオを中断または変更する請求項１に記載の自動連携装置。
  3. 　自動連携装置が、
    　シナリオを作成するシナリオ作成ステップと、
    　前記シナリオを連携させるシナリオ連携ステップと、
    　前記シナリオを管理および実行するシナリオ管理実行ステップとを実行し、
    　故障対応業務を共通作業と個別作業に分類し、分類した作業または複数の作業を組み合わせた作業群に対し親シナリオまたは子シナリオを定義し、前記シナリオを分割し、各シナリオ間の関係性および各シナリオの実行ステータスから前記シナリオを跨いだ管理を行い、故障対応工程および内容に応じて前記シナリオの中断または変更を行う自動連携方法。
  4. 　請求項１または２に記載した自動連携装置として、コンピュータを機能させる自動連携プログラム。
PCT/JP2019/027002 2019-07-08 2019-07-08 自動連携装置、自動連携方法、および自動連携プログラム WO2021005686A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2021530378A JP7273341B2 (ja) 2019-07-08 2019-07-08 自動連携装置、自動連携方法、および自動連携プログラム
PCT/JP2019/027002 WO2021005686A1 (ja) 2019-07-08 2019-07-08 自動連携装置、自動連携方法、および自動連携プログラム
US17/625,382 US11775367B2 (en) 2019-07-08 2019-07-08 Automatic cooperation apparatus, automatic cooperation method and automatic cooperation program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2019/027002 WO2021005686A1 (ja) 2019-07-08 2019-07-08 自動連携装置、自動連携方法、および自動連携プログラム

Publications (1)

Publication Number Publication Date
WO2021005686A1 true WO2021005686A1 (ja) 2021-01-14

Family

ID=74114436

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2019/027002 WO2021005686A1 (ja) 2019-07-08 2019-07-08 自動連携装置、自動連携方法、および自動連携プログラム

Country Status (3)

Country Link
US (1) US11775367B2 (ja)
JP (1) JP7273341B2 (ja)
WO (1) WO2021005686A1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004080297A (ja) * 2002-08-15 2004-03-11 Ntt Docomo Inc 故障措置システム、及び、故障措置方法
JP2005045840A (ja) * 2004-10-18 2005-02-17 Fujitsu Ltd ネットワーク管理方法及びネットワーク管理システム
JP2010072834A (ja) * 2008-09-17 2010-04-02 Fujitsu Ltd 障害対処プログラム及び障害対処装置

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140279800A1 (en) * 2013-03-14 2014-09-18 Agincourt Gaming Llc Systems and Methods for Artificial Intelligence Decision Making in a Virtual Environment
US20150095101A1 (en) * 2013-10-01 2015-04-02 Omnex Systems, LLC Method and system for populating requirements
JP6441786B2 (ja) * 2015-12-04 2018-12-19 株式会社日立製作所 テスト支援装置、テスト支援方法、及びプログラム
JP6499622B2 (ja) 2016-08-22 2019-04-10 日本電信電話株式会社 事業者間一括サービス構築装置及び事業者間一括サービス構築方法
US20190287003A1 (en) * 2018-03-14 2019-09-19 Scaled Inference, Inc. Methods and systems for integrating speculative decision-making in cross-platform real-time decision-making systems

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004080297A (ja) * 2002-08-15 2004-03-11 Ntt Docomo Inc 故障措置システム、及び、故障措置方法
JP2005045840A (ja) * 2004-10-18 2005-02-17 Fujitsu Ltd ネットワーク管理方法及びネットワーク管理システム
JP2010072834A (ja) * 2008-09-17 2010-04-02 Fujitsu Ltd 障害対処プログラム及び障害対処装置

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
MORIMOTO, KENJI ET AL.: "Policy-based autonomous management system", IEICE TECHNICAL REPORT, vol. 105, no. 225, 28 July 2005 (2005-07-28), pages 25 - 30 *
NAKAJIMA, JUN ET AL.: "A feasibility study on applying the automation technology to IT system management", IEICE TECHNICAL REPORT, vol. 114, no. 523, 12 March 2015 (2015-03-12), pages 73 - 78 *

Also Published As

Publication number Publication date
JP7273341B2 (ja) 2023-05-15
US20220253349A1 (en) 2022-08-11
US11775367B2 (en) 2023-10-03
JPWO2021005686A1 (ja) 2021-01-14

Similar Documents

Publication Publication Date Title
US10819560B2 (en) Alert management system and method of using alert context-based alert rules
US10623269B2 (en) Operator fusion management in a stream computing environment
US8190599B2 (en) Stream data processing method and system
US11075798B2 (en) Configuration management in a stream computing environment
US8386636B2 (en) Business process system management method
US10164986B2 (en) Realized topology system management database
US20190306236A1 (en) Insight for cloud migration and optimization
US20080183876A1 (en) Method and system for load balancing
US9652295B2 (en) Runtime fusion of operators based on processing element workload threshold and programming instruction compatibility
US10862766B2 (en) Controller for a cloud based service in a telecommunications network, and a method of providing a cloud based service
US10642583B2 (en) Development data management for a stream computing environment
US20090282414A1 (en) Prioritized Resource Access Management
JP2007087232A (ja) システム構成変更によるポリシ修正を容易にするポリシ作成方法、及びポリシ管理方法
Gupta et al. A QoS-supported approach using fault detection and tolerance for achieving reliability in dynamic orchestration of web services
US10042736B2 (en) Breakpoint for predicted tuple processing time in a streaming environment
US20090089772A1 (en) Arrangement for scheduling jobs with rules and events
WO2021005686A1 (ja) 自動連携装置、自動連携方法、および自動連携プログラム
CN112639739A (zh) 在至少两个不同级别的平台的计算机上分发特定应用的子应用
US20230259405A1 (en) Resource management device, resource managementmethod, and resource management program
Zhang et al. Kubedim: Self-Adaptive Service Degradation of Microservices-Based Systems
Kowalkiewicz et al. Service composition enactment
JP2016157358A (ja) Ｄｒサイト切替先選定装置および方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19936738

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2021530378

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19936738

Country of ref document: EP

Kind code of ref document: A1