JP2019041361A - Communication platform and communication processing method - Google Patents

Abstract

To enable integrated handling of communications with different standards.SOLUTION: A communication platform includes a common API in which an application program is implemented and that is provided at a transmitting/receiving end having a communication interface, to which data is passed from the application program and that passes data to the application program, and data related to information exchange service passed from the application program is converted into a format conforming to the transmission communication standard by the common API and then passed to the communication interface, and data passed from the communication interface is converted into data related to the information exchange service used by the application program by the common API and then passed to the application program.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a communication platform and a communication processing method. More specifically, the present invention relates to a technique suitable for application to a communication mechanism for performing data transmission for exchanging various information and data between different types of applications, for example.

  Standards for each application when trying to transmit by a communication system to combine and use multiple types of information and data collected and acquired by multiple mechanisms (in other words, different types of applications) In some cases, communication systems are constructed using different communication technologies / communication systems.

  Specifically, for applications related to power, for example, the distribution automation, smart meter, and demand response applications related to the smart grid are related to the power distribution system and consumers, so data is exchanged by communication. Have the potential to cooperate with each other.

  Looking at the standards of communication methods used in each application, for example, application of IEC 61850 is studied in IEC TC 57 WG 17 as a communication standard for power distribution automation, and IEC 61850-8- is used as a protocol stack. The method using the MMS (Manufacturing Message Specification) (Non-Patent Documents 1 and 2) defined in 1 is the mainstream.

  In addition, IEC 62056 is adopted as a communication standard for smart meters in Japan. In IEC 62056, an information model for measurement (COSEM interface object) (Non-Patent Document 3) and an application layer (DLMS) for accessing the information model are used. / COSEM application layer) (Non-Patent Document 4).

  Furthermore, as a demand response communication protocol, the use of OpenADR 2.0 is promoted by JSCA (abbreviation of Japan Smart Community Alliance) (Non-patent Document 5).

  As described above, the standard of the communication method used in each application related to power differs for each application.

Japan Industrial Standards Committee "Industrial Automation System-Manufacturing Message Specification-Service Definition", JISB 3600, 2004 Japan Industrial Standards Committee "Industrial Automation System-Manufacturing Message Specification-Protocol Specification", JIS B3601, 2004 IEC "Electricity metering data exchange-The DLMS / COSEM suite-Part 6-2: COSEM interface classes", IEC 620566-2, edition 2.0, 2016 IEC "Electricity metering data exchange-The DLMS / COSEM suite-Part 5-3: DLMS / COSEM application layer", IEC 62056-5-3, edition 2.0, 2016 JSCA Smart House Building Standards / Business Promotion Study Group “Demand Response Interface Specification Version 1.0 (draft)”, 2013

  However, in a situation where different standards of communication are used for each application, there is a problem that mutual cooperation between applications is difficult or takes a lot of time and effort.

  Accordingly, an object of the present invention is to provide a communication platform and a communication processing method that can integrally handle communication with different standards.

  In order to achieve such an object, the communication platform of the present invention is provided in a transmission / reception end having an application program and having a communication interface, and is provided with an API (data that is passed from or to the application program). Data for information exchange service delivered from application programs is converted to a format that conforms to the standard of the prescribed communication method by API and passed to the communication interface, and data passed from the communication interface Is converted into data related to the information exchange service used by the application program by the API and then passed to the application program.

  The communication processing method of the present invention is a communication platform provided with an application program installed and provided at a transmission / reception end having a communication interface, and an API for passing data from and to the application program. This is a communication processing method to be performed, and data related to an information exchange service passed from an application program is converted into a format conforming to a standard of a predetermined communication method by an API and then passed to a communication interface, and data passed from the communication interface is also converted to an application Data relating to an information exchange service used by the program is converted by the API and passed to the application program.

  Therefore, according to these communication platforms and communication processing methods, at the application level, the data exchange service used by each application program remains unchanged, and data that conforms to the standard of a predetermined communication method is transmitted between the transmitting and receiving ends. In addition, it becomes easy to share and use a plurality of types of information and data related to each application, and cooperation between different types of applications becomes easy.

  According to the communication platform and the communication processing method of the present invention, data converted by the API may be accommodated in an XMPP stanza and converted into an XML format message, and then passed as an IP packet to the communication interface. In this case, a plurality of types of information and data are transmitted and shared in accordance with the XML (Extensible Markup Language) format and in accordance with XMPP (Extensible Messaging and Presence Protocol).

  The communication platform and the communication processing method of the present invention may use any one of IEC 61850, IEC 62056, and OpenADR as a standard of a predetermined communication method. In this case, in particular, sharing of a plurality of types of information and data related to each application related to the smart grid is efficiently performed.

  The communication platform and the communication processing method of the present invention may use IEC 61850's ACSI (abbreviation of Abstract Communication Service Interface) as an API. In this case, it is easy to build a common platform by using existing technology, and it is also possible to build a mechanism for sharing multiple types of information and data related to each application related to the smart grid. It becomes simple.

  According to the communication platform and the communication processing method of the present invention, it is possible to easily share and use multiple types of information and data related to each application, and to easily link different types of applications. Therefore, it is possible to simplify and improve the efficiency and efficiency of application system construction and operation, and to enhance the application.

  When the XMPP is used, the communication platform and the communication processing method of the present invention can transmit and share multiple types of information and data according to the XMPP. It is possible to simplify and improve the construction and operation, and to enhance the application.

  The communication platform and the communication processing method of the present invention are particularly relevant to each application related to the smart grid when any one of IEC 61850, IEC 62056, and OpenADR is used as a standard of a predetermined communication method. It is possible to efficiently share multiple types of information and data, so that the construction and operation of application systems especially related to smart grids can be simplified, and the efficiency of applications related to smart grids in particular can be improved. It becomes possible to plan.

  When the communication platform and the communication processing method of the present invention uses the ACSI of IEC 61850 as an API, it becomes possible to easily construct a common platform by utilizing existing technology. In particular, it is possible to easily construct a mechanism for sharing a plurality of types of information and data related to each application related to the smart grid.

It is a flowchart explaining the processing procedure of the communication platform and communication processing method which concern on this invention. It is a figure explaining the example of the processing sequence of communication in the structure of embodiment. It is a conceptual diagram explaining the hierarchical structure of the communication platform of embodiment. It is a figure which shows the processing flow of the component of the communication platform of embodiment. It is a figure which shows the processing flow in case the transmission / reception end acquires data from another transmission / reception end in the structure of embodiment. It is a figure explaining the structure of the request message of embodiment. It is a figure explaining the structure of the response message of embodiment.

  Hereinafter, the configuration of the present invention will be described in detail based on an example of an embodiment shown in the drawings.

  1 to 7 show an example of an embodiment of a communication platform and a communication processing method according to the present invention.

  The communication platform of the present embodiment is provided at a transmission / reception end having an application program and having a communication interface, and includes a common API for transferring data from and to the application program. The data related to the information exchange service to be transferred is converted into a format conforming to the transmission communication standard by the common API and then transferred to the communication interface, and the data passed from the communication interface is shared with the data related to the information exchange service used by the application program After being converted by API, it is passed to the application program.

  In addition, the communication processing method according to the present embodiment is a communication provided with a common API that is installed in a transmission / reception end having an application program and has a communication interface, and that passes data from the application program to / from the application program. This is a communication processing method performed by the platform. Data related to the information exchange service passed from the application program is converted into a format conforming to the transmission communication standard by the common API and then passed to the communication interface. The data passed from the communication interface is also transferred to the application. Data relating to an information exchange service used by the program is converted by the API and passed to the application program.

  In this embodiment, when the distribution automation, smart meter, demand response, and system management applications, which are applications related to the smart grid, are linked to each other, the communication method used by the distribution automation, smart meter, and demand response is used. A case will be described as a specific example in which communications with different communication system standards are handled in an integrated manner, assuming that the standards are IEC 61850, IEC 62056, and OpenADR, respectively.

The items relating to the specific examples described above correspond to the notations in the drawings as general / general explanation as follows.
-Programs related to distribution automation: "Application programs αc, αs"
-Programs related to smart meters: "Application programs βc, βs"
-Programs related to demand response: “Application programs γc, γs”
-Programs related to system management: "Application programs δc, δs"
-IEC 61850: "Communication Standard I"
-IEC 62056: "Communication Standard II"
-OpenADR: "Communication Standard III"

  Note that “application programs αc, βc, γc, and δc” are expressed as “application programs αc−δc” and “application programs αs, βs, γs, and δs” are expressed as “application programs αs−δs”. In addition, “communication standards I, II, and III” are expressed as “communication standards I-III”.

  Examples of the transmission / reception end of the communication assumed in the present embodiment (specifically, communication used in an application related to a smart grid) include the following.

1) Power distribution automation master station (also simply referred to as “master station”)
The distribution automation master station communicates with a distribution automation slave station to realize various distribution automation functions such as power quality and system configuration management.

2) Distribution automation slave station (also simply referred to as “slave station”)
The distribution automation slave station is responsible for processing and communication related to monitoring and control of various devices (for example, a section switch, an instrument transformer, etc.) installed on the distribution system. A protection relay (that is, an overcurrent relay or the like) may be mounted.

3) DR server (DR: Abbreviation for Demand Response)
The DR server selects a DR program (for example, CPP (Critical Peak Pricing)) on the power supply side based mainly on supply and demand operations in the entire power system, and transmits and receives a demand response signal to and from the DR program participants. Do.

4) MDMS (Meter Data Management System)
MDMS stores measurement / measurement data and customer-related data collected from a meter and provides them to other systems. It is not responsible for processing directly related to power supply.

5) Meter A meter (for example, a smart meter) measures the amount of electric power of a consumer in each direction. In addition, active / reactive power, current, voltage, etc. may be measured. These measurement / measurement data are transmitted to the system (for example, MDMS etc.) which requires them.

6) xEMS
“XEMS” refers to a distributed power source, a power storage device, and a load that the customer owns, and a load that performs data linkage with the system side as necessary. Examples include BEMS (abbreviation for building energy management system) and HEMS (abbreviation for home energy management system).

  In the present invention, the type of application (or the type of transmission / reception end) related to the application program αc-δc (any one of the application programs αc-δc) to which the data exchange request is transmitted and the destination of the data exchange request ( That is, depending on the combination with the type of application (or the type of transmission / reception end) related to the application program αs−δs (which receives and responds to a request for data exchange) (in other words, , For each combination), a communication system standard (specifically, any of communication standards I-III) that is applied and used for transmission of [service request] and [response] to the request between the transmitting and receiving ends. Is previously selected. This preselected communication system standard is referred to as a “transmission communication standard”.

  Table 1 below summarizes specific examples of the transmission communication standard for each combination of various transmission / reception terminals listed in 1) to 6) above. Note that the communication sections (in other words, combinations of various transmission / reception ends) arranged in Table 1 and standards used for communication (that is, transmission communication standards) are merely examples, and combinations of transmission / reception ends that can be targeted in the present invention. Not all.

The transmission communication standard for each combination of various transmission / reception ends is determined in consideration of the following, for example, as an example.
1) It is preferable to use IEC 61850 when requesting advanced processing in device control or notification from the device.
2) Use IEC 62056 when using only simple data acquisition and settings.
3) Use OpenADR when there is no other option at the sending and receiving end of the other party.

  Further, in a situation where communication is performed with a transmission / reception end that is not equipped with a communication platform, it is necessary to match a method used by a transmission / reception end that is not equipped with a communication platform.

  In the following, following the heading “(Application Specific Example)”, description of [Request for Service] and [Response] performed between the distribution automation master station and the smart meter as a specific example of application of the present invention. Is described.

《Communication integration and platform》
In the present invention, a communication platform is used to integrate communication performed as part of processing in various applications.

  The communication platform according to the present invention enables mutual cooperation between different applications through API (abbreviation of application programming interface), and more specifically, by positioning and using the API based on a specific concept. Configured as follows. The API as one of the elements constituting the communication platform according to the present invention is referred to as a “common API”.

  The common API is capable of exchanging information with various applications installed at each of the transmission / reception ends / various application programs αc-δc, αs-δs related to the realization of the functions of these various applications (in other words, data can be exchanged). And configured to correspond to various information exchange services defined by various communication standards I-III used in the various installed applications, and for each communication standard I-III. Different communication services can be used in a unified way.

(Application examples)
The common API is configured to be able to exchange information with each application for distribution automation, smart meter, demand response and system management / application programs related to the realization of the functions of each application, and is used for distribution automation. IEC 61850, IEC 62056 used in smart meters, and various information exchange services defined in OpenADR used in demand response, and is different for each IEC 61850, IEC 62056, and OpenADR Make communication services available in a uniform way.

  The communication platform also applies XMPP (Extensible Messaging and Presence Protocol) as a protocol located in a lower layer of the protocol defined in various communication standards I-III.

  Then, the format of data input from the application programs αc-δc and αs-δs to the communication platform via the common API is converted into the XML (Extensible Markup Language) format, and then transmitted using XMPP. Is done.

  XMPP is capable of exchanging data in XML format and is characterized by being suitable for transmission of device state changes.

  Data exchanged between the transmitting and receiving ends is accommodated in a message and transmitted. The message has a variable length, and a plurality of data items may be accommodated in one message depending on the communication service.

  Thus, for example, when the application programs αc-δc and αs-δs of the transmission / reception ends perform data exchange, at one transmission / reception end (in other words, the transmission / reception end on the data request side), the transmission communication standard (specifically, Is generated in an XML format request message (in other words, transmission data for the transmission / reception end on the data request side) including [service request] according to the structure defined in any of the communication standards I-III). At the same time, the request message is transmitted to the other end (in other words, the transmitting / receiving end on the data providing side) by requesting data transmission to the XMPP layer. Here, the process in which the request message is generated is a process in which application data is converted into communication data.

  In the one transmission / reception end, an XML-format response message (in other words, reception data for the transmission / reception end on the data request side) transmitted from the other end (that is, the transmission / reception end on the data providing side) is sent to the XMPP layer. The response message in the XML format is reversely converted to extract the contents of [Response], and the contents of [Response] are passed to the application program [alpha] c- [delta] c. Here, the process in which the response message is inversely converted is a process in which communication data is converted into application data.

  Further, at the other transmission / reception end (that is, the transmission / reception end on the data providing side), an XML format request message (in other words, the transmission / reception end on the data providing side) transmitted from the other end (that is, the transmission / reception end on the data requesting side). Received data) is received by the XMPP layer, the request message in the XML format is reversely converted to extract the contents of [service request], and the contents of [service request] are transferred to the application program αs-δs. Passed. Here, the process in which the request message is inversely converted is, in other words, the process in which communication data is converted into application data.

  In the other transmission / reception end, the data provided corresponding to the request message transmitted from the other end (that is, the transmission / reception end on the data request side) conforms to the structure defined in the transmission communication standard [response]. A response message in XML format (in other words, transmission data for the transmission / reception end on the data providing side) is generated and the other end (that is, the transmission / reception end on the data requesting side) is requested by sending data to the XMPP layer. The response message is transmitted to. Here, the process in which the response message is generated is a process in which application data is converted into communication data.

  As described above, by using and utilizing the XML format and XMPP, it is possible to easily construct a structure in which various applications / various application programs αc-δc, αs-δs mutually utilize data.

<< Constituent elements of XMPP >>
In order for the communication platform to use XMPP, the transmission / reception end becomes an XMPP client, and at least one XMPP server is installed. And XMPP clients communicate (in other words, data exchange) via the XMPP server.

  The XMPP server mediates communication (in other words, data exchange) between XMPP clients. Messages exchanged between XMPP clients via the XMPP server are called “stanzas”.

  The transmission / reception end is installed with application programs αc-δc and αs-δs related to the realization of the function of the application related to the transmission / reception end, is provided with a communication platform, and functions and operates as a client in XMPP. Composed.

  The transmission / reception end stores a storage unit (specifically, an application program αc-δc, αs-δs and a common API and various programs / middleware related to the realization of the function of the application related to the transmission / reception end as necessary. For example, a control unit (specifically, for example, a CPU (ie, CPU) for executing processing of the application programs αc-δc, αs-δs, the common API, and various programs / middleware) A central processing unit)).

  The transmission / reception end has a communication unit for communicating with the XMPP server so as to function and operate as a client in XMPP.

  The communication unit is a communication interface for connecting to a communication network / communication line. For example, the communication unit includes a wireless module that performs wireless communication and a wired module that performs wired communication, and is connected to the communication network via an XMPP server. A function of exchanging messages (that is, stanzas) with the transmission / reception ends of

<Communication platform components>
The communication platform is configured to perform communication between the application program αc-δc in one transmission / reception end and the application program αs-δs in the other transmission / reception end through a common API (specifically, for example, information related to various applications). Provide functions such as notification and data exchange).

(Application examples)
The communication platform is related to the realization of the function of the distribution automation master station that is one of the transmission / reception terminals through the common API (in other words, the function of the smart meter that is the other transmission / reception terminal). A function of performing communication with an application program βs related to realization is provided.

The communication platform is positioned as middleware among software. The main elements that make up the communication platform are as follows.
(1) Common API
(2) XMPP wrapper-configures the upper layer of the communication protocol (3) XMPP client library-configures the lower layer of the communication protocol

  In this embodiment, Java (registered trademark) is used to implement a communication platform (in other words, programming).

(1) Common API
The common API is related to the realization of functions of various applications, and can exchange information with various application programs αc-δc and αs-δs installed in each of the transmitting and receiving ends (in other words, data can be exchanged). In addition, it is configured to correspond to various information exchange services defined in various communication standards I-III used in the various installed applications.

(Application examples)
The common API relates to the realization of distribution automation, smart meter, demand response, and system management functions, and is configured to be able to exchange information with various application programs installed at each of the transmitting and receiving ends. IEC 61850 used in distribution automation, IEC 62056 used in smart meters, and various information exchange services defined in OpenADR used in demand response.

  The common API is used for information exchange service / communication service using a transmission / reception function as an XMPP client as a transmission / reception end on the data request side as a role / positioning in communication, and at the transmission / reception end on the data providing side. It is used for an information exchange service / communication service using a transmission / reception function as an XMPP client.

  The common API has a function of transmitting data and a function of receiving data as a function of providing an information exchange service / communication service to the application programs αc-δc and αs-δs.

Examples of types / classifications of information exchange service / communication service to which the common API corresponds (and used at the transmission / reception end) are as follows.
-Communication initialization service: Used to start a communication session.
-Communication termination service: Used to terminate a communication session.
-Data acquisition service: Used to acquire various data such as devices and sensors.
-Data setting service: Used to set / update settling values of devices.
-Selection / control service: Used to control devices.
-Notification service: Used when a status change occurs in a device.
-File transfer service: Used when updating software.

(Application examples)
Specific examples of the information exchange service used in power distribution automation, smart meter, and demand response, and specific examples of the information exchange service supported by the common API include the following. The following specific example is an example of an information exchange service defined in ACSI (abbreviation of Abstract Communication Service Interface) of IEC 61850.
-Communication initialization service: Associate
-Communication termination service: Release
-Data acquisition service: GetDataValues, GetDataSetValues, QueryLogByTime
-Data setting service: SetDataValues, SetDataSetValues
-Selection / control service: SelectWithValue, Operate
-Notification service: SetURCBValues, Report, CommandTermination
-File transfer service: SetFile

  The common API specifies the contents of [service request] and [response] for the information exchange service A designated (in other words, passed) from the application programs [alpha] c- [delta] c and [alpha] s- [delta] s. The request is converted into a request or response of a specific communication service a, and the [service request] or [response] of the converted communication service a is passed to the XMPP wrapper.

(Application examples)
The common API is “GetDataSetValuesRequest” (as a variable for ACSI), which is a request for an information exchange service specified from an application program αc related to distribution automation or an application program βs related to a smart meter. [Service Request] and [Response] containing “GetDataSetValuesResponse” as a response and “GetDataNormal” as a response to the request and “GetRequestNormal” as a request for a communication service specific to IEC 62056 and “GetResponseNormal” as a response thereto. (It is a Java class for COSEM), and at the same time, [Service Request] whose content is “GetRequestNormal” and [Response] whose content is “GetResponseNormal” are passed to the XMPP wrapper.

  The common API also converts / passes the contents of [service request] and [response] to the information exchange service A through the communication service a unique to various communication standards I-III delivered from the XMPP wrapper, and the conversion. [Service Request] and [Response] for the information exchange service A are transferred to the application programs αc-δc and αs-δs.

(Application examples)
The common API uses “GetRequestNormal”, which is a communication service request unique to IEC 62056 passed from the XMPP wrapper, and “GetResponsetNormal”, which is a response, to “GetDataSetValuesRequest”, which is a request for an information exchange service, and “GetDataSetValuesResponse”, which is a response. And “GetDataSetValuesResponse” is passed to the application program αc related to distribution automation, or “GetDataSetValuesRequest” is passed to the application program βs related to the smart meter on the response side.

(2) XMPP wrapper The XMPP wrapper has a conversion module corresponding to each of the various communication standards I-III in order to absorb the differences between the communication standards I-III. Provide service.

(Application examples)
The XMPP wrapper has conversion modules corresponding to IEC 61850, IEC 62056, and OpenADR, and provides communication services for each of these communication standards.

  Since the XMPP wrapper provides a communication service a specific to the communication standard I-III for the common API, the contents related to the communication service a are accommodated in an XMPP stanza and an XML format message is generated. Request data transmission to the client library.

(Application examples)
The XMPP wrapper responds to “GetRequestNormal”, which is a communication service request specific to IEC 62056 passed from the common API. Therefore, the XMPP wrapper accommodates the content related to “GetRequestNormal” in the XMPP stanza and generates an XML format message. , Request data transmission to the XMPP client library.

  In addition, when an XMPP stanza (XML format message) is passed from the XMPP client library, the XMPP wrapper passes a request or response of the communication service a accommodated in the XMPP stanza to the common API.

(Application examples)
When an XMPP stanza (XML format message) is passed from the XMPP client library, the XMPP wrapper passes the contents related to “GetRequestNormal”, which is a request for a communication service unique to IEC 62056 contained in the XMPP stanza, to the common API. And pass.

(3) XMPP Client Library The XMPP client library provides a function of receiving an XML format message as transmission data in an IP packet and transmitting it to an XMPP server when requested by the XMPP wrapper.

  The XMPP client library also receives an IP packet transmitted from the XMPP server, expands the IP packet, extracts an XML format message contained in the IP packet, and passes it to the XMPP wrapper as received data I will provide a.

  In order to provide the functions as described above, the XMPP client libraries at the transmitting and receiving ends cooperate with each other via the XMPP server.

<Cooperation of components>
Processing procedure when one transmission / reception end as an XMPP client (positioning is a transmission / reception end on the data request side) acquires data from the other transmission / reception end (positioning is a transmission / reception end on the data providing side) as an XMPP client Will be explained. It is assumed that an application program αc related to distribution automation is installed at the transmission / reception end on the data request side, and an application program βs related to the smart meter is installed at the transmission / reception end on the data providing side. .

(Application examples)
A processing procedure when the power distribution automation master station as the XMPP client acquires data from the smart meter as the XMPP client will be described. Note that an application program αc related to distribution automation is installed in the distribution automation master station, and an application program βs related to the smart meter is installed in the smart meter.

  First, the communication platform is activated at each of the transmission / reception end on the data request side and the transmission / reception end on the data providing side (S1 in FIG. 1).

  Subsequently, a communication platform initialization process is performed (S2 in FIG. 1). Specifically, for example, a work area (specifically, for example, a memory) used when converting an information exchange service into a communication service is cleared and initialized, and information exchange service requests and responses For example, a storage unit or a memory holds rules used when converting information service request / response information and information exchange service request / response into communication service request / response. Furthermore, the correspondence data of the transmission communication standard assigned to the combination of the type of application on the data requesting side (or type of transmission / reception end) and the type of application on the data providing side (or type of transmission / reception end) It is held in a storage unit or memory.

  After the processing of S2, the communication platform enters a state of waiting for communication processing (that is, waiting for processing related to [service request] or [response]) (S3 in FIG. 1). Specifically, it enters a standby state for a request for transmission processing from the application programs αc and βs and a request for reception processing from the XMPP client library.

  When a request for transmission processing occurs in the application program αc installed at the transmission / reception end on the data requesting side (S4: Yes in FIGS. 1 and 2), the information exchange service A designated by the application program αc is targeted. [Service Request] is passed to the common API (circle 1 in FIGS. 4 and 5).

(Application examples)
When a transmission processing request occurs in the application program αc related to distribution automation installed in the distribution automation master station, the content is “GetDataSetValuesRequest” for using the information exchange service specified by the application program αc [ Service Request] is passed to the common API. Here, the format of [service request] passed from the application program αc to the common API is Java. The common API has a structure based on ACSI of IEC 61850. Specifically, the common API is configured to correspond to a part or all of the information exchange service defined by ACSI. ACSI may be used as it is.) Further, if necessary, it is configured to support an information exchange service that is not defined by ACSI but is used by application programs αc-δc and αs-δs. . “GetDataSetValuesRequest” is a Java class as an ACSI variable.

  A structure in which the content of [service request] for the information exchange service A on the data providing side (in other words, the responding side) is defined in the transmission communication standard by the common API at the transmitting and receiving ends on the data requesting side And converted into a request for the communication service a specific to the transmission communication standard (S6 in FIGS. 1 and 2). At this time, the transmission source (that is, the transmission / reception end on the data request side, the application program αc) and the final destination (that is, the transmission / reception end on the data providing side, the application program βs) related to the [service request] to be processed. A communication standard I-III (any one) assigned in advance to the combination is selected as the transmission communication standard.

(Application examples)
With the common API, the contents of [Service Request] containing “GetDataSetValuesRequest”, which is an information exchange service request, are mapped to a structure conforming to COSEM (IEC 62056) and “GetRequestNormal which is a request for a communication service unique to IEC 62056”. To "." At this time, for the combination of the [Service Request] sender (ie, distribution automation master station, application program αc) and the final destination (ie, smart meter, application program βs) whose content is “GetDataSetValuesRequest” Thus, IEC 62056, which is a communication standard assigned in advance, is selected as the transmission communication standard. “GetRequestNormal” is a Java class for COSEM (IEC 62056).

  [Request for service] containing the request for the communication service a specific to the transmission communication standard, mapped to the information exchange service A, which is converted by the common API, is passed to the XMPP wrapper (FIG. 4). And circle 2 in FIG.

(Application examples)
The request [GetRequestNormal] of the communication service specific to IEC 62056 (COSEM) converted by the common API, specifically, to which the request “GetDataSetValuesRequest” of the information exchange service is mapped, is an XMPP wrapper. Passed to.

  Next, the XMPP wrapper at the transmission / reception end on the data request side stores the contents of [Request for Service] containing the request for the communication service a passed from the common API in the XMPP stanza, and the XML format message is received. It is generated (S7 in FIGS. 1 and 2).

(Application examples)
The XMPP wrapper accommodates the contents of [Service Request] with the content “GetRequestNormal” passed from the common API in the XMPP stanza, and generates an XML format message. Note that “PDU” in FIG. 6 and FIG. 7 is an abbreviation for Protocol Data Unit.

  The message generated by the XMPP wrapper is an XMPP stanza that includes, as items / elements, the contents of [request for service] mapped to the structure defined in the transmission communication standard.

  Further, the XMPP wrapper requests the XMPP client library to transmit the generated XML format message (XMPP stanza) to the transmission / reception end on the data providing side (circle 3 in FIGS. 4 and 5).

  Then, the XMPP client library at the transmission / reception end on the data request side performs processing for transmitting an XML format message (S8 in FIGS. 1 and 2).

  Specifically, the XML message generated by the XMPP wrapper (XMPP stanza) is accommodated in an IP packet by the XMPP client library at the transmission / reception end on the data request side (in other words, mapped to a structure according to XMPP). )

  As described above, a request message is created and transmitted as an IP packet including an XMPP stanza embedded with [service request] passed through the common API.

  The request message is transmitted to the XMPP server via the communication unit (communication interface) at the transmission / reception end on the data request side (circle 4 in FIGS. 4 and 5).

  The XMPP server transfers the received request message to the transmission / reception end on the data providing side (circle 5 in FIG. 4). The XMPP stanza includes the address of the final destination (that is, the transmitting / receiving end on the data providing side).

  The request message transferred by the XMPP server is received by the transmitting / receiving end of the data providing side via the communication unit (communication interface) of the transmitting / receiving end of the data providing side.

  Then, when the request message is received, a request for reception processing is generated in the XMPP client library at the transmission / reception end on the data providing side (S5 in FIG. 1 and FIG. 2: Yes), and the request message is received by the XMPP client library. Reception processing is performed (S9 in FIGS. 1 and 2).

  Specifically, the XMPP client library at the transmission / reception end on the data providing side expands the IP packet, which is a request message, and retrieves an XMPP stanza (in other words, an XML format message) while referring to a structure conforming to XMPP. .

  The XMPP stanza extracted by the XMPP client library is passed to the XMPP wrapper (circle 6 in FIG. 4).

  A portion corresponding to the structure defined in the transmission communication standard (ie, specific to the transmission communication standard) accommodated in the XMPP stanza passed from the XMPP client library by the XMPP wrapper at the transmission / reception end on the data providing side. [Content of [Request for Service]] for using the communication service a) is extracted (S10 in FIGS. 1 and 2).

(Application examples)
The portion corresponding to the structure conforming to COSEM (IEC 62056) accommodated in the XMPP stanza by the XMPP wrapper (that is, the request “GetRequestNormal” of the communication service specific to IEC 62056 (COSEM) [service request] Is taken out.

  The part corresponding to the structure defined by the transmission communication standard, taken out by the XMPP wrapper, is passed to the application program βs installed at the transmission / reception end on the data providing side via the common API (FIG. 4). Round 7, Round 8).

(Application examples)
The part corresponding to the structure according to COSEM (IEC 62056) is passed to the application program βs implemented in the smart meter via the common API.

  At this time, the content of [request for service] containing the request for the communication service a specific to the transmission communication standard is converted into the request for the information exchange service A by the common API at the transmission / reception end on the data providing side (FIG. 1). And S11 in FIG.

(Application examples)
With the common API, the content of the [service request] including the communication service request “GetRequestNormal” unique to IEC 62056 is converted into the information exchange service “GetDataSetValuesRequest”.

  Then, in response to the [Service Request] being passed through the common API, in response to the [Service Request] (specifically, the requested data is returned in response), A request for transmission processing occurs in the application program βs installed at the transmission / reception end on the data providing side (S4: Yes in FIGS. 1 and 2).

(Application examples)
In response to the [Service Request] being passed through the common API, in response to the [Service Request], the application program βs related to the smart meter installed in the smart meter performs transmission processing. A request arises.

  The application program βs installed at the transmission / reception end on the data providing side returns the data requested for transmission related to the information exchange service A related to [service request] in the [response] of the information exchange service A. Then, as a response of the information exchange service A, a [response] containing the data item corresponding to the transmission request is passed to the common API (circle 9 in FIG. 4).

(Application examples)
The application program βs installed in the smart meter returns the data requested for transmission in response to the information exchange service request “GetDataSetValuesRequest” related to [Service Request] in response to the information exchange service “GetDataSetValues”. Then, as a response to the information exchange service “GetDataSetValues”, a [response] containing the data item corresponding to the transmission request is passed to the common API.

  Then, by the common API at the transmission / reception end on the data providing side, the response of the information exchange service A is mapped to the structure defined in the transmission communication standard with the content of the data item corresponding to the transmission request as the content Then, it is converted into a communication service a (response) specific to the transmission communication standard (S6 in FIGS. 1 and 2). At this time, a combination of a transmission source (that is, transmission / reception end on the data providing side, application program βs) and a final destination (that is, transmission / reception end on the data requesting side, application program αc) related to the [response] to be processed The communication standard I-III (any one) assigned in advance is selected as the transmission communication standard.

(Application examples)
As a “GetDataSetValuesResponse” that is a response of the information exchange service, the content of the data item corresponding to the transmission request is converted into a structure conforming to COSEM (IEC 62056) by the common API, and “GetResponseNormal that is a response of the communication service unique to IEC 62056” To "." At this time, a combination of a [response] sender (ie, smart meter, application program βs) and final destination (ie, distribution automation master station, application program αc) containing “GetDataSetValuesResponse” in advance The assigned communication standard IEC 62056 is selected as the transmission communication standard. “GetResponseNormal” is a Java class for COSEM (IEC 62056).

  [Response] containing the data item corresponding to the transmission request from the communication service a (response) specific to the transmission communication standard converted by the common API, specifically the information exchange service A mapped, Passed to the XMPP wrapper (circle 10 in FIG. 4).

(Application examples)
IEC 62056 (COSEM) -specific communication service “GetResponseNormal” converted by the common API, specifically mapped to the information exchange service response “GetDataSetValuesResponse”, and the data item corresponding to the transmission request [Response] is passed to the XMPP wrapper.

  Next, the XMPP wrapper at the transmission / reception end on the data providing side stores the contents of [response] including the communication service a (response) and the data item passed from the common API in the XMPP stanza, and the XML format. Is generated (S7 in FIGS. 1 and 2).

(Application examples)
The XMPP wrapper stores the “GetResponseNormal” passed from the common API and the contents of the [response] containing the data item in the XMPP stanza, and generates an XML format message.

  The message generated by the XMPP wrapper is an XMPP stanza that includes, as items / elements, the contents of [response] mapped to the structure defined in the transmission communication standard.

  Further, the XMPP wrapper requests the XMPP client library to transmit the generated XML format message (XMPP stanza) to the transmission / reception end on the data request side (circle 11 in FIGS. 4 and 5).

  Then, the XMPP client library at the transmission / reception end on the data providing side performs an XML format message transmission process (S8 in FIGS. 1 and 2).

  Specifically, the XML message generated by the XMPP wrapper (XMPP stanza) is accommodated in an IP packet by the XMPP client library at the transmission / reception end on the data providing side (in other words, mapped to a structure according to XMPP). )

  As described above, the response message is created and transmitted as an IP packet including the XMPP stanza in which the [response] passed through the common API is embedded.

  The response message is transmitted to the XMPP server via the communication unit (communication interface) at the transmission / reception end on the data providing side (circle 12 in FIGS. 4 and 5).

  The XMPP server transfers the received response message to the transmission / reception end on the data request side (circle 13 in FIGS. 4 and 5). Note that the XMPP stanza includes the address of the final destination (that is, the transmission / reception end on the data request side).

  The response message transferred by the XMPP server is received by the transmitting / receiving end of the data requesting side via the communication unit (communication interface) of the transmitting / receiving end of the data requesting side.

  Then, triggered by receiving the response message, a request for reception processing is generated in the XMPP client library at the transmission / reception end on the data request side (S5: Yes in FIGS. 1 and 2), and the response message is sent by the XMPP client library. Reception processing is performed (S9 in FIGS. 1 and 2).

  Specifically, an IP packet as a response message is expanded by the XMPP client library at the transmission / reception end on the data request side, and an XMPP stanza (in other words, an XML format message) is extracted while referring to a structure according to XMPP. .

  The XMPP stanza extracted by the XMPP client library is passed to the XMPP wrapper (circle 14 in FIGS. 4 and 5).

  Then, the portion corresponding to the structure defined in the transmission communication standard (ie, specific to the transmission communication standard) accommodated in the XMPP stanza passed from the XMPP client library by the XMPP wrapper at the transmission / reception end on the data request side. [Content of [response] containing the communication service a (response) and the data item) is extracted (S10 in FIGS. 1 and 2).

(Application examples)
The XMPP wrapper contains the response “GetResponseNormal” and the data item of the communication service specific to the structure conforming to COSEM (IEC 62056) accommodated in the XMPP stanza [that is, IEC 62056 (COSEM)] Response) is taken out.

  A portion corresponding to the structure defined by the transmission communication standard, taken out by the XMPP wrapper, is passed to the application program αc installed at the transmission / reception end on the data request side via the common API (see FIG. 4 and FIG. 4). Circles 15 and 16 in FIG. 5).

(Application examples)
A portion corresponding to the structure according to COSEM (IEC 62056) is passed to the application program αc installed in the distribution automation master station via the common API.

  At this time, the content of [response] including the communication service a (response) specific to the transmission communication standard is converted into the information exchange service A by the common API at the transmission / reception end on the data request side (FIGS. 1 and 2). S11).

(Application examples)
The content of [response] having the response “GetResponseNormal” of the communication service unique to IEC 62056 is converted into the response “GetDataSetValuesResponse) of the information exchange service by the common API.

  As described above, the transmission / reception end on the data requesting side acquires the data corresponding to the content of the request message transmitted by itself from the transmission / reception end on the data providing side.

  According to the communication platform and the communication processing method configured as described above, at the application level, the information exchange service A used by each application program αc-δc, αs-δs remains as it is, and the transmission / reception end on the data request side Since data in the format of the transmission communication standard is transmitted between the transmitting and receiving ends on the data providing side, it is easy to share and combine multiple types of information and data related to each application. it can. For this reason, it is possible to simplify and improve the efficiency and efficiency of application system construction and operation, and to enhance the application.

  Since the correspondence between the common API (specifically, for example, based on the ACSI of IEC 61850) and the communication message of each communication method is static, conversion data (specifically, used by the XMPP wrapper) The "information exchange service request and response structure information" and "communication service request and response structure information" are associated with the Java class and the XML data) in advance in the memory, not in the database. In addition, by using the same conversion data at each transmission / reception end, it is possible to achieve both high speed and efficient communication processing.

  By using the same conversion data at each transmitting / receiving end, if there is a difference in the contents of the conversion data used by the transmitting end and the receiving end, The XMPP wrapper at the receiving end cannot perform message conversion, whereas the XMPP wrapper uses the common conversion data at the transmitting end and the receiving end to ensure that the message is converted. It becomes possible.

  In addition, since the conversion data is referred to (in other words, searched) for each element constituting the message and the message is converted based on the result, it is desirable to reduce the processing amount required for the search. By including only elements in the conversion data, it is possible to reduce the waste of search processing.

  Although the above-described embodiment is an example of a preferred embodiment for carrying out the present invention, the embodiment of the present invention is not limited to the above-described embodiment, and the present invention is not limited to the scope of the present invention. The invention can be variously modified.

  For example, in the above-described embodiment, the case where the applications related to the smart grid are linked to each other has been described as a specific example. However, the application target of the present invention is limited to the communication mechanism used by the application related to the smart grid. However, it may be applied to a communication mechanism that is not related to the smart grid, and more specifically, may be applied to a communication mechanism that is not related to the power facility.

  In the above-described embodiment, the common API is configured based on ACSI. However, in some cases, the common API is uniquely designed to be compatible with the information exchange service used in the application programs αc-δc and αs-δs. You may make it comprise.

  In the above-described embodiment, any one of the communication standards I-III used in various applications related to the transmission / reception end is selected as the transmission communication standard. A communication standard other than the communication standard I-III used in various applications may be selected as the transmission communication standard.

  In the above-described embodiment, the communication platform according to the present invention is mounted on both the transmission / reception end on the data request side and the transmission / reception end on the data providing side. However, the communication platform according to the present invention is used. A mode of communication to be performed is not limited to communication between transmission and reception ends on which a communication platform is mounted. That is, even when the communication partner's transmission / reception end does not support the communication platform according to the present invention, if the communication of IEC 61850, IEC 62056, or OpenADR using XMPP is possible, the communication platform according to the present invention It is possible to communicate with the mounted transmission / reception end.

αc Application program related to distribution automation βs Application program related to smart meter

Claims (8)

  The present invention relates to an information exchange service provided with an API in which an application program is mounted and provided at a transmission / reception end having a communication interface, and has an API for passing data from or to the application program. Data is converted into a format conforming to a standard of a predetermined communication method by the API and then passed to the communication interface, and data passed from the communication interface is converted into data related to the information exchange service used by the application program. A communication platform that is converted by the API and then transferred to the application program.   The communication platform according to claim 1, wherein the data converted by the API is accommodated in an XMPP stanza and converted into an XML format message, and then transferred to the communication interface as an IP packet.   The communication platform according to claim 1 or 2, wherein the standard of the predetermined communication method is one of IEC 61850, IEC 62056, and OpenADR.   The communication platform according to any one of claims 1 to 3, wherein the API is IEC 61850 ACSI.   A communication processing method performed by a communication platform that includes an application program installed and provided at a transmission / reception end having a communication interface and has an API for passing data from or to the application program. Data related to the information exchange service passed from the application program is converted into a format conforming to a standard of a predetermined communication method by the API and then passed to the communication interface, and the data passed from the communication interface is used by the application program A communication processing method, wherein the data is converted into data related to the information exchange service by the API and then transferred to the application program.   6. The communication processing method according to claim 5, wherein the data converted by the API is accommodated in an XMPP stanza and converted into an XML format message, and then transferred to the communication interface as an IP packet.   7. The communication processing method according to claim 5, wherein any one of IEC 61850, IEC 62056, and OpenADR is used as the standard of the predetermined communication method.   The communication processing method according to any one of claims 5 to 7, wherein ACSI of IEC 61850 is used as the API.

Images