JP2014203138A - Electronic device, verification method, and verification program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To prevent erroneous operation of an electronic device by detecting invalid setting information generated in a setting device.SOLUTION: An electronic device that operates in accordance with setting information generated by a setting device comprises: acquisition means that acquires setting information; storage means that stores a function definition to be defined in setting information of the electronic device; verification means that verifies whether the function definition is defined in the setting information before starting operation; and operation control means that stops start of operation when the function definition is not defined in the setting information.

Description

  The present invention relates to an electronic device, a verification method, and a verification program.

  There is a system in which setting information is registered from an external setting device for a device in a predetermined facility via a network, and each device in the facility is controlled based on the setting information. For example, each device in the substation is constructed based on IEC 61850, which is an international standard, and is controlled based on setting information defined by IEC 61850. Examples of the equipment in the substation include a main device such as a switch, a driving device, a generator, or a transformer, and an electronic device that controls the main device (hereinafter referred to as IED: Intelligent Electronic Device).

  For example, there is a technique described in Patent Document 1 as a technique for controlling each device in a facility such as a substation. In the facility control system described in Patent Document 1, the function of a field device (for example, IED) is installed in a control station, and a communication link is formed between the device function and the control station to integrate field devices. .

JP 2001-202104 A

  In IEC61850, IED functions are represented by a template file called an ICD (IED Capability Description) file. Since the IED installed in the facility has each ICD file, when there are multiple vendor IEDs, each vendor company prepares its own IED ICD file.

  In system engineering of IEC 61850, first, an engineering tool called a system configurator is used. The system configurator reads the ICD files of each company IED in an integrated manner, and generates an SCD (System Configuration Description) file reflecting the settings of the entire system. In the SCD file, based on the contents of each company's ICD file, the setting values according to the overall system specifications are reflected for each IED. Therefore, the SCD file generated by the system configurator includes setting information set for each of all the IEDs installed in the facility.

  Next, when setting information is reflected on each IED installed in the facility, an engineering tool called an IED configurator is used. The IED configurator reads the SCD file generated by the system configurator, extracts the setting information of the target IED, and reflects the extracted setting information on the IED. The setting information to be reflected in each IED is output as a CID (Configured IED Description) file. Therefore, the IED configurator extracts the setting information of the target IED from the SCD file, generates a CID file, and sets the generated CID file for the IED.

  As described above, in the system engineering of IEC 61850, before setting information (CID file) for setting each IED is completed, an engineering tool such as a system configurator and an IED configurator is used.

  Here, when the SCD file is created by the system configurator, if the function definition of the IED imported from the vendor's ICD file is changed by mistake, the IED is appropriate if the setting information (CID file) is reflected in the IED. There is a problem that it can not work.

  Currently, no unified system configurator tool is provided, and the SCD file is created by an arbitrary system configurator tool. For this reason, when an SCD file is created by the system configurator, it is impossible to exclude the possibility that a logical node and its data item relating to the IED function definition are added or deleted by mistake.

  Also, when creating a CID file with the IED configurator, if the function definition of the IED imported from the SCD file is changed by mistake, the IED will operate properly if the setting information (CID file) is reflected in the IED. It may not be possible.

  In view of such a point, an embodiment of the present invention aims to prevent an electronic device from malfunctioning, and to provide an electronic device or the like that detects unauthorized setting information generated by a setting device. .

  An electronic device according to one aspect of the present invention is an electronic device that operates according to setting information generated by a setting device, and stores an acquisition unit that acquires setting information and a function definition to be defined by the setting information of the electronic device. Storage means, verification means for verifying whether or not the function definition is defined in the setting information before the start of operation, and an operation for stopping the operation start when the function definition is not defined in the setting information Control means.

  According to another aspect of the present invention, there is provided a verification method for setting information generated by a setting device, the procedure for acquiring setting information in the electronic device and the setting information of the electronic device from the storage means. A procedure for reading a function definition to be defined, a procedure for verifying whether or not the function definition is defined in the setting information before the start of operation, and an operation when the function definition is not defined in the setting information. And a procedure for canceling the start.

  Further, the verification program according to another aspect of the present invention provides an electronic device that operates according to the setting information generated by the setting device, an acquisition unit that acquires setting information, and a function definition that should be defined by the setting information of the electronic device. The stored storage means, the verification means for verifying whether or not the function definition is defined in the setting information before starting the operation, and the operation start is stopped when the function definition is not defined in the setting information. It functions as an operation control means.

  According to the disclosed technology, it is possible to detect unauthorized setting information generated by the setting device on the electronic device side.

1 is a diagram illustrating an example of a system configuration It is a figure which shows an example of the hardware constitutions of the system configurator 1 and the IED configurator 2. FIG. 2 is a block diagram illustrating an example of functions that the system configurator 1 has. It is a block diagram which shows an example of the function which IED configurator 2 has. It is a block diagram which shows an example of the function which IED3 has. It is a figure which shows an example of the ICD file of A company. It is a figure which shows an example of the ICD file of B company. It is a figure which shows an example of the ICD file of C company. It is a figure which shows an example of a SCD file. It is a figure which shows an example of a CID file. It is a figure which shows an example of a verification item table. It is a flowchart which shows an example of the CID file verification process of IED3.

  Hereinafter, embodiments for solving the above problems will be described with reference to the accompanying drawings.

[Example]
<System configuration>
FIG. 1 is a diagram illustrating an example of a system configuration in the embodiment. The control system shown in FIG. 1 includes a system configurator 1, an IED configurator 2, an IED (electronic device) 3, and a main device 4. In the substation 100, a main device 4 and an IED 3 for controlling the main device 4 are installed.

  The system configurator 1 is an overall setting device that configures the entire system. The system configurator 1 can be constructed, for example, by installing an engineering tool (software) called a system configurator on the hardware of a PC (Personal Computer).

  The IED configurator 2 is a setting device that configures each IED. The IED configurator 2 can be constructed by installing an engineering tool (software) called an IED configurator in, for example, PC hardware.

  The IED 3 is an intelligent electronic device having a processor and a communication function, and controls the main device 4. The IED 3 acquires setting information (for example, a CID file) from the IED configurator 2 and generates a data model for controlling the main device 4 based on the setting information. The IED 3 controls the device based on the setting value of the data model.

  The main device 4 is a device such as a switch, a drive device, a generator, or a transformer provided by a plurality of vendors. The main device 4 is controlled by the IED 3. The IED 3 and the main apparatus 4 are connected by a serial communication cable, a copper wire that transmits an analog signal or a digital (ON / OFF) signal, and the like.

  In normal cases, the IED 3 and the main device 4 in the substation 100 are often provided by a plurality of vendors such as A company, B company, and C company, for example. Each vendor company prepares an IED configurator 2 for setting its own IED for each vendor company.

<IEC61850 System Engineering>
Next, before describing the system engineering flow of the international standard IEC61850, the ICD file, SCD file, and CID file will be described first.

・ "ICD file"
The ICD file is a function definition file that describes and defines the functions of each IED in the XML format. Vendor companies submit the function definitions (specifications) of their IEDs as ICD files to the substation manager.

・ "SCD file"
The SCD file is a setting file that describes setting information of the entire substation system in the XML format. The SCD file is generated by the system configurator 1. The administrator of the substation 100 acquires each ICD file from each vendor and generates an SCD file using the system configurator 1. The SCD file is generated based on the ICD file that is a function definition file, and for each IED of each vendor company, the function definition possessed by the IED and the setting value assigned to operate the function defined by the function definition. Including.

  For example, when an IED of a vendor company has a network communication function, an IP address setting of the IED can be given as a setting value to be given. The administrator determines the IP address of each IED and describes it in the SCD file so that the network address does not overlap in the entire system.

  Further, for example, when the IED of each vendor company has a linkage function between the IEDs, the setting value to be given is a setting value related to the linkage. For example, according to the ICD file of company A, the ICD of company A has a function of sending an emergency notification by multicast. According to the ICD file of company B, the ICD of company B receives the emergency notification and issues an alarm. Suppose that it has a function of outputting. In this case, in order to realize the cooperation function, the IED of Company A needs to be set to send an emergency notification and the setting of notification conditions, and the IED of Company B receives an emergency notification from the IED of Company A. Settings to be performed and operation settings at the time of reception are required.

  In this way, the SCD file describes setting information for operating individual functions of each company's IED under the entire system.

・ "CID file"
The CID file is a setting file in which setting information for setting each IED is described in the XML format. The CID file is generated by the IED configurator 2. The vendors in charge of the vendor acquire the SCD file generated by the system configurator 1, import the acquired SCD file into the IED configurator 2, and then extract the setting information part of the company's IED 3 to generate the CID file To do. Since the CID file is an IED setting information file, the CID file includes a function definition possessed by the IED and a setting value assigned to operate a function defined by the function definition.

  Next, referring to FIG. 1 again, the system engineering flow of IEC 61850 will be described.

  (1) First, when an IED 3 of a plurality of vendors is installed in the substation 100, each vendor company prepares an ICD file of its own IED 3.

  (2) The manager of the substation 100 acquires each ICD file provided by each vendor, imports the acquired ICD file into the system configurator 1, and sets specific settings based on the system specifications of the entire substation. Assign values and create setting information for the entire substation system. Thereby, an SCD file is generated. The generated SCD file includes setting information set for each of all IEDs installed in the facility.

  (3) The person in charge of each vendor company acquires the SCD file generated by the system configurator 1, takes the acquired SCD file into the IED configurator 2, and then extracts the setting information portion of the company IED 3. Thereby, a CID file is generated.

  (4) The person in charge of each vendor uses the IED configurator 2 to set (register) the generated CID file in the company IED 3 via the network. Thereby, the setting of IED3 is completed. Note that an ICD file may be set for the company IED 3 via a portable storage medium or the like.

  (5) When the IED 3 acquires the CID file from the IED configurator 2, the IED 3 reflects the setting information on its own device based on the CID file. Thereafter, the IED 3 operates the own apparatus according to the setting information reflected in the own apparatus.

<Hardware configuration>
FIG. 2 is a diagram illustrating an example of a hardware configuration of the system configurator 1 and the IED configurator 2 in the embodiment. The system configurator 1 and the IED configurator 2 include a CPU 11, a ROM 12, a RAM 13, an HDD 14, a storage medium reading device 15, an input device 16, a display device 17, and a communication device 18 as main components. The system configurator 1 and the IED configurator 2 are realized by, for example, a PC having a display, a notebook PC, a server, or the like.

  The CPU 11 is composed of a microprocessor and its peripheral circuits, and is a circuit that controls the entire apparatus. The ROM 12 is a memory that stores a predetermined control program executed by the CPU 11. The RAM 13 is a memory used as a work area when the CPU 11 executes a predetermined control program stored in the ROM 12 to perform various controls.

  The HDD 14 is a device that stores various information including a general-purpose OS and various programs, and is a nonvolatile storage device. The storage medium reader 15 is a device that inputs information from an external storage medium such as a CD, DVD, or USB memory.

  The input device 16 is a device for a user to perform various input operations. The input device 16 includes a mouse, a keyboard, a touch panel switch provided so as to be superimposed on the display screen of the display device 17, and the like.

  The display device 17 is a device that displays various data on a display screen. For example, it is composed of LCD (Liquid Crystal Display), CRT (Cathode Ray Tube) and the like.

  The communication device 18 is a device that communicates with other devices via a network. Supports communication according to various network forms including wired and wireless networks.

<Functional configuration>
FIG. 3 is a block diagram illustrating an example of functions of the system configurator 1 in the embodiment. The system configurator 1 illustrated in FIG. 3 includes an ICD file acquisition unit 101, an SCD file generation unit 102, and a storage unit 103.

  The ICD file acquisition unit 101 acquires an ICD file of each IED 3 provided by each vendor. The ICD file acquisition unit 101 may acquire an ICD file via a network, a portable storage medium, or the like.

  The SCD file generation unit 102 takes in the ICD file, assigns specific setting values based on the system specifications of the entire substation, and generates setting information of the entire substation system, thereby generating an SCD file.

  The storage unit 103 stores the acquired ICD file, the generated SCD file, and the like.

  As described above, these functional units are realized by an engineering tool (software) executed on hardware resources such as a CPU, a ROM, and a RAM of a computer constituting the system configurator 1.

  FIG. 4 is a block diagram illustrating an example of functions of the IED configurator 2 in the embodiment. The IED configurator 2 illustrated in FIG. 4 includes an SCD file acquisition unit 201, a CID file generation unit 202, a CID file setting unit 203, and a storage unit 204.

  The SCD file acquisition unit 201 acquires the SCD file generated by the system configurator 1. The SCD file acquisition unit 201 may acquire the SCD file via a network, a portable storage medium, or the like.

  The CID file generation unit 202 generates a CID file to be set for a specific IED by extracting setting information about a specific IED (for example, IED 3a of company A) from the SCD file.

  The CID file setting unit 203 sets a CID file for a specific IED 3. The CID file setting unit 203 sets a CID file in the IED 3 via a network, a portable storage medium, or the like.

  The storage unit 204 stores the acquired SCD file, the generated CID file, and the like.

  As described above, these functional units are realized by an engineering tool (software) executed on hardware resources such as a CPU, a ROM, and a RAM of a computer constituting the IED configurator 2.

  FIG. 5 is a block diagram illustrating an example of functions of the IED 3 in the embodiment. The IED 3 illustrated in FIG. 5 includes a CID file acquisition unit 301, a CID file verification unit 302, an operation control unit 303, an alarm unit 304, and a storage unit 305.

  The CID file acquisition unit 301 acquires the CID file generated by the IED configurator 2. The CID file acquisition unit 301 can acquire a CID file via a network, a portable storage medium, or the like.

  The CID file verification unit 302 reads, for example, the CID file when the IED 3 is activated, and verifies whether or not the function items for operating the functions necessary for the operation control of the IED 3 are correctly defined. That is, the CID file verification unit 302 changes the data item (function item) setting to an invalid item or value when the CID file is generated by the system configurator 1 or the IED configurator 2 in order to prevent malfunction of the IED 3. Verify whether they are not equal.

  When the verification result of the CID file verification unit 302 is determined to be normal, the operation control unit 303 controls and operates the main device 4 based on the verified CID file. However, if the verification result is determined to be abnormal (unauthorized), the operation is not performed based on the CID file.

  When the verification result of the CID file verification unit 302 is determined to be abnormal (unauthorized), the alarm unit 304 outputs an alarm to the user using, for example, light emission, voice, or other notification methods. The alarm notifies the user that the CID file set in the IED 3 is abnormal (unauthorized) and warns the user.

  The storage unit 305 stores the acquired CID file, a verification item table described later, and the like.

  As described above, these functional units are realized by an IED control program executed on hardware resources such as a CPU, a ROM, and a RAM of a computer configuring the IED 3.

<Various data>
Next, specific examples of various data used in the embodiment will be described.

(ICD file)
FIG. 6 is a diagram illustrating an example of an ICD file of company A. The ICD file in FIG. 6 is a function definition file in which the function definition (specification) of the IED (IED name = “E1”) of company A is described and defined in the XML format.

  The ICD file is composed of a plurality of “elements”. “Element” indicates a unit of information in which a character string (element content) to be marked up is surrounded by “tag”. The “tag” explicitly indicates an element boundary. The start of the “element” is referred to as a “start tag”, and the end of the “element” is referred to as an “end tag”.

  For example, an <IED> element 601 is an element that defines an IED device name or the like. The <IED> element 601 is defined by being surrounded by a start tag <IED> and an end tag </ IED>.

  The “element” has an attribute. For example, the <IED> element 601 has attributes “name”, “type”, “manufacturer”, and “configVersion”.

  An “element” can include another “element” in the element. For example, the <IED> element 601 includes “elements” such as “AccessPoint”, “Server”, “LDdevice”, and “LN0”.

  In addition, reference data can be specified as the attribute. For example, the <LN0> element 602 defined in the <IED> element 601 has an attribute “lnType”, and the attribute value “lnType” is specified by reference data “LLN0_0”.

  The reference destination of the attribute value is defined in the <DATATYPETEMPLATES> element 603. For example, the attribute value of “lnType” of the <LN0> element 602 is associated with the “id” attribute of the <LNodeType> element 604 defined in the <DATATYPETEMPLATES> element 603. Therefore, when the reference destination of the attribute value “lnType” is acquired, the “id” attribute value of the <LNodeType> element 604 that matches the attribute value of the “lnType” attribute (for example, “LLN0 — 0”) is searched.

  For example, the attribute value of the “type” attribute of the <DO> element 605 is “INC_0”. The reference destination of the attribute value is associated with the “id” attribute of the <DOType> element 606 defined in the <DATATYPETEMPLATES> element 603. Therefore, when the reference destination of the attribute value of “type” is acquired, the “id” attribute value of the <DOType> element 606 that matches the attribute value of the “Type” attribute (for example, “INC_0”) is searched.

  FIG. 7 is a diagram illustrating an example of the ICD file of company B. FIG. 8 is a diagram illustrating an example of an ICD file of company C. Each vendor company submits the ICD files shown in FIGS. 6 to 8 to the manager of the substation as the function definition (specification) of their IED.

(SCD file)
FIG. 9 is a diagram illustrating an example of an SCD file. The SCD file in FIG. 9 is a setting file in which setting information of the entire substation system including IEDs of Company A, Company B, and Company C is described in XML format. The SCD file is generated by the system configurator 1 based on the ICD file, and for each IED of each vendor company, a function definition possessed by the IED and a setting value assigned to operate the function defined by the function definition. Including.

  For example, a <COMMUNICATION> element 901 indicates network setting information of an IED of company A, an IED of company B, and an IED of company C. For example, the administrator of the substation 100 uses the system configurator 1 to set an IP address (setting value) for the network function of each company's IED.

  An <IED> element 902 is setting information generated based on the ICD file (FIG. 6) of company A. Specifically, the <IED> element 902 includes a <IED> element 601 in the ACD file of the company A and a setting value assigned to the function of the company A IED 3a. For example, the administrator of the substation 100 uses the system configurator 1 to set the setting value of the IED 3a of company A for the function of the IED 3a based on the <IED> element 901. The system configurator 1 generates an SCD file by describing setting values set for the functions of the IED 3a.

  Similarly, <IED> element 903 and <IED> element 904 are setting information generated based on the ICD file (FIG. 7) of company B and the ICD file (FIG. 8) of company C, respectively. The substation manager 100 uses the system configurator 1 to set respective setting values for the functions of the IED 3b and the IED 3c.

  Further, a <DATATYPETEMPLATES> element 905 is an element that defines a reference destination of the attribute value. All of the <DATATYPETEMPLATES> elements described in the ICD files (FIGS. 6 to 8) of Company A, Company B, and Company C are described here.

(CID file)
FIG. 10 is a diagram illustrating an example of a CID file. The CID file in FIG. 10 is a setting file of the IED 3a of company A. The IED configurator 2a can generate the CID file of the IED 3a by extracting the setting information of the IED 3a from the SCD file of FIG.

For example, the CID file in FIG. 10 is generated by extracting the following description from the SCD file in FIG.
Of <COMMUNICATION> element 901, description location relating to IED3a. Description location of <IED> element 902. Among <DATATYPETPLATLES> element 905, a description location referenced by an attribute value of another element in <IED> element 902 ( Reference data)

(Verification item table)
FIG. 11 is a diagram illustrating an example of the verification item table. The verification item table is used when verifying the CID file, and is a table that specifies verification items for performing verification for each element. The verification item table is created according to the function of the IED 3 by a developer or the like, and is stored and stored in advance in the storage unit 305 of the IED 3.

  The verification item table in FIG. 11 includes items such as “verification item ID”, “logical node name”, “data object name”, “data item name”, “FC name”, and “data type (type)”.

  The “verification item ID” is an identifier of a verification item given every time one verification item is registered in the verification item table.

  “Logical node name” is a logical node necessary for the IED to operate normally, and indicates the name of the logical node to be verified. Although details will be described later, for example, it corresponds to the attribute value “LLN0” of the “lnClass” attribute (attribute indicating the logical node name) of the <LN0> element 602 that is a logical node in the CID file of FIG.

  “Data object name” is a data object necessary for the IED to operate normally, and indicates the name of the data object to be verified. Although details will be described later, for example, in the <LNodeType> element 604 in the CID file of FIG. 10, the attribute value “Mod” of the “name” attribute (attribute indicating the data object name) of the <DO> element 605 that is a data object. Corresponding to

  “Data item name” is a data item necessary for the IED to operate normally, and indicates the name of the data item to be verified. Although details will be described later, for example, in the <DOType> element 606 in the CID file of FIG. 10, the attribute value “ctlVal” of the “name” attribute (attribute indicating the data item name) of the <DA> element 608 that is a data item Is equivalent to.

  “FC name” indicates the FC name of the data item to be verified. Although details will be described later, for example, this corresponds to the attribute value “CO” of the “fc” attribute (attribute indicating the FC name) of the <DA> element 608 which is a data item in the CID file of FIG.

  “Data type” indicates the data type of the data item to be verified. Although details will be described later, for example, this corresponds to the attribute value “INT8” of the “bType” attribute (attribute indicating the data type) of the <DA> element 608 which is a data item in the CID file of FIG.

<Operation>
Next, the operation of the IED 3 in the embodiment will be described.

  First, as a premise, the IED 3 captures the CID file generated by the IED configurator 2 and stores the captured CID file in the storage unit 305. A verification item table is stored in advance in the storage unit 305 of the IED 3.

  Here, in the conventional IED 3, when the IED 3 is activated, the operation control unit 303 reads the CID file in the storage unit 305, and controls and operates the main device 4 based on the read CID file.

  On the other hand, in the IED 3 in this embodiment, when the IED 3 is activated, first, the CID file verification unit 302 reads the CID file in the storage unit 305 and verifies the read CID file.

  When the verification result that the CID file is normal is notified from the CID file verification unit 302, the operation control unit 303 reads the CID file in the storage unit 305 as in the conventional IED3, and based on the read CID file. Thus, the main device 4 is controlled and operated.

  On the other hand, when the verification result that the CID file is abnormal is notified from the CID file verification unit 302, the operation control unit 303 does not read the CID file and does not start the operation (stops the operation start). In addition, when the verification result that the CID file is abnormal is notified from the CID file verification unit 302, the alarm unit 304 outputs an alarm to the user. This will be described in detail below.

(CID file verification process)
FIG. 12 is a flowchart illustrating an example of the IED3 CID file verification process. In addition to FIG. 12, it demonstrates in detail, referring FIG.10 and FIG.11.

  S1: When the IED 3 is activated, the CID file verification unit 302 first acquires a CID file and a verification item table from the storage unit 305.

  S2: Next, the CID file verification unit 302 refers to the verification item table and acquires one initial verification item. For example, in the verification item table of FIG. 11, as the first verification item, “verification item ID” 001, “logical node name” LLN0, “data object name” Mod, “data item name” ctlVal, “FC name” on the first line “CO” and “data type (type)” INT8 are acquired.

  S3: Next, the CID file verification unit 302 refers to the CID file and verifies whether there is a logical node necessary for the IED to operate normally. Specifically, referring to the CID file, it is confirmed whether there is a logical node that matches the “logical node name” (for example, LLN0) acquired in S2.

  Here, the CID file in FIG. 10 is referred to. In order for the IED to operate normally in the CID file, the logical node of the IED must be defined by an element such as <LN0> in the “LD device” element 607 that defines the IED device.

  Accordingly, the CID file verification unit 302 defines the definition of the logical node whose “logical node name” is LLN0 from the “LDdevice” element 607, specifically, the <LN0> element whose “logical node name” is LLN0. Check if it exists.

  In the case of the CID file shown in FIG. 10, the “LD device” element 607 includes a <LN0> element 602 that is a logical node. The attribute value of the “lnClass” attribute (attribute indicating the logical node name) of the <LN0> element 602 that is a logical node is “LLN0”. This matches the “logical node name” LLN0 acquired in S2. That is, in this case, the existence of the logical node whose “logical node name” is LLN0 is confirmed in the CID file of FIG.

  If there is a logical node that matches the “logical node name” acquired in S2, the process proceeds to S4. On the other hand, when it does not exist, it progresses to S10.

  S4: Next, the CID file verification unit 302 verifies whether a data object necessary for the IED to operate normally exists. Specifically, for the logical node verified in S3, it is confirmed whether there is a data object that matches the “data object name” (for example, Mod) acquired in S2.

  Reference is again made to the CID file of FIG. The <LN0> element 602 that is a logical node has an “lnType” attribute. The attribute value of the “lnType” attribute (attribute indicating reference data) is specified by reference data “LLN0_0”.

  The reference destination of the attribute value is defined in the <DATATYPETEMPLATES> element 603. For example, the “lnType” attribute value of the <LN0> element 602 is associated with the “id” attribute of the <LNodeType> element defined in the <DATATYPETEMPLATES> element 603. Therefore, when the reference destination of the attribute value of “lnType” is acquired, the “id” attribute value of the <LNodeType> element that matches the attribute value of the “lnType” attribute (for example, “LLN0_0”) is searched. As a result, the <LNodeType> element 604 is searched.

  If the <LNodeType> element 604 is searched as a reference destination, the definition of the data object whose “data object name” is Mod from the <LNodeType> element 604, specifically, the “data object name” is Mod. It is confirmed whether or not the <DO> element exists.

  In the case of the CID file in FIG. 10, there are a plurality of <DO> elements that are data objects in the <LNodeType> element 604, and among these, the <DO> element 605 has a “name” attribute (data object The attribute value of “name indicating attribute” is “Mod”. This matches the “data object name” Mod acquired in S2. That is, in this case, the existence of the data object whose “data object name” is Mod is confirmed in the CID file of FIG.

  If there is a data object that matches the “data object name” acquired in S2, the process proceeds to S4. On the other hand, when it does not exist, it progresses to S10.

  S5: Next, the CID file verification unit 302 verifies whether there is a data item necessary for the IED to operate normally. Specifically, for the data object verified in S4, it is confirmed whether there is a data item that matches the “data item name” (eg, ctlVal) acquired in S2.

  Reference is again made to the CID file of FIG. The <DO> element 605 that is a data object has a “Type” attribute. The attribute value of the “Type” attribute (attribute indicating reference data) is specified by reference data “INC_0”.

  The reference destination of the attribute value is defined in the <DATATYPETEMPLATES> element 603. For example, the attribute value of “Type” of the <DO> element 605 is associated with the “id” attribute of the <DOType> element defined in the <DATATYPETEMPLATES> element 603. Therefore, when the reference destination of the attribute value of “Type” is acquired, the “id” attribute value of the <DOType> element that matches the attribute value of the “Type” attribute (for example, “INC_0”) is searched. As a result, the <DOType> element 606 is searched.

  If the <DOType> element 606 is searched for as a reference destination, the definition of the data item whose “data item name” is ctlVal from the <DOType> element 606, specifically, the “data item name” is ctlVal. It is confirmed whether or not <DA> element exists.

  In the case of the CID file in FIG. 10, there are a plurality of <DA> elements that are data items in the <DOType> element 606, and among these, the <DA> element 608 has a “name” attribute (data item The attribute value of “name indicating attribute” is “ctlVal”. This matches the “data item name” ctlVal acquired in S2. That is, in this case, the existence of the data item whose “data item name” is ctlVal is confirmed in the CID file of FIG.

  If there is a data item that matches the “data item name” acquired in S2, the process proceeds to S6. On the other hand, when it does not exist, it progresses to S10.

  S6: Next, if it is confirmed that there is a data item that matches the “data item name” acquired in S2, the CID file verification unit 302 “FC name” of the <DA> element 608 that is the data item of S5. And “data type” is verified to be an appropriate value for the IED to operate normally. Specifically, for the data item in S5, the data item matches the “FC name” (for example, CO) and “data type” (for example, INT8) acquired in S2, and the “FC name” and “ Check if it is defined in Data type.

  Reference is again made to the CID file of FIG. In the <DA> element 608, the attribute value of the “fc” attribute (attribute indicating the FC name) is “CO”, and the attribute value of the “bType” attribute (attribute indicating the data type) is “INT8”. This coincides with the “FC name” CO and “data type” INT8 acquired in S2. That is, in this case, in the CID file of FIG. 10, the data item is defined by “FC name” and “data type” that match the “FC name” and “data type” acquired in S2.

  If the data item of S5 is defined by “FC name” and “data type” that match the “FC name” and “data type” acquired in S2, the process proceeds to S7. On the other hand, if neither “FC name” nor “data type” is defined, the process proceeds to S10.

  S7: Here, the CID file verification unit 302 refers to the verification item table again, and determines whether or not there is an unprocessed verification item in the verification item table. If there is an unprocessed verification item, the process proceeds to S8. This is because the verification (S3 to S6) is executed for all the verification items in the verification item table. On the other hand, if there are no unprocessed verification items, it means that verification has been completed for all verification items, and thus the process proceeds to S9.

  S8: The CID file verification unit 302 refers to the verification item table and acquires one next verification item. For example, in the verification item table of FIG. 11, when “verification item ID” 001 is acquired in S2, “verification item ID” 002 is acquired as the next verification item. After the acquisition, the process proceeds to S3 again, and the verification of the acquired verification item is executed (S3 to S6).

  S9: The CID file verification unit 302 determines that the verification result of the CID file is normal, and notifies the operation control unit 303 of the verification result (normal).

  S10: The CID file verification unit 302 determines that the verification result of the CID file is abnormal (unauthorized) when any of the S3 to S6 is N, and the verification result ( Abnormal).

  As described above, the CID file verification processing is executed by the CID file verification unit 302.

  When the verification result of the CID file verification unit 302 is determined to be normal, the operation control unit 303 controls and operates the main device 4 based on the verified CID file.

  On the other hand, when it is determined that the verification result is abnormal (unauthorized), the operation control unit 303 does not read the CID file and does not start the operation (stops the operation start). Thereby, it is possible to prevent the IED 3 from performing an illegal operation.

  Further, the alarm unit 304 outputs an alarm to the user when the verification result of the CID file verification unit 302 is determined to be abnormal (unauthorized). Thereby, the user can recognize that the CID file set in the IED 3 is abnormal (unauthorized).

  Examples of the alarm output method include a method in which the alarm unit 304 of the IED 3 emits an alarm lamp, plays an alarm sound from a speaker, or displays a warning on a display. The alarm unit 304 may notify (send) an alarm to another device and output the alarm on the device side that has been notified of the alarm.

<Summary>
In system engineering of IEC61850, a CID file is generated via a plurality of setting devices such as the system configurator 1 and the IED configurator 2. In addition, a unified tool is not provided for the system configurator tool and the IED configurator tool. For this reason, it is impossible to exclude the possibility that the logical node and its data item relating to the IED function definition are added or deleted by mistake.

  The IED 3 according to the present embodiment, for example, reads the CID file after verifying whether the CID file can be normally operated at the timing when the IED 3 is activated. For this reason, if the setting information is inconsistent with the specifications of the IED device, an alarm is output to the user and the IED 3 is prevented from operating illegally by preventing the operation. Can do.

  That is, according to the present embodiment, it is possible to provide an electronic device or the like that detects unauthorized setting information generated by the setting device for the purpose of preventing malfunction of the electronic device.

  Although the embodiments have been described in detail above, the invention is not limited to the specific embodiments, and various modifications and changes can be made within the scope described in the claims.

1 System Configurator 2 IED Configurator 3 IED
4 Main unit 11 CPU
12 ROM
13 RAM
14 HDD
DESCRIPTION OF SYMBOLS 15 Storage medium reader 16 Input device 17 Display apparatus 18 Communication apparatus 100 Substation 101 ICD file acquisition part 102 SCD file generation part 103 Storage part 201 SCD file acquisition part 202 CID file generation part 203 CID file setting part 204 Storage part 301 CID File acquisition unit 302 CID file verification unit 303 Operation control unit 304 Alarm unit 305 Storage unit

Claims (5)

An electronic device that operates according to setting information generated by a setting device,
An acquisition means for acquiring setting information;
Storage means for storing function definitions to be defined in the setting information of the electronic device;
Before starting operation, verification means for verifying whether the function definition is defined in the setting information;
If the function definition is not defined in the setting information, operation control means for stopping the operation start,
An electronic device comprising:   The electronic device according to claim 1, further comprising an alarm unit that outputs an alarm when the function definition is not defined in the setting information. The setting information is a CID file conforming to the international standard IEC61850,
3. The function definition includes a logical node, a data object of the logical node, a data item of the data object, an FC of the data item, and a data type to be defined by the setting information of the electronic device. Electronic devices. A method for verifying setting information generated by a setting device,
Electronic equipment,
The procedure to get the setting information,
A procedure for reading out the function definition to be defined in the setting information of the electronic device from the storage means;
Before starting operation, a procedure for verifying whether the function definition is defined in the setting information;
When the function definition is not defined in the setting information, a procedure for stopping the operation start;
Verification method to execute. In an electronic device that operates according to the setting information generated by the setting device,
An acquisition means for acquiring setting information;
Storage means for storing function definitions to be defined in the setting information of the electronic device;
Before starting operation, verification means for verifying whether the function definition is defined in the setting information;
The verification program for functioning as an operation control means for stopping the operation start when the function definition is not defined in the setting information.

Images