WO2022114612A1 - Gateway device for heterogeneous communication protocol data communication and method for setting same - Google Patents

Abstract

The present invention may provide a gateway device for heterogeneous communication protocol data communication, the device being characterized by comprising: a main PCB; a sub PCB comprising a port unit corresponding to a communication protocol, a transceiver supporting the port unit and the communication protocol, and a conversion unit for bidirectional protocol conversion between the communication protocol and a modbus TCP according to hardware specifications; and a coupling part which allows the sub PCB to be detachably coupled to the main PCB in a slot coupling method. According to the above, the gateway device is economical because cost and time can be reduced, and since modbus map generation can be made more easily and quickly, various communication protocols can be easily and conveniently converted in a modbus TCP method.

Description

Gateway device for heterogeneous communication protocol data communication and its setting method

The present invention relates to a gateway device for heterogeneous communication protocol data communication and a method for setting the same, and more particularly, to a gateway device for heterogeneous communication protocol data communication that enables a user to easily convert between Modbus TCP and other protocols, and its It is about setting method.

In general, Modbus is a commonly used protocol to implement simple, reliable and efficient communication in various modern networks.

On the other hand, in the case of sensors or devices, various communication methods exist. Accordingly, in order for these sensors or devices to change to modbus communication, a hardware/software communication protocol conversion device suitable for communication devices must be provided.

As an example of this technology, Republic of Korea Patent Publication No. 10-1191547 discloses, as a frame conversion gateway device for relaying between a CAN communication network device and a Modbus communication network device, a CAN input unit for receiving a CAN input data frame, and a Modbus input data frame. A receiving Modbus input unit, converting the received CAN input data frame into a Modbus output data frame, and converting the received Modbus input data frame into a CAN output data frame, and the converted CAN output data frame or the converted A communication method of a gateway device supporting communication between a CAN and Modbus including an output unit for outputting a Mobus output data frame and a gateway device using the same have been disclosed.

However, in the prior art, there was a problem in that the cost was excessively generated in developing and manufacturing such a communication conversion device, and also there was a problem in that it takes a lot of time to generate a modbus map.

[Prior art literature]

[Patent Literature]

Republic of Korea Patent Publication No. 10-1191547

The present invention is economical because the cost is not excessively generated, and since modbus map generation can be made more easily and quickly, heterogeneous communication protocol data communication that can easily and conveniently convert various communication protocols to the modbus TCP method. An object of the present invention is to provide a gateway device for and a method for setting the same.

The present invention, a main PCB comprising a power supply unit, an MCU unit, and an Ethernet port unit (ethernet port); A port unit corresponding to a communication protocol, a transceiver supporting the port unit and the communication protocol, and a conversion unit for bidirectional protocol conversion between a communication protocol according to hardware specifications and Modbus TCP. sub PCB; And it is possible to provide a gateway device for heterogeneous communication protocol data communication comprising a; and a coupling unit for detachably coupling the sub PCB to the main PCB in a slot coupling method.

Here, the MCU unit may provide a UI for setting conversion between the communication protocol and Modbus TCP in the user terminal through a web browser, wherein the UI is the Ethernet port unit through a setting screen in the user terminal It can be configured so that conversion can be set by accessing the IP address set in .

Furthermore, the UI is configured to control the data flow by setting a modbus map for each sub-PCB coupled through the coupling unit in the user terminal, a communication protocol interpretation method, and a data transmission/reception relationship, The MCU unit may be configured to upload a file of a communication map to match and convert the maps between the respective protocols.

In addition, the MCU unit may be configured to record data transmission/reception relationship-data flow information set by the user terminal, and the sub-PCB may be configured to record the Modbus map and protocol analysis information.

In addition, the MCU unit may be configured to include a slot data flow control module for data flow control and a slot data collection module for data monitoring.

A gateway device for heterogeneous communication protocol data communication and a method for setting the same according to the present invention can easily develop and set a complex and expensive communication gateway currently in use, thereby reducing cost and time, which is economical, Since modbus map generation can be made more easily and quickly, various communication protocols can be easily and conveniently converted to the modbus TCP method.

A gateway device for heterogeneous communication protocol data communication and a setting method thereof according to the present invention can convert various protocol methods by exchanging a slot-type PCB in one Modbus gateway, and in the conversion setting, the gateway device provides a setting UI and allows the user to change the setting, thereby providing an effect that the user can use easily.

In addition, in the gateway device for heterogeneous communication protocol data communication and the method for setting the same according to the present invention, a user can conveniently change a desired communication protocol to modbus TCP or change modbus TCP to a desired communication protocol and use the setting, It can be conveniently set and detailed through a file, so that the user can accurately change the communication map to the desired one.

1 is a block diagram illustrating a system configuration of a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

2 is a diagram illustrating the configuration of a main PCB and a sub-PCB of a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

3 is a diagram illustrating a map setting screen when changing Modbus by accessing an Ethernet port for setting in a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

4 is a block diagram illustrating a software configuration diagram in a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

5 is a diagram illustrating a data flow diagram in a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

6 is a diagram illustrating a data model conversion flow in a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

7 is a diagram illustrating a concept of generating a device setting file in a gateway apparatus for heterogeneous communication protocol data communication according to an embodiment of the present invention.

8 and 9 are diagrams illustrating an example of creating a configuration file in a gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention.

Hereinafter, the terms used in the present invention have been selected as widely used general terms as possible while considering the functions in the present invention, which may vary depending on the intention or precedent of a person skilled in the art, the emergence of new technology, etc. . In addition, in a specific case, there is a term arbitrarily selected by the applicant, and in this case, the meaning will be described in detail in the description of the corresponding invention. Therefore, the term used in the present invention should be defined based on the meaning of the term and the overall content of the present invention, rather than the name of a simple term. What part of the specification

When a component is "included", it means that other components may be further included, rather than excluding other components, unless otherwise stated. In addition, terms such as "...unit", "module", and "means" described in the specification mean a unit that processes at least one function or operation, which is implemented in hardware or software, or is a combination of hardware and software. can be implemented. In addition, in the following description, terms such as 1st, 2nd, etc. are terms used to describe various components, and their meanings are not limited, and are used only for the purpose of distinguishing one component from other components. do.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings so that those of ordinary skill in the art can easily implement them. However, the present invention may be embodied in several different forms and is not limited to the embodiments described herein. And in order to clearly explain the present invention in the drawings, parts irrelevant to the description are omitted, similar reference numerals are attached to similar parts throughout the specification, and the same reference numbers used throughout the present specification refer to the same components. indicates. And, in the description of the present invention, if it is determined that a detailed description of a related known technology may unnecessarily obscure the gist of the present invention, the detailed description thereof will be omitted.

First, the gateway device for heterogeneous communication protocol data communication according to an embodiment of the present invention (hereinafter referred to as 'the present invention') is a main PCB configured to include a power supply unit, an MCU unit, and an ethernet port. And, a port unit corresponding to the communication protocol, a transceiver supporting the port unit and the communication protocol, and a conversion unit for bidirectional protocol conversion between the communication protocol according to the hardware specification and the Modbus TCP It may be configured to include a sub-PCB configured, and a coupling unit that allows the sub-PCB to be detachably coupled to the main PCB in a slot coupling manner.

Here, the MCU unit may provide a UI for setting conversion between the communication protocol and Modbus TCP in the user terminal through a web browser, wherein the UI is the Ethernet port unit through a setting screen in the user terminal It can be configured so that conversion can be set by accessing the IP address set in .

Furthermore, the UI is configured to control the data flow by setting a modbus map for each sub-PCB coupled through the coupling unit in the user terminal, a communication protocol interpretation method, and a data transmission/reception relationship, The MCU unit may be configured to upload a file of a communication map to match and convert the maps between the respective protocols.

In addition, the MCU unit may be configured to record data transmission/reception relationship-data flow information set by the user terminal, and the sub-PCB may be configured to record the Modbus map and protocol analysis information.

In addition, the MCU unit may be configured to include a slot data flow control module for data flow control and a slot data collection module for data monitoring.

Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings.

1 is a block diagram showing the system configuration of the present invention, and a main PCB (Main board) is configured to include a power supply unit, an MCU unit, and an Ethernet port unit (Ethernet port).

And the sub-PCB (Sub board) is configured by including a Dsub port or an input port suitable for each protocol in each part, and includes a transceiver suitable for each protocol.

2 is a diagram showing the configuration of the main PCB and the sub-PCB of the present invention.

Referring to FIG. 2, the present invention provides a main PCB (main board) equipped with an Ethernet port and MCU, and a transceiver supporting various ports (RS232, CAN, RS485, LoRa, WiFi) and communication protocols ( Various communication protocols can be converted to modbus TCP by combining a sub board (sub board) equipped with a tranceiver.

3 is a diagram illustrating a map setting screen when changing a Modbus by connecting to an Ethernet port for setting of the present invention. Referring to the drawing, the conversion setting is performed by connecting the main PCB to an IP address set in the Ethernet port of the main PCB through the setting screen of a web browser (webserver) in the user's PC, so that the main PCB provides a UI to set the conversion. can

Here, the user terminal (PC, etc.) can specify the Modbus map for each slot and the communication protocol interpretation method on the setting screen by the user, and can control the data flow by setting the data transmission/reception relationship by designating between modules, and By uploading a file (csv file, xml file, etc.), it can be converted by matching the map between each protocol.

4 is a diagram showing the software configuration of the present invention. Referring to the drawings, the subPCB may be configured to include a protocol according to the hardware specification and a bidirectional protocol converter between Modbus TCP.

WebServer of main PCB provides UI for gateway setting, data transmission/reception relationship set by user - data flow information is recorded in main PCB (Main), and Modbus map and protocol interpretation information are recorded in corresponding sub PCB (Sub) . And based on this data relationship information, the slot data aggregator and the slot data flow controller are executed.

The slot data flow controller can perform real-time data monitoring on the main PCB at the same time as the data flow control, and for this purpose, data can be recorded in the slot data collection unit.

Hereinafter, the software configuration of the MCU of the present invention, in particular, the communication structure of the present invention, the map setting process, the connection configuration of communication devices, and the setting mechanism for communication with these devices will be looked at. Prior to this, an integrated HMI (All in One - HMI) to be described later is a software configuration of the MCU of the present invention. Hereinafter, the integrated HMI will be described as an embodiment.

First, FIG. 5 is a diagram illustrating a communication data flow diagram according to an embodiment of the present invention. Referring to the drawings, communication data is collected into one data bundle through BPM and IMB.

In detail, firstly, communication data of ESS PCS and BMS is collected from BPM, and the data is serviced to Modbus Server, and secondly, the remaining communications are collected from IMB's Python program and serviced again as Modbus Server.

And finally, the HMI gets data from Modbus Server of Python and uses it for UI configuration. At this time, the HMI program communicates with Cloud Service (EMS).

For interworking, communication data can be reconfigured in a tree form to perform http service.

Hereinafter, in the communication setting of the present invention, a detailed device configuration will be described.

First, although the communication configuration method according to the device type has been described above, in reality, a device of the same type may be configured with a different communication protocol. Here, the protocol includes the specification of data transmission and reception as well as the change of the data model. Therefore, the communication program expressed in the data flow diagram of FIG. 5 should be able to respond flexibly according to the communication type of each device.

Table 1 shows examples of devices of the same type having these different protocols, and in the data flow diagram, each program may correspond as shown in Table 2.

device	category
BMS	- BBMS method (CAN communication) - BSC method (Modbus Tcp/Ip)
Power Meter	- GIPAM - VIPAM

program	response action
uPMS	- Response to protocol specification changes (CAN, RS485, TCP/IP...)
Python PMS	- Modbus map relocation
HMI	- Building a common data model

On the other hand, in the data flow chart, the change of the communication protocol for each program in Table 2 can be corresponded as follows.

In the case of uPMS, uPMS is performed in BPM and is responsible for communication between ESS PCS and BMS. Basically, uPMS must be able to collect data by converting changes in physical communication specifications (CAN communication <-> serial communication) and provide consistent data service to the Modbus Server.

In the case of Python PMS, Python PMS serves the final Modbus data model, and there is a requirement for mapping the power meter and related data without processing, so in Python PMS, data is collected without processing each Modbus data. It should be able to service data with one Modbus Server.

Also, since Python PMS can change the number of Modbus registers according to protocol changes, it is necessary to know the size of the register area and the address for the remapping address, which can be changed with the configuration file.

Python PMS can change the Modbus Client, register area, and remapping address according to the configuration file in Table 3.

config file	role
device-def.xml	It includes information about the communication address of the devices that will collect the communication, and the file name that describes the protocol and data model. If the communication address is changed, this file must be modified.
data-model-{device name}.xml	Describes the data model (register area) corresponding to {device name}. When a register is changed in the Modbus protocol, the corresponding contents must be reflected in this configuration file, or the newly created file name must be reflected in device-def.xml after writing a new data model.
route-map-def.xml	Describes the data configuration to be serviced to the final Modbus server. That is, it is determined to which address each data of each communication device is mapped. When the data area is changed or the meaning of data is changed, it must be reflected in this setting file.

Meanwhile, although these configuration files are statically created in Table 2, it goes without saying that the configuration files of Table 2 may be dynamically reflected and generated in order to dynamically respond to a protocol change.

Looking at HMI, the HMI program is in charge of UI configuration and scheduling operations based on the Modbus data model of Python PMS.

Here, since the final Modbus data model may be changed according to the detailed configuration of communication devices, it is possible to build an internally consistent data model by considering these models in the HMI. In this case, the HMI can build a data model with a hierarchical name space similar to a file system through the configuration file in Table 4.

config file	role
renderer-info.yaml	It is a configuration file containing information that maps Modbus addresses and data types to a specific namespace. Ex) The following item maps Modbus 7 address to the name space of bms/802/SoC.
	bms - address: 7 description: Rack SOC len: 1 name: 802.SoC scale: 10.0 type: unit16 unit: '%'
model-config.yaml	It is a configuration file that contains the relative Modbus offset address and data group information in the namespace configuration.

6 is a diagram showing a data flow diagram of the present invention, and the data model transformation of each program can be summarized as shown in FIG. Referring to the drawings, data are collected through primary communication in uPMS, and these collected data are collected in secondary communication in Python PMS, and finally can be provided as UI and HTTP services in HMI.

Hereinafter, a dynamic communication configuration and application scheme design will be described.

First, the design concept uses a method of dynamically generating configuration files to reflect the dynamic configuration of communication devices while maintaining the structure of the existing program. Here, dynamic creation requires two types of configuration files, the first is a configuration file containing information specific to each device, and the second is a configuration file containing all-in-one configuration information.

Looking at the dual device configuration files, as shown in Table 5, the configuration files represent files to be created in advance for each device, and these configuration files are stored in the configuration file pool for each device, and if necessary, the files are taken and combined. The files described in Tables 3 and 4 are created.

config file name	Explanation
{device-id}--data- model.yaml	Describes the data model area of the device. Separate each device name with a prefix.
{device-id}--route- map.tmpl	It determines where each set of registers on the device maps to an internal Modbus address.
{device-id}--renderer- info.yaml	Describes the information required to map the device's Modbus data model to the namespace. You can see the existing renderer-info.yaml as a file created by subdividing each device.
{device-id}--model- group.tmpl	Describes the information to be used when composing the Modbus data model of the device as a measurement product.

7 shows an embodiment of the concept of creation of a configuration file.

Referring to the drawing, for example, if three files of Device A, B, and C are combined, each device setting file is combined and the route-map-def.yaml, renderer-info.yaml, and model-config.yaml Three files are created, and date-model is copied as it is with the device name as a suffix, creating a total of six files.

Here, each device setting file is created by the developer and embedded in the program at the time the program is compiled, but if a setting file related to the outside of the program exists later, it may be changed so that the corresponding file takes precedence over the built-in setting file.

On the other hand, in addition to the predefined setting file for each device, information on which devices are connected and installed at the site where the integrated (All In One) equipment is installed is required. Indicates the configuration files to be described.

config file name	Explanation
nameplate.yaml	Describes the type of All in One equipment (new and renewable linkage type, peak cut type, integrated type, etc.) and connected device information.
device-def-info.yaml	Describes connection information (network address, etc.) of each device and device type. According to the information described here, it is decided which setting file to be combined with from the device setting file pool described in "2. Device setting file".
modbus-offset.yaml	When each communication device is internally remapped to the Modbus address space, the Offset address is determined. Unless a new type of device is added, it is commonly used without change. (TBD)

In Table 6, nameplate.yaml and device-def-info.yaml should be changed according to the type of integrated (All In One) equipment and installation information at the site, and these files cannot be manipulated by the user (installation engineer). It contains enough information and additionally, a GUI program can be configured to make it easier. FIG. 8 shows a configuration file for the setting file nameplate.yaml in the above, and FIG. 9 shows a configuration file for device-definfo.yaml.

According to the above description, the order of the generated files may be exemplarily represented as follows. First, an All In One configuration file (nameplate.yaml, device-definfo.yaml) is created separately for each site, and a device setting file is created.

At this time, each device setting file is built into the program in advance, and the device setting files selected by the above-described All In One configuration file are combined to dynamically create the setting files of Tables 3 and 4. When the configuration files of Tables 3 and 4 are created like this (At this time, the integration - HMI program does not know whether the file is dynamically created or not), the integration (All In One) - HMI program builds the data model according to the flow of FIG. do.

Since the data model is a consistent model that conceptually integrates the detailed communication model below, it is possible to express UI or perform manipulations in a consistent way. That is, ultimately, by manipulating the two files nameplate.yaml and device-def-info.yaml, it is possible to respond to the communication device connected to the integration (All In One).

Although the present invention has been described with reference to the embodiment shown in the drawings, which is merely exemplary, it will be understood by those skilled in the art that various modifications and equivalent other embodiments are possible therefrom. Therefore, the true technical protection scope of the present invention should be determined by the technical spirit of the appended claims.

Claims (5)

1. a main PCB configured to include a power supply unit, an MCU unit, and an Ethernet port unit;

   A port unit corresponding to a communication protocol, a transceiver supporting the port unit and the communication protocol, and a conversion unit for bidirectional protocol conversion between a communication protocol according to hardware specifications and Modbus TCP. sub PCB; and

   A gateway device for heterogeneous communication protocol data communication, characterized in that it comprises; a coupling unit for detachably coupling the sub PCB to the main PCB in a slot coupling method.
2. The method of claim 1,

   The MCU unit,

   Provides a UI (user interface) to set conversion between the communication protocol and Modbus TCP through a web browser, and the UI is connected to the IP address set in the Ethernet port in the user terminal to set the conversion A gateway device for heterogeneous communication protocol data communication, characterized in that it is configured to be
3. 3. The method of claim 2,

   The UI is

   By setting the modbus map, communication protocol interpretation method, and data transmission/reception relationship for each sub-PCB to be connected, data flow can be controlled,

   The MCU unit,

   The gateway device for heterogeneous communication protocol data communication, characterized in that it is configured to be converted by matching maps between protocols by uploading setting files for the connected sub-PCB information and integrated configuration information.
4. 4. The method of claim 3,

   The MCU unit,

   Data transmission/reception relationship-data flow information set by the user terminal is recorded,

   The sub-PCB,

   A gateway device for heterogeneous communication protocol data communication, characterized in that the Modbus map and communication protocol analysis information are recorded.
5. 5. The method of claim 4,

   The MCU unit,

   A gateway device for heterogeneous communication protocol data communication, characterized in that it comprises a slot data flow control module for data flow control, and a slot data collection module for data monitoring.

Images