CN117707809A

CN117707809A - OPCDA server identification method, device, electronic equipment and storage medium

Info

Publication number: CN117707809A
Application number: CN202311809117.XA
Authority: CN
Inventors: 张晓燕
Original assignee: Beijing Topsec Technology Co Ltd; Beijing Topsec Network Security Technology Co Ltd; Beijing Topsec Software Co Ltd
Current assignee: Beijing Topsec Technology Co Ltd; Beijing Topsec Network Security Technology Co Ltd; Beijing Topsec Software Co Ltd
Priority date: 2023-12-26
Filing date: 2023-12-26
Publication date: 2024-03-15

Abstract

The application provides an OPCDA server identification method, an apparatus, an electronic device and a storage medium, wherein the method comprises the following steps: transmitting a first request to a remote call port of a remote end to activate an instance object of the remote end, and acquiring a dynamic port for monitoring an OPCDA server; sending a second request to the dynamic port, and enumerating a remote OPCDA server list through a second function of a second interface in the second request; sending a third request to the dynamic port, and traversing the OPCDA server list through a third function of a third interface in the third request; and sending a fourth request to each OPCDA server traversed, and acquiring the information of each OPCDA server through a fourth function of the second interface in the fourth request. In the application, a transmitting end is connected with a remote call port at a far end, and an OPCDA server is identified from a protocol layer. The OPCDA server is identified under the linux platform, so that the cost is reduced, and the efficiency is improved.

Description

OPCDA server identification method, device, electronic equipment and storage medium

Technical Field

The present invention relates to the field of industrial control, and in particular, to an OPCDA server identification method, an apparatus, an electronic device, and a storage medium.

Background

The monitoring and management of the OPCDA server are all in Windows system, and the scanning device or the identification product for identifying and scanning the OPCDA server is mostly developed under Linux platform. Currently, the scanning device or the identification product needs to realize the identification or scanning of the OPCDA server through an additional Windows proxy or gateway program, so that the cost is high and the efficiency is low.

Disclosure of Invention

In view of the foregoing, an object of an embodiment of the present application is to provide an OPCDA server identification method, apparatus, electronic device, and storage medium, which can reduce the cost of OPCDA server identification and improve the OPCDA server identification efficiency.

In a first aspect, an embodiment of the present application provides an OPCDA server identifying method, by sending a first request to a remote call port at a remote end to activate an OPCEnum instance object at the remote end, and acquiring a dynamic port for monitoring the OPCDA server; sending a second request to the dynamic port, and enumerating a remote OPCDA server list through a second function of a second interface in the second request; sending a third request to the dynamic port, and traversing the OPCDA server list through a third function of a third interface in the third request; and sending a fourth request to each OPCDA server traversed, and acquiring information of each OPCDA server through a fourth function of the second interface in the fourth request.

In the implementation process, when the sending end identifies the OPCDA server, connection is established through a remote call port at a far end, a request packet is constructed from a protocol layer based on a DCERPC protocol, and the OPCDA server is detected and identified through the request packet. The OPCDA server can be directly identified under the linux platform without additional Windows agents or gateway programs; the implementation program has simple structure and convenient deployment, can reduce the cost of OPCDA server identification and improve the OPCDA server identification efficiency.

In one embodiment, the first request includes a first Bind request and a first RPC request packet; the step of sending a first request to the remote call port of the remote to activate the remote OPCEnum instance object and obtaining a dynamic port for monitoring the OPCDA server includes: establishing connection with the remote call port of the remote end; sending the first Bind request to the remote call port at the remote end, and binding a first interface according to the first Bind request; after the first interface is successfully bound, the first RPC request packet is sent to the remote call port at the far end; and calling a first function according to a first function identifier in the first RPC request packet, activating a remote OPCEnum instance object through the first function, and acquiring a dynamic port for monitoring the OPCDA server.

In the implementation process, a first Bind request is sent to a remote call port at a remote end to Bind a first interface, and a first function is requested Bao Diaoyong through a first RPC, wherein the first function can be used for activating an OPCEnum instance object so as to activate the OPCEnum instance object through a request packet at a protocol level, and the linux platform is directly used for activating an instance object of an OPCDA server without an additional Windows agent or gateway program; the method has the advantages of simple program structure and convenient deployment, can reduce the cost of the activation of the OPCEnum instance object and improve the activation efficiency of the OPCEnum instance object.

In one embodiment, the obtaining a dynamic port for listening to the OPCDA server comprises: acquiring an execution result returned by the first RPC request packet, wherein the execution result comprises port binding information and a remote object IPID, and the remote object IPID is the IPID of the OPCEnum instance object; and determining the dynamic port of the OPCDA server according to the execution result.

In the implementation process, the dynamic port for monitoring the OPCDA server is determined according to port binding information and a remote object IPID in an execution result returned by executing the first RPC request packet, so that connection is directly established with the dynamic port in subsequent service, protocol layer connection between a linux system and the Windows platform is established in a COM or DCOM environment of the Windows platform, and the linux platform directly determines the dynamic port according to the execution result fed back by the remote end without an additional Windows agent or gateway program; the method has the advantages of simple program structure and convenient deployment, and can reduce the cost of dynamic port determination and improve the efficiency of dynamic port determination.

In one embodiment, wherein the second request includes a second Bind request and a second RPC request packet; the sending a second request to the dynamic port, enumerating, by a second function of a second interface in the second request, a remote OPCDA server list, including: establishing connection with the dynamic port; sending the second Bind request to the dynamic port, and binding the second interface according to the second Bind request; after the second interface is successfully bound, sending the second RPC request packet to the dynamic port; and calling a second function according to a second function identifier in the second RPC request packet, and enumerating a remote OPCDA server list through the second function.

In the implementation process, a second Bind request is sent to a remote call port of a far end to Bind a second interface, and a second function is requested Bao Diaoyong through a second RPC, wherein the second function can be used for enumerating an OPCDA server list of the far end so as to enumerate the OPCDA server list of the far end through a request packet in a protocol layer, and the linux platform is directly used for enumerating the OPCDA server list in the far end without additional Windows agents or gateway programs; the method has the advantages of simple program structure and convenient deployment, can reduce the cost of remote OPCDA server list enumeration and improve the remote OPCDA server list enumeration efficiency.

In one embodiment, wherein the fourth request comprises a fourth RPC request packet; the sending a fourth request to each traversed OPCDA server, and obtaining the information of each OPCDA server through the fourth function of the second interface in the fourth request, including: after the second interface is successfully bound, the fourth RPC request packet is sent to the dynamic port; and calling a fourth function according to a fourth function identifier in the fourth RPC request packet, and acquiring information of each OPCDA server through the fourth function.

In one embodiment, the remote object IPID in the fourth RPC request packet is the remote object IPID determined by the first RPC request packet, where the remote object IPID is the IPI of the OPCEnum instance object; and the fourth service identifier in the fourth RPC request packet is the first service identifier in the first RPC request packet.

In the implementation process, when the information of the OPCDA server is acquired, the second interface bound by the second Bind request is directly and repeatedly utilized to perform data packet interaction, and connection with the interface in the dynamic port is not required to be re-established, so that the information acquisition process of the OPCDA server is simplified, and the information acquisition efficiency of the OPCDA server is improved. In addition, through the fourth RPC request Bao Diaoyong, the fourth function can be used for acquiring information of the OPCDA server, so as to acquire the information of the OPCDA server through a request packet in a protocol layer, and the linux platform can directly acquire the information of the OPCDA server in a far end without an additional Windows agent or gateway program; the implementation program has simple structure and convenient deployment, can reduce the acquisition cost of the OPCDA server information and improve the acquisition efficiency of the OPCDA server information in the remote end.

In one embodiment, the third request includes a third Bind request and a third RPC request packet; the sending a third request to the dynamic port, traversing the OPCDA server list through a third function of a third interface in the third request, including: establishing connection with the dynamic port; sending the third Bind request to the dynamic port, and binding the third interface according to the third Bind request; after the third interface is successfully bound, sending the third RPC request packet to the dynamic port; and calling a third function according to a third function identifier in the third RPC request packet, and traversing the OPCDA server list through the third function.

In the implementation process, a third Bind request is sent to a remote call port of the far end to Bind a third interface, and a third function is requested Bao Diaoyong through a third RPC, wherein the third function can be used for traversing the OPCDA server list so as to realize traversing the remote OPCDA server list through a request packet in a protocol layer, and the linux platform directly traverses the remote OPCDA server list without an additional Windows agent or gateway program; the method has the advantages of simple program structure and convenient deployment, can reduce the cost of traversing the far-end OPCDA server list and improve the efficiency of traversing the far-end OPCDA server list.

In a second aspect, embodiments of the present application further provide an OPCDA server identifying apparatus, including: the activation module is used for sending a first request to the remote call port of the remote end to activate the OPCEnum instance object of the remote end and acquiring a dynamic port for monitoring the OPCDA server; an enumeration module, configured to send a second request to the dynamic port, and enumerate a remote OPCDA server list through a second function of a second interface in the second request; the traversing module is used for sending a third request to the dynamic port, and traversing the OPCDA server list through a third function of a third interface in the third request; and the acquisition module is used for sending a fourth request to each OPCDA server traversed and acquiring the information of each OPCDA server through a fourth function of the second interface in the fourth request.

In a third aspect, embodiments of the present application further provide an electronic device, including: a processor, a memory storing machine-readable instructions executable by the processor, which when executed by the processor, perform the steps of the method of the first aspect, or any of the possible implementations of the first aspect.

In a fourth aspect, embodiments of the present application further provide a computer readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of the OPCDA server identification method of the first aspect, or any one of the possible implementations of the first aspect.

In order to make the above objects, features and advantages of the present application more comprehensible, embodiments accompanied with figures are described in detail below.

Drawings

In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present application and therefore should not be considered limiting the scope, and that other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

Fig. 1 is a schematic diagram of interaction between a transmitting end and a remote end provided in an embodiment of the present application;

fig. 2 is a schematic block diagram of a transmitting end according to an embodiment of the present application;

fig. 3 is a flowchart of an OPCDA server identification method provided in an embodiment of the present application;

Fig. 4 is a schematic functional block diagram of an OPCDA server identification apparatus provided in an embodiment of the present application.

Detailed Description

The technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application.

It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures. Meanwhile, in the description of the present application, the terms "first", "second", and the like are used only to distinguish the description, and are not to be construed as indicating or implying relative importance.

In an industrial environment, various industrial control devices and industrial control systems perform various important production tasks. The OPCDA server program is a relatively common industrial control service program. In the safety evaluation of the industrial control environment, if the OPCDA server can be accurately found, the safety workers can be effectively helped to complete the safety guarantee works of asset census, safety evaluation, service reinforcement and the like of the industrial control environment.

OPC (Object Linking and Embedding (OLE) for Process Control, its advent has bridged Windows-based applications and field process control applications. In the past, each application developer had to write a specific interface function in order to access the data information of the field device. Because of the wide variety of field devices and the continual upgrading of products, great workload is often brought to users and software developers. System integrators and developers are eagerly demanding a plug-and-play device driver with high efficiency, reliability, openness, interoperability. In this case, OPC standards have been developed. The OPC specification is based on Microsoft Windows technology, using COM/DCOM (distributed component object model) to exchange data between software components.

In recent years, with the rise of intelligent manufacturing, equipment networking is a necessary path for informatization construction of various large-scale production enterprises, and equipment data acquisition mainly uses the function of OPCDA for transmitting production data, process data and real-time state of equipment. OPC AE and OPC HDA are mainly used in some specific devices and systems.

The inventor of the application finds out through long-term research that in the safety evaluation work of an industrial control environment, aiming at the requirement of finding out an OPCDA server, the current asset scanning or missing scanning products are all based on development under a Linux platform, the development language is inconvenient to directly call an interface of a DCOM component, and the device deployment difficulty can be increased by introducing a Windows agent to call the interface of the DCOM component only.

In view of this, in the present application, when the transmitting end performs OPCDA server identification, a connection is established with a remote call port at a remote end, a request packet is constructed from a protocol layer based on the DCERPC protocol, and the OPCDA server is detected and identified by the request packet. The OPCDA server can be directly identified under the linux platform without additional Windows agents or gateway programs; the implementation program has simple structure and convenient deployment, can reduce the cost of OPCDA server identification and improve the OPCDA server identification efficiency.

For the sake of understanding the present embodiment, first, a detailed description will be given of an operating environment for executing an OPCDA server identification method disclosed in the embodiments of the present application.

Fig. 1 is a schematic diagram of interaction between a transmitting end and a remote end according to an embodiment of the present application. The transmitting end is in communication connection with one or more remote ends through the switch to perform data communication or interaction.

Wherein the remote end is a device for managing installation of the OPCDA server device. The remote end may be a web server, a database server, etc., or may be a personal computer (personal computer, PC), a tablet computer, a smart phone, a personal digital assistant (personal digital assistant, PDA), etc. The distal end may be selected according to the actual circumstances.

The installation OPCDA server device herein is typically various industrial control devices, industrial control systems, etc. in an industrial environment.

It should be appreciated that the OPC specification is a specification standard based on Microsoft Windows technology that uses COM/DCOM (distributed component object model) to exchange data between software components. Therefore, the remote end is developed based on the Windows platform, and various interfaces of the remote end are Windows standard interfaces.

The transmitting end is an asset scanning or inquiring device, and the transmitting end can be a network server, a database server and the like, and can also be a personal computer (personal computer, PC), a tablet computer, a smart phone, a personal digital assistant (personal digital assistant, PDA) and the like. The transmitting end can be selected according to actual conditions.

It will be appreciated that current asset scanning, or asset querying products are developed under the Linux platform. Thus, the development language of the transmitting end is Linux related language.

For the sake of understanding the present embodiment, a detailed description will be first given of a transmitting end that performs the OPCDA server identification method disclosed in the embodiments of the present application.

As shown in fig. 2, a block diagram of the transmitting end is shown. The sender 100 may include a memory 111, a processor 113. It will be appreciated by those skilled in the art that the structure shown in fig. 2 is merely illustrative, and is not intended to limit the structure of the transmitting end 100. For example, the sender 100 may also include more or fewer components than shown in fig. 2, or have a different configuration than shown in fig. 2.

The memory 111 and the processor 113 are directly or indirectly electrically connected to each other to realize data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines. The processor 113 is used to execute executable modules stored in the memory.

The Memory 111 may be, but is not limited to, a random access Memory (Random Access Memory, RAM), a Read Only Memory (ROM), a programmable Read Only Memory (Programmable Read-Only Memory, PROM), an erasable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), an electrically erasable Read Only Memory (Electric Erasable Programmable Read-Only Memory, EEPROM), etc. The memory 111 is configured to store a program, and the processor 113 executes the program after receiving an execution instruction, and a method executed by the sender 100 of the process definition disclosed in any embodiment of the present application may be applied to the processor 113 or implemented by the processor 113.

The processor 113 may be an integrated circuit chip having signal processing capabilities. The processor 113 may be a general-purpose processor, including a central processing unit (Central Processing Unit, CPU for short), a network processor (Network Processor, NP for short), etc.; but also digital signal processors (digital signal processor, DSP for short), application specific integrated circuits (Application Specific Integrated Circuit, ASIC for short), field Programmable Gate Arrays (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.

The transmitting end 100 in this embodiment may be used to perform each step in each method provided in the embodiments of the present application. The implementation of the OPCDA server identification method is described in detail below by several embodiments.

Referring to fig. 3, a flowchart of an OPCDA server identification method according to an embodiment of the present application is shown. The specific flow shown in fig. 3 will be described in detail.

In step 201, a first request is sent to a remote call port at the remote end to activate an OPCEnum instance object at the remote end, and a dynamic port for monitoring an OPCDA server is acquired.

Wherein the first request includes a first Bind request and a first RPC request packet. The first Bind request is a system call function that binds the network socket to the specified IP address and port to snoop network connection requests on that address and port. The first RPC request packet is a data packet for sending a request, and the first RPC request packet may include data such as a first function identifier, a first service identifier, a sender identifier, and the like. The specific data in the first RPC request packet may be selected according to the actual situation.

The remote call port here is an RPC service (chinese name: remote procedure call protocol) port in the remote system. Wherein the RPC service is used to enable a program running at a remote end to successfully execute codes on other remote devices.

In one embodiment, the system in the remote end is a Windows system and the remote call port is a TCP 135 port. The TCP 135 port is mainly used for using RPC protocol and providing DCOM (Microsoft Distributed Component Object Model, chinese name: distributed component object model) service. Through the DCOM service, the sender program object can request program objects from other remote ends in the network.

The OPCEnum instance object is a common tool for performing device management in a remote end, and is used for enumerating registered OPCDA servers on computers such as various industrial control devices and industrial control systems.

A dynamic port is herein a port that is not fixedly assigned a certain service but is dynamically assigned, which means that when a system process or application process requires network communication, it applies for a port to the host, which allocates one from the available port numbers for its use. When this process is shut down, the occupied port number is also released.

In one embodiment, the dynamic port may be a TCP 1035 port.

It should be understood that, after the remote end obtains the first RPC request packet, an execution result is returned to the sender, where the execution result may include an address and a port number of the dynamic port allocated by the remote end.

Step 202, sending a second request to the dynamic port, and enumerating the remote OPCDA server list through a second function of the second interface in the second request.

Wherein the second request includes a second Bind request and a second RPC request packet. The second Bind request is a system call function that binds the network socket to the specified IP address and port to snoop network connection requests on that address and port. The second RPC request packet is a data packet for sending a request, where the second RPC request packet may include data such as a second function identifier, a second service identifier, a sender identifier, and the like. The specific data in the second RPC request packet may be selected according to the actual situation.

The second interface here includes a plurality of functions therein. Wherein a second interface in the second function is used to enumerate the functions of the list.

Step 203, a third request is sent to the dynamic port, and the OPCDA server list is traversed by a third function of a third interface in the third request.

Wherein the third request includes a third Bind request and a third RPC request packet. The third Bind request is a system call function that binds the network socket to the specified IP address and port to snoop network connection requests on that address and port. The third RPC request packet is a data packet for sending a request, and the third RPC request packet may include data such as a third function identifier, a third service identifier, a sender identifier, and the like. The specific data in the third RPC request packet may be selected according to the actual situation.

The third request interface here includes a plurality of functions therein. Wherein the third request function is a function in the third request interface for traversing the list.

Step 204, sending a fourth request to each OPCDA server traversed, and obtaining the information of each OPCDA server through a fourth function of the second interface in the fourth request.

Wherein the fourth request includes a fourth Bind request and a fourth RPC request packet. The fourth Bind request is a system call function that binds the network socket to the specified IP address and port to snoop network connection requests on that address and port. The fourth RPC request packet is a data packet for sending a request, and the fourth RPC request packet may include data such as a fourth function identifier, a fourth service identifier, a sender identifier, and the like. The specific data in the fourth RPC request packet may be selected according to the actual situation.

Optionally, some or all of the first Bind request, the second Bind request, the third Bind request, and the fourth Bind request may be the same or different. The specific request contents of the first Bind request, the second Bind request, the third Bind request and the fourth Bind request can be adjusted according to actual situations.

In one possible implementation, step 201 includes: establishing connection with a remote call port at a remote end; sending a first Bind request to a remote call port at a remote end, and binding a first interface according to the first Bind request; after the first interface is successfully bound, a first RPC request packet is sent to a remote call port at a far end; and calling the first function according to the first function identifier in the first RPC request packet, activating the remote OPCEnum instance object through the first function, and acquiring a dynamic port for monitoring the OPCDA server.

The first Bind request may include an interface identifier of the first interface. For example, if the first interface is an isystem activator, the first Bind request may include a first interface identifier corresponding to the first interface: 000001a0-0000-0000-c000-000000000046.

It is understood that after the remote end obtains the first Bind request, the remote end binds the corresponding first interface according to the first interface identifier in the first Bind request, and returns a binding result to the sending end after the first interface is bound. If the first interface corresponding to the first Bind request is successfully bound, continuing to call a first function in the first interface, and executing corresponding service. If the binding fails, the action is terminated.

The first interface may include a plurality of functions, where each function corresponds to a corresponding function identifier. And determining to call a first function corresponding to the first function identifier according to the first function identifier in the first RPC request packet.

In one implementation, the first function is remoteceateinstance. The first function is used to create a reference for an instance object.

Optionally, the functions in the first interface may sequentially set corresponding function identifiers according to a set order. For example, opnum 1, opnum 2, opnum 3, opnum 4, etc., each function identifies a function in a corresponding one of the first interfaces. The function identification of each function in the defined interface can be adjusted according to actual conditions.

Illustratively, if the first function is remoteceateinstance, the first function identifier in the first RPC request packet may be opnum 4.

It will be appreciated that each time the sender sends an RPC request packet to the remote end, there may be a difference in the traffic that the requesting remote end performs. Therefore, each time the sending end sends the RPC request packet to the remote end, the corresponding service identity and the remote end unique identification code are contained.

In one embodiment, the first service identity in the first RPC request packet may be f6805d6a-c30b-43d5-a8f6-d064e4ac17ec; if the instance object class identifier in the first RPC request is 13486d51-4821-11d2-a494-3cb306c10000, the remote unique identifier is the interface unique identifier of the IOPCServerList interface; if the identifier of the interface ID in the first RPC request is 13486d50-4821-11d2-a494-3cb306c10000, the remote unique identifier is a class unique identifier of the class where the IOPCServerList interface is located.

In one possible implementation, acquiring a dynamic port for listening to an OPCDA server includes: acquiring an execution result returned by the first RPC request packet; and determining the dynamic port of the OPCDA server according to the execution result.

The execution result includes port binding information and a remote object IPID.

The port binding information here may include a port address and a port number. For example, networkAddr 10.7.169.23[1035] represents a 1035 port bound at the far end.

The remote object IPID is the IPID of the OPCEnum instance object. For example, the IPID of the OPCEnum instance object may be expressed as: 0000c404-06cc-0ba8-0941-9ed7b48bb056, the execution result may include the identification 0000c404-06cc-0ba8-0941-9ed7b48bb 056.

It should be understood that, because the execution result includes the binding information of the first port and the remote object IPID, the sending end may determine the dynamic port allocated by the remote end according to the binding information of the first port, and establish connection with the remote end again through the dynamic port. The sending end can also determine the remote object to be accessed according to the remote object IPID so as to access the corresponding remote object in the subsequent service.

In one possible implementation, step 202 includes: establishing connection with a dynamic port; sending a second Bind request to the dynamic port, and binding a second interface according to the second Bind request; after the second interface is successfully bound, a second RPC request packet is sent to the dynamic port; and calling a second function according to a second function identifier in the second RPC request packet, and enumerating a remote OPCDA server list through the second function.

Wherein, the second Bind request may include an interface identifier of the second interface. For example, if the second interface is IOPCServerList, the second Bind request may include a second interface identifier corresponding to the second interface: 13486d50-4821-11d2-a494-3cb306c10000.

It should be understood that after the remote end obtains the second Bind request, the remote end binds a corresponding second interface according to the interface identifier in the second Bind request, and returns a binding result to the sending end after the second interface is bound. If the interface binding corresponding to the second Bind request is successful, the function in the second interface is continuously called, and corresponding service is executed. If the binding fails, the action is terminated.

The result of the execution here includes IPID representing the iterative object of the OPCDA server. The IPID includes a list of OPCDA servers in the remote end.

The second interface may include a plurality of functions, where each function corresponds to a corresponding function identifier. And determining to call a second function corresponding to the second function identifier according to the second function identifier in the second RPC request packet.

In one implementation, the second interface is an IOPCServerList and the second function is an enumclassesofcategory function. The second function is used to enumerate a remote OPCDA server list.

Optionally, the functions in the second interface may sequentially set corresponding function identifiers according to a set order. For example, opnum 1, opnum 2, opnum 3, opnum 4, etc., each function identifies a function in a corresponding one of the second interfaces. The function identification of each function in the defined interface can be adjusted according to actual conditions.

Illustratively, if the second function is an enumclassofcategory function, the second function identification in the second RPC request packet may be opnum 3.

The second RPC request packet may further include an OPCDA server version and an OPCEnum instance object identifier.

It should be appreciated that as OPCDA servers continue to develop, there may be a number of different versions of the OPCDA servers. For example, OPCDA server version 1.0, OPCDA server version 1.1, OPCDA server version 2.0, OPCDA server version 3.0, and the like. Versions of OPCDA servers installed in different industrial control devices or industrial control systems may be different, and when the transmitting end identifies the OPCDA servers, the transmitting end may identify or manage the OPCDA servers according to the different versions. Thus, the OPCDA server version may be set in the second RPC request packet to determine the corresponding version of OPCDA server that currently needs to be identified.

In one possible implementation, step 204 includes: after the second interface is successfully bound, a fourth RPC request packet is sent to the dynamic port; and calling a fourth function according to a fourth function identifier in the fourth RPC request packet, and acquiring the information of each OPCDA server through the fourth function.

The interface for acquiring the information of each OPCDA server is connected with the interface for enumerating the remote OPCDA server list. That is, the dynamic port connection in step 202 described above may be directly reused in acquiring information of each OPCDA server.

It should be understood that, since step 204 and step 202 may reuse the same interface, after enumerating the remote OPCDA server list, a fourth RPC request packet may be directly sent to the dynamic port, and a fourth function in the second interface is called, and information of each OPCDA server is obtained through the fourth function.

In one implementation, the fourth function may be a GetClassDetails function. The fourth function is used to obtain information for each OPCDA server.

The information of the OPCDA server here may include information of OPCDA server name, software name, server version, and the like. The information of the OPCDA server acquired by the fourth function can be adjusted according to actual situations.

The remote object IPID in the fourth RPC request packet is the remote object IPID determined by the first RPC request packet; the fourth service identifier in the fourth RPC request packet is the first service identifier in the first RPC request packet.

In one possible implementation, step 203 includes: establishing connection with a dynamic port; sending a third Bind request to the dynamic port, and binding a third interface according to the third Bind request; after the third interface is successfully bound, a third RPC request packet is sent to the dynamic port; and calling a third function according to a third function identifier in the third RPC request packet, and traversing the OPCDA server list through the third function.

The third Bind request may include an interface identifier of the third interface. For example, if the third interface is IEnumGUID, the third Bind request may include a third interface identifier corresponding to the third interface: 0002e000-0000-0000-c000-000000000046.

It should be understood that after the remote end obtains the third Bind request, the remote end binds a corresponding third interface according to the interface identifier in the third Bind request, and returns a binding result to the sending end after the third interface is bound. If the interface binding corresponding to the third Bind request is successful, the function in the third interface is continuously called, and corresponding service is executed. If the binding fails, the action is terminated.

The third interface may include a plurality of functions, where each function corresponds to a corresponding function identifier. And determining to call a third function corresponding to the third function identifier according to the third function identifier in the third RPC request packet.

In one implementation, the third interface is an IEnumGUID, and the second function is a Next () function. The third function is used to traverse the OPCDA server list.

Optionally, the functions in the third interface may sequentially set corresponding function identifiers according to a set order. For example, opnum 1, opnum 2, opnum 3, opnum 4, etc., each function identifies a function in a corresponding one of the third interfaces. The function identification of each function in the defined interface can be adjusted according to actual conditions.

Illustratively, if the third function is an IEnumGUID function, the second function identification in the third RPC request packet may be opnum 3.

The object ID in the third RPC request packet is the IPID representing the iterative object of the OPCDA server extracted in step 202, and the third service identity in the third RPC request packet is the first service identity in the first RPC request packet.

Based on the same application concept, the embodiment of the present application further provides an OPCDA server identification apparatus corresponding to the OPCDA server identification method, and since the principle of solving the problem by the apparatus in the embodiment of the present application is similar to that of the foregoing embodiment of the OPCDA server identification method, the implementation of the apparatus in the embodiment of the present application may refer to the description in the foregoing embodiment of the method, and the repetition is omitted.

Fig. 4 is a schematic functional block diagram of an OPCDA server identification apparatus according to an embodiment of the present application. The respective modules in the OPCDA server identification apparatus in this embodiment are used to perform the respective steps in the above-described method embodiment. The OPCDA server identification device comprises an activation module 301, an enumeration module 302, a traversing module 303 and an acquisition module 304; wherein,

the activation module 301 is configured to activate an OPCEnum instance object at a remote end by sending a first request to the remote call port at the remote end, and obtain a dynamic port for listening to the OPCDA server.

The enumeration module 302 is configured to send a second request to the dynamic port, and enumerate a remote OPCDA server list through a second function of a second interface in the second request.

The traversing module 303 is configured to send a third request to the dynamic port, and traverse the OPCDA server list through a third function of a third interface in the third request.

The obtaining module 304 is configured to send a fourth request to each of the OPCDA servers traversed, and obtain information of each OPCDA server through a fourth function of the second interface in the fourth request.

In a possible implementation manner, the activation module 301 is specifically configured to: establishing connection with the remote call port of the remote end; sending the first Bind request to the remote call port at the remote end, and binding a first interface according to the first Bind request; after the first interface is successfully bound, the first RPC request packet is sent to the remote call port at the far end; calling a first function according to a first function identifier in the first RPC request packet; activating a remote OPCEnum instance object through the first function, and acquiring a dynamic port for monitoring the OPCDA server.

In a possible implementation manner, the activation module 301 is specifically configured to: acquiring an execution result returned by the first RPC request packet, wherein the execution result comprises port binding information and a remote object IPID, and the remote object IPID is the IPID of the OPCEnum instance object; and determining the dynamic port of the OPCDA server according to the execution result.

In one possible implementation, the enumeration module 302 is specifically configured to: establishing connection with the dynamic port; sending the second Bind request to the dynamic port, and binding the second interface according to the second Bind request; after the second interface is successfully bound, sending the second RPC request packet to the dynamic port; calling a second function according to a second function identifier in the second RPC request packet; enumerating a remote OPCDA server list by the second function.

In a possible implementation manner, the obtaining module 304 is specifically configured to: after the second interface is successfully bound, the fourth RPC request packet is sent to the dynamic port; calling a fourth function according to a fourth function identifier in the fourth RPC request packet; and acquiring information of each OPCDA server through the fourth function.

In a possible implementation manner, the traversing module 303 is specifically configured to: establishing connection with the dynamic port; sending the third Bind request to the dynamic port, and binding the third interface according to the third Bind request; after the third interface is successfully bound, sending the third RPC request packet to the dynamic port; calling a third function according to a third function identifier in the third RPC request packet; traversing the OPCDA server list by the third function.

Furthermore, the embodiment of the present application further provides a computer readable storage medium, where a computer program is stored, where the computer program is executed by a processor to perform the steps of the OPCDA server identification method described in the above method embodiment.

The computer program product of the OPCDA server identification method provided in the embodiments of the present application includes a computer readable storage medium storing program code, where the program code includes instructions for executing the steps of the OPCDA server identification method described in the above method embodiments, and the details of the method embodiments may be referred to herein and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other manners as well. The apparatus embodiments described above are merely illustrative, for example, flow diagrams and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

In addition, the functional modules in the embodiments of the present application may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.

The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes. It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising … …" does not exclude the presence of other like elements in a process, method, article or apparatus that comprises the element.

The foregoing description is only of the preferred embodiments of the present application and is not intended to limit the same, but rather, various modifications and variations may be made by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application. It should be noted that: like reference numerals and letters denote like items in the following figures, and thus once an item is defined in one figure, no further definition or explanation thereof is necessary in the following figures.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. An OPCDA server identification method, comprising:

transmitting a first request to activate a remote OPCEnum instance object to a remote call port, and acquiring a dynamic port for monitoring the OPCDA server;

Sending a second request to the dynamic port, and enumerating a remote OPCDA server list through a second function of a second interface in the second request;

sending a third request to the dynamic port, and traversing the OPCDA server list through a third function of a third interface in the third request;

and sending a fourth request to each OPCDA server traversed, and acquiring information of each OPCDA server through a fourth function of the second interface in the fourth request.

2. The method of claim 1, wherein the first request comprises a first Bind request and a first RPC request packet;

the step of sending a first request to the remote call port of the remote to activate the remote OPCEnum instance object and obtaining a dynamic port for monitoring the OPCDA server includes:

establishing connection with the remote call port of the remote end;

sending the first Bind request to the remote call port at the remote end, and binding a first interface according to the first Bind request;

after the first interface is successfully bound, the first RPC request packet is sent to the remote call port at the far end;

and calling a first function according to a first function identifier in the first RPC request packet, activating a remote OPCEnum instance object through the first function, and acquiring a dynamic port for monitoring the OPCDA server.

3. The method of claim 2, wherein the obtaining a dynamic port for listening to the OPCDA server comprises:

acquiring an execution result returned by the first RPC request packet, wherein the execution result comprises port binding information and a remote object IPID, and the remote object IPID is the IPID of the OPCEnum instance object;

and determining the dynamic port of the OPCDA server according to the execution result.

4. The method of claim 1, wherein the second request comprises a second Bind request and a second RPC request packet;

the sending a second request to the dynamic port, enumerating, by a second function of a second interface in the second request, a remote OPCDA server list, including:

establishing connection with the dynamic port;

sending the second Bind request to the dynamic port, and binding the second interface according to the second Bind request;

after the second interface is successfully bound, sending the second RPC request packet to the dynamic port;

and calling a second function according to a second function identifier in the second RPC request packet, and enumerating a remote OPCDA server list through the second function.

5. The method of claim 4, wherein the fourth request comprises a fourth RPC request packet;

the sending a fourth request to each traversed OPCDA server, and obtaining the information of each OPCDA server through the fourth function of the second interface in the fourth request, including:

after the second interface is successfully bound, the fourth RPC request packet is sent to the dynamic port;

and calling a fourth function according to a fourth function identifier in the fourth RPC request packet, and acquiring information of each OPCDA server through the fourth function.

6. The method of claim 5, wherein the remote object IPID in the fourth RPC request packet is the remote object IPID determined by the first RPC request packet, the remote object IPID being the IPID of the OPCEnum instance object;

and the fourth service identifier in the fourth RPC request packet is the first service identifier in the first RPC request packet.

7. The method of claim 1, wherein the third request comprises a third Bind request and a third RPC request packet;

the sending a third request to the dynamic port, traversing the OPCDA server list through a third function of a third interface in the third request, including:

Establishing connection with the dynamic port;

sending the third Bind request to the dynamic port, and binding the third interface according to the third Bind request;

after the third interface is successfully bound, sending the third RPC request packet to the dynamic port;

and calling a third function according to a third function identifier in the third RPC request packet, and traversing the OPCDA server list through the third function.

8. An OPCDA server identification apparatus, comprising:

the activation module is used for sending a first request to the remote call port of the remote end to activate the OPCEnum instance object of the remote end and acquiring a dynamic port for monitoring the OPCDA server;

an enumeration module, configured to send a second request to the dynamic port, and enumerate a remote OPCDA server list through a second function of a second interface in the second request;

the traversing module is used for sending a third request to the dynamic port, and traversing the OPCDA server list through a third function of a third interface in the third request;

and the acquisition module is used for sending a fourth request to each OPCDA server traversed and acquiring the information of each OPCDA server through a fourth function of the second interface in the fourth request.

9. An electronic device, comprising: a processor, a memory storing machine-readable instructions executable by the processor, which when executed by the processor perform the steps of the method of any of claims 1 to 7 when the electronic device is run.

10. A computer-readable storage medium, characterized in that it has stored thereon a computer program which, when executed by a processor, performs the steps of the method according to any of claims 1 to 7.