Alias validation

Abstract

To provide a method of constantly verifying an Alias (a string of a character that can be read by a human / has a meaning).SOLUTION: A method includes steps of: performing an inquiry of a mapping between an Alias and a connection character string of an I / O channel hosted by a scattering control node by a global discovery server (GDS); making a cross-platform client to brows an I / O channel by establishing a continuous network connection used for acquiring a list updated in a local of the mapping between the Alias and the connection character string from a local Alias database of the DCN by using the connection character string; identifying a discrepancy of the mapping between the Alias and the connection character string of the I / O channel hosted by the DCN; and establishing a temporal network connection between the cross-platform client and a GDS on the basis of the discrepancy.SELECTED DRAWING: Figure 5

Description

[Technical field]

[0001] The present invention relates to alias verification. [Background technology]

[0002] Process automation equipment may include a myriad of components, including sensors, actuators, function blocks, and distributed control nodes (DCNs), among others. Tracking these components using traditional identification techniques may result in a variety of problems. Connection strings may include network information such as the IP addresses and TCP / UDP ports of individual nodes, as well as their node IDs, used to identify individual components, such as sensors or actuators, that are accessible through the node, but are not easily interpretable by humans and do not scale easily. Therefore, architectures such as the Open Platform Communications Unified Architecture (OPC UA) may include a Global Discovery Server (GDS) that provides an "Alias ​​Name Service" (ANS) that facilitates the mapping of aliases (human-readable / meaningful strings of characters) to individual process automation nodes. In other words, the GDS can act like a "phone book" for cross-platform components, such as OPC UA clients. Summary of the Invention [Means for solving the problem]

[0003] Aliases are often defined from scratch. For example, aliases may be defined in a DCN, which may register them in a GDS. The GDS may compile a global list of mappings between one or more aliases and one or more connection strings. Over time, changes may occur in the process automation equipment. For example, additional aliases may be registered separately, hardware may fail and / or be replaced, etc.

[0004] Implementations described herein relate to having cross-platform clients, such as OPC UA clients, periodically verify aliases with cross-platform servers, such as OPC UA servers, that they have been directed to. More particularly, but not by way of limitation, implementations are described herein for using existing persistent connections between OPC UA clients and OPC UA servers. This allows for faster detection of aliases that have changed or moved and prevents additional complexity and network traffic caused by cross-platform clients reconnecting to the GDS to look for updated aliases.

[0005] The techniques described herein provide several technical advantages. Automatic identification of discrepancies between local alias databases and GDS mappings allows for improved data accuracy, which promotes increased productivity and reduced likelihood of catastrophic system failures or performance shortfalls. Additionally, validating DCN and aliases rather than establishing connections to a GDS may conserve computing resources such as network bandwidth, reduce latency, and / or improve data accuracy.

[0006] In some implementations, a method may be performed that includes querying a GDS for mappings between aliases and connection strings of input / output (I / O) channels hosted by a DCN; allowing a cross-platform client to browse the I / O channels, where the browsing includes establishing a persistent network connection between the cross-platform client and the DCN using the connection strings; obtaining a locally updated list of mappings between aliases and connection strings via the persistent network connection from a local alias database of the DCN; identifying a mismatch between the locally updated list of mappings and mappings between aliases and connection strings of I / O channels hosted by the DCN; establishing a temporary network connection between the cross-platform client and the GDS based on the mismatch; and retrieving an updated mapping between the aliases and new connection strings from the GDS via the temporary network connection.

[0007] In some implementations, the new connection string of the updated mapping is associated with a different DCN. In some implementations, the new connection string of the updated mapping is associated with a different I / O channel of the same DCN. In some implementations, the GDS sends one or more alias updates in response to a change to a compilation of a global list of mappings between aliases and connection strings. In some implementations, the method further includes causing the cross-platform client to browse the updated I / O channel based on the new connection string of the updated mapping. In some implementations, the mismatch includes a duplicate alias detected based at least in part on the locally updated list of mappings. In some implementations, the mismatch includes an alias missing from the locally updated list of mappings. In some implementations, the method further includes closing the temporary network connection upon receipt of the updated mapping.

[0008] In some implementations, a method may be implemented that includes identifying, in a first component included in the architecture, a first local list of mappings between aliases and connection strings; querying a second component of the architecture for verification of accuracy corresponding to the first local list based on the identification; identifying a mismatch between the first local list of mappings and a second local list of mappings of at least the second component based on receiving a response to the query; sending a request for an updated list of mappings to the second component or other components of the architecture based on the mismatch; and updating, in the first component, the first local list of mappings in response to receiving the updated list of mappings.

[0009] In some implementations, the first component is a cross-platform client and the second component is a GDS. In some implementations, the first component is a cross-platform client and the second component is a DCN. In some implementations, the transmitted request is to the other component and the other component is a GDS. In some implementations, the first component is a first DCN and the second component is another DCN.

[0010] In some implementations, the method further includes, after updating the first local list of mappings, modifying one or more views of the first component based on the updated list of mappings. In some implementations, the method further includes, before querying a second component of the architecture, determining a current persistent connection with the second component. In some implementations, before querying the second component, the current persistent connection corresponds to a view of the first component to the second component. In some implementations, before querying the second component, the second component identifies a change in one or more features hosted by the second component, and the updated list of mappings reflects the change. In some implementations, based on the updated list of mappings reflecting the change, the view of the first component to the second component is updated or terminated. In some implementations, the method further includes, after updating the first local list of mappings, sending a connection request from the first component to a third component of the architecture based on the updated list, and, in response to the connection request being confirmed by the third component, identifying one or more new browses between the first component and the third component.

[0011] Some implementations include one or more processors of one or more computing devices operable to execute instructions stored in associated memory, the instructions configured to effect performance of any of the aforementioned methods. Some implementations also include one or more non-transitory computer-readable storage media storing computer instructions executable by the one or more processors to perform any of the aforementioned methods.

[0012] It should be appreciated that all combinations of the above concepts and additional concepts described in more detail herein are considered to be part of the subject matter disclosed herein, for example, all combinations of claimed subject matter listed at the end of this disclosure are considered to be part of the subject matter disclosed herein. [Brief description of the drawings]

[0013] [Figure 1] FIG. 1 illustrates generally an environment in which selected aspects of the present disclosure may be implemented, according to various embodiments. [Figure 2A] 1A-1C are diagrams illustrating generally examples of how the techniques described herein may be implemented, according to various embodiments. [Figure 2B] 1A-1C are diagrams illustrating generally examples of how the techniques described herein may be implemented, according to various embodiments. [Figure 2C] 1A-1C are diagrams illustrating generally examples of how the techniques described herein may be implemented, according to various embodiments. [Diagram 3] 1A-1C are diagrams illustrating schematic diagrams of further examples of how the techniques described herein may be implemented. [Figure 4] 1A-1D are schematic diagrams illustrating exemplary methods for implementing selected aspects of the present disclosure. [Diagram 5] FIG. 10 illustrates generally another exemplary method for implementing selected aspects of the present disclosure. [Figure 6] FIG. 1 illustrates generally an exemplary computer architecture in which selected aspects of the present disclosure may be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Implementations described herein relate to having cross-platform clients, such as OPC UA clients, periodically verify aliases with cross-platform servers, such as OPC UA servers, that they have been directed to. More particularly, but not by way of limitation, implementations are described herein for using an existing persistent connection between an OPC UA client and an OPC UA server to perform alias verification. This allows for faster detection of changed or moved aliases and prevents additional complexity and network traffic due to cross-platform clients reconnecting to a GDS to search for updated aliases. As used herein, a "persistent" connection refers to a network communication channel that is open-ended and / or has an unlimited duration or lifespan, e.g., not closed after an initial exchange, but remains open for subsequent exchanges. In contrast, a "transient" connection refers to a transient network communication channel that is established for the purpose of exchanging specific data, which is closed after the exchange of the specific data is completed.

[0015] An alias may be a string of characters (e.g., a word, name, phrase, etc., as opposed to binary characters or hash sequences) that are easily interpretable / meaningful to a human. In some cases, aliases may be defined in batches, for example, as an alias configuration file that includes a list of aliases and corresponding connection strings. The alias configuration file may be provided and / or modified using a configuration tool that allows for the creation and / or modification of aliases and causes corresponding cross-platform clients, such as DCN, to register those aliases with the GDS. As mentioned above, over time, changes may occur in the process automation equipment that may result in one or more alias configuration files for one or more components of the OPC UA becoming stale (outdated, misleading, and / or inaccurate, etc.). For example, hardware may be removed, hardware may be replaced, and / or additional aliases may be registered separately, causing alias configuration files created prior to these events to become stale.

[0016] The GDS may be operated to create new aliases, modify existing aliases, and / or correct outdated aliases by providing an Alias ​​Name Service (ANS) that facilitates the mapping of aliases (e.g., strings of characters presented in a readily human-readable syntax) to connection strings and node IDs (e.g., strings of characters presented in a readily computer-readable syntax). Accordingly, the GDS may contain aliases that are readily interpretable to both human users of OPC UA and non-human components of OPC UA (such as DCNs, clients, sensors, etc., to the extent that these components are distinct in a given implementation). Thus, the GDS may resemble a "phone book" for OPC UA components and users in some implementations.

[0017] 1, an exemplary environment 100 in which various aspects of the present disclosure may be implemented is illustrated diagrammatically. Starting at the top left, DCN 102A, hosting an OPC UA client 105, establishes a temporary network connection with GDS 104. DCN 102A then queries GDS 104 (e.g., "Alias ​​1?"). The query "Alias ​​1?" may indicate a request by DCN 102A for data associated with "Alias ​​1," such as a mapping between "Alias ​​1" and a corresponding connection string. Based on that request, GDS 104 sends "Connection String 1" to DCN 102A.

[0018] The transmission of "Connection String 1" from GDS 104 to DCN 102A may be based on a determination that "Alias ​​1" is associated with "Connection String 1." "Connection String 1" (and thus "Alias ​​1") may be associated with one or more components, such as DCN 102B and / or its components (e.g., sensors, I / O channels, function blocks, etc.). Once DCN 102A obtains "Connection String 1" from GDS 104, DCN 102A may close the temporary network connection with GDS 104, as indicated by an "X."

[0019] FIG. 1 illustrates DCN 102A browsing DCN 102B after DCN 102A receives “Connection String 1” and closes the temporary connection with GDS 104. This browsing may include, for example, having OPC UA client 105 browse one or more components associated with “Connection String 1.” For example, OPC UA client 105 may browse I / O channels or function blocks associated with OPC UA server 106A hosted by DCN 102B based on receiving “Connection String 1.” DCN 102A’s browsing to DCN 102B may result in data being exchanged between DCN 102B and DCN 102A. The exchanged data may include, for example, sensor data associated with the I / O channel corresponding to OPC UA server 106A.

[0020] As shown in FIG. 1, after DCN 102A receives data from DCN 102B, DCN 102A may perform an "alias check" on DCN 102B. However, implementations disclosed herein are not limited to the time constraints shown in the accompanying figures. Thus, in some implementations, DCN 102A may perform an "alias check" prior to, contemporaneously with, and / or after receiving data from DCN 102B. In some implementations, the alias check correlates to potential equipment changes.

[0021] In response to DCN 102A performing an "alias check" with DCN 102B (which may include DCN 102A prompting DCN 102B for aliases and / or connection strings associated with DCN 102B), DCN 102B may send at least to DCN 102A a locally updated list of mappings between aliases and / or connection strings ("alias1:CS1, alias2:CS2, ..."). If there are no mismatches detected between one or more aliases that DCN 102A knows about and the aliases conveyed in the locally updated list of mappings received from DCN 102B, no further action may need to be taken.

[0022] However, at some point, as shown in FIG. 1, DCN 102C (or a component thereof) may "take over alias 1" temporarily or for a sustained period of time. For example, if a temperature sensor (e.g., thermometer, thermocouple, thermostat, etc.) associated with "alias 1" is moved from DCN 102B to DCN 102C, DCN 102C may now become associated with (e.g., "take over") "alias 1". In response, DCN 102C may send an indication to GDS 104 that DCN 102C has taken over "alias 1". GDS 104 may then store this updated information. In some implementations, due to latency, network constraints, etc., GDS 104 may not immediately and / or automatically (i.e., without prompting from a user and / or components) transmit said updated information to other DCNs (102A, 102B, ..., etc.). In some implementations, updated information may only be sent from the GDS 104 to a corresponding DCN after the corresponding DCN has inquired from the GDS 104 for said updated information.

[0023] Sometime after DCN 102C has taken over ALIAS1, DCN 102A may perform another alias check with DCN 102B. By performing an alias check with DCN 102B after DCN 102C has taken over "Alias ​​1", DCN 102A receives a transmission from DCN 102B indicating that DCN 102B is now associated with "Alias ​​2: CS2, Alias ​​3: CS3" as opposed to also being associated with "Alias ​​1" and "Connection String 1".

[0024] DCN 102A may establish at least a temporary network connection with GDS 104 in response to receiving a transmission from DCN 102B indicating that DCN 102B is simply associated with "Alias ​​2: CS2, Alias ​​3: CS3". DCN 102A may then send a request / command "Alias ​​1?" to GDS 104 for an updated mapping between "Alias ​​1" and the new connection string. GDS 104 may identify DCN 102C (or one or more components thereof) associated with "Alias ​​1" and send the connection string associated with the identified DCN 102C to DCN 102A.

[0025] In some implementations, it may not be possible for the GDS to identify the appropriate DCN. For example, if a component is identified as having failed or been removed, the GDS 104 may not send the identity of the DCN (with which the alias was previously associated) to the requesting component. The GDS 104 may instead send a notification that the component has failed or been removed. However, as shown in FIG. 1 and previously described, "Alias ​​1" is identified by the GDS 104 as being taken over or having been taken over by DCN 102C. Thus, the GDS 104 may respond to a request from DCN 102A targeted for "Alias ​​1" by identifying DCN 102C by the GDS 104 sending "Connection String 2".

[0026] As shown in FIG. 1, DCN 102A may receive a transmission, e.g., “Connection String 2”, in response to DCN 102A's request to GDS 104. “Connection String 2” may include information indicating that DCN 102C (or one or more components thereof) is associated with “Alias ​​1”. DCN 102A may close the connection with GDS 104 after receiving the transmission, “Connection String 2”, from GDS 104. DCN 102A may browse DCN 102C after closing the connection with GDS 104 based on the information indicating that DCN 102C is associated with “Alias ​​1”. Data may be exchanged from DCN 102A and DCN 102C after DCN 102A browses DCN 102C.

[0027] 1 illustrates data transfer using unidirectional arrows, implementations are not necessarily limited to one-way communication between the components illustrated. For example, implementations described herein with respect to FIG. 1 note that DCN 102A receives information associated with "Alias ​​1," but DCN 102A may also transmit information to various components of the architecture.

[0028] 2A-2C, exemplary environments 200A-200C are illustrated generally and include various aspects of the disclosure that may be present in some implementations. In FIG. 2A, DCN 202A may include OPC UA server 204A, which itself may include I / O channel 250A associated with alias "thermostat" and viewed by OPC UA client 270 "fan controller" and I / O channel 260A associated with alias "actuator 1". In some implementations, OPC UA client 270 "fan controller" may also be caused to view I / O channel 260A "actuator 1". As a result of OPC UA client 270 "fan controller" viewing I / O channel 250A "thermostat", data indicative of I / O channel 250A "thermostat" may be sent to OPC UA client 270 "fan controller". OPC UA client 270 “Fan Controller” may use the data received from I / O 250A “Thermostat” to control one or more aspects of a process in a facility.

[0029] 2B, a physical sensor (e.g., a thermostat) associated with I / O channel 250A “Thermostat” has been removed, moved, or replaced. In some implementations, removing the physical sensor associated with I / O channel 250A may result in a loss of data. In some implementations, moving the physical sensor associated with I / O channel 250A “Thermostat” to a different location (e.g., to a different DCN) may result in stale and / or inaccurate data. In some implementations, replacing the sensor (e.g., replacing the thermostat with a photosensor) may also result in stale and / or inaccurate data.

[0030] As shown in FIG. 2B, an OPC UA client 270 “Fan Controller”, unaware of the aforementioned sensor removal, movement or replacement, would still be forced to view I / O 250A “Thermostat” of DCN 202A even though no data is being generated or perhaps stale data is being generated. For example, if a different physical sensor, such as a photosensor, were to become associated with I / O channel 250A “Thermostat” of DCN 202A and this photosensor generated data associated with I / O channel 250A “Thermostat”, then the OPC UA client 270 “Fan Controller” could continue to perform its role in the process automation facility based on erroneous data (i.e., based on the photosensor data that it believes is associated with the physical thermostat sensor).

[0031] 2C, the OPC UA client 270 may validate the alias with DCN 202A. In response to validating the alias with DCN 202A, the OPC UA client 270 may determine that the alias “thermostat” is no longer associated with DCN 202A (as indicated by the prohibition symbol). In some implementations, the disassociation may result from a system integrator exclusively assigning the alias to a different component of the architecture. In some implementations, the disassociation may result from multiple instances of the same alias existing and one or more components of the architecture deciding to prioritize an instance of the duplicate alias over another. Regardless, based on determining that the alias “thermostat” is no longer associated with DCN 202A, the OPC UA client 270 may discontinue connection with DCN 202A and / or connect with GDS 104. According to FIG. 2C, an OPC UA client 270 “Fan Controller” establishes at least a temporary connection with GDS 104, which includes ANS 290 to facilitate mapping of aliases to components of the architecture, including mapping the alias “Thermostat” to one or more connection strings.

[0032] 2C also shows DCN 202B, which hosts OPC UA server 204B and includes I / O channel 250B and I / O channel 260B. I / O channel 250B is now associated with the alias "thermostat" and I / O channel 260B is associated with the alias "actuator 2." As described herein, aliasing may be performed by a user / system integrator or may be performed automatically by one or more components, including ANS 290. For example, ANS 290 may detect updates regarding aliases, connection strings, and corresponding components, either alone or based on data received from other components of the architecture.

[0033] After I / O channel 250B is associated with the alias "thermostat", DCN 202B may transmit data to GDS 104 indicating that said alias "thermostat" is associated with I / O 250B. GDS 104 may store data indicative of the aliases associated with components of the architecture. However, as previously described, resource and network constraints may limit the ability of GDS 104 to automatically and / or immediately transmit stored data indicative of the aliases to the relevant components in the network with GDS 104. Thus, GDS 104 may, in some implementations, store the display aliases for a significant period of time (such as one second, one minute, one hour, one day, one week, etc., as non-limiting example lengths) before automatically transmitting the stored data to the relevant components, i.e., if GDS 104 is configured to automatically (without request) transmit the stored data. Thus, the OPC UA client 270 “Fan Controller” may query the GDS 104 before the GDS 104 sends stored data indicating the association of the I / O channel 250B with the alias “Thermostat.”

[0034] In response to the query from OPC UA client 270 “Fan Controller”, GDS 104 may send data to OPC UA client 270 “Fan Controller” indicating the alias “Thermostat” of I / O channel 250B. Based on the data indicating the alias “Thermostat” of I / O channel 250B, OPC UA client 270 “Fan Controller” may browse I / O channel 250B “Thermostat” of DCN 202B. OPC UA client 270 “Fan Controller” may drop its connection with GDS 104 after receiving the data indicating the alias “Thermostat” of I / O channel 250B.

[0035] For example, as described herein, an OPC UA server may maintain an up-to-date list of aliases that it currently hosts and may therefore be able to provide an OPC UA client with a list of those current aliases upon alias update. Thus, as shown in FIGS. 1 and 2A-2C, an OPC UA client 270 may periodically request that an OPC UA server 204 that hosts an I / O channel associated with an alias that the OPC UA client wishes to be browsed provide an "alias update." The OPC UA client 270 may then check the list of aliases provided upon alias update against its local list of aliases. If there is a mismatch, the OPC UA client may establish a connection to the GDS to identify the latest I / O channel that corresponds to one or more aliases browsed by the OPC UA client.

[0036] In some implementations, the OPC UA server may proactively publish alias updates to one or more components of the architecture, with or without a request by the OPC UA client. The OPC UA server may do this periodically and / or in response to some change to one or more aliases. Changes may be the result of various events, such as the addition, replacement, and / or removal of one or more aliases by the GDS or by an engineer.

[0037] It may not always be necessary for the DCN to re-establish a temporary connection with the GDS 104 to retrieve the updated alias. For example, in some implementations, a first DCN configured with selected aspects of the present disclosure may leverage a second DCN's temporary connection with the GDS 104 to facilitate alias updates, without the first DCN having to establish its own temporary connection with the GDS 104. Figure 3 illustrates OPC UA 300 with DCN 330B and OPC UA client 350 in a persistent connection with each other, and GDS 104 and DCN 330A in temporary communication with each other.

[0038] Although DCN 330A may be able to interact directly with GDS 104 for alias validation and / or alias mapping updates, neither DCN 330B nor OPC UA client 350 can do so immediately since they currently have a direct connection to GDS 104. However, as previously explained, DCN 330B and OPC UA client 350 can exchange information with each other regarding alias validation and / or alias mapping updates.

[0039] In some implementations, components of OPC UA 300 may be able to communicate requests for alias validation and / or updated alias mappings indirectly to GDS 104, for example, by relaying information through one or more other components. For example, OPC UA client 350 may communicate requests for alias validation and / or updated alias mappings from DCN 330B to DCN 330A and then to GDS 104, over a connection (shown with dashed lines) that may be temporarily established or that is already established. GDS 104 may then communicate the response back to OPC UA client 350 through the same components.

[0040] Alternatively, at any point during the propagation of the query and / or request, connections may be made between components to skip further components in the propagation chain. For example, OPC UA client 350 may propagate a query to DCN 330B, which may establish at least a temporary connection with GDS 104, without further propagating the query through DCN 330A. A similar connection may also be made after GDS 104 receives a query, such that GDS 104 may respond directly to OPC UA client 350, for example by establishing a temporary connection, even if the query has propagated through multiple components of the OPC UA 300 system.

[0041] In some cases, the local alias database (e.g., 332, 352) may be up to date and contain updated mappings enough to respond to a query without interacting with the GDS 104. For example, in FIG. 3, DCN 330A may have recently received updated alias mappings through its existing connection to GDS 104. Thus, if a query is propagated from OPC UA 350 to DCN 330B and then to DCN 330A (which has updated the alias mappings and therefore may know the response), DCN 330A can respond to the query without necessarily propagating the query further to GDS 104. In some implementations, DCN 330A's response may occur through the same propagation channel or by establishing a direct communication channel.

[0042] 4 is a flow chart illustrating an example method 400 for practicing selected aspects of the disclosure, according to implementations disclosed herein. For convenience, the operations of the flow chart are described with respect to a system performing the operations. The system may include various components of OPC UA 300 and / or various computer systems, such as one or more components illustrated in FIGS. 1-2. Additionally, while the operations of method 400 are illustrated in a particular order, this is not intended to be limiting. One or more operations may be rearranged, omitted, and / or added.

[0043] At block 402, a first component of the architecture identifies a first local list of mappings between aliases and connection strings. OPC UA 300 represents an example architecture in which the sequence of FIG. 4 may be implemented. The first component may be GDS 104, DCN 330, and / or OPC UA client 350. The first local list may be stored in a local database of the first component. For example, the first local list may be stored in ANS 290, local alias database 332, 352, etc.

[0044] At block 404, a second component of the architecture is queried for verification of accuracy corresponding to the first local list of mappings. The second component may be queried based on and / or in response to the identification of the first local list at block 402. In some implementations, the query for verification of accuracy includes a request from the first component to the second component for identification of one or more similarities and / or differences between the first local list of mappings and the second local list of mappings. The second local list of mappings may be stored in the second component and / or another component in communication with the second component. In some implementations, the first component is a cross-platform client (e.g., 350) and the second component is a DCN (e.g., 330A / B). In some implementations, the first component is a first DCN (e.g., 330A) and the second component is another DCN (e.g., 330B). In some implementations, the first component is a cross-platform client (eg, 350) and the second component is a GDS (eg, 104).

[0045] In some implementations, a current persistent connection between the first component and the second component is determined before the second component is queried. The current persistent connection may correspond to a view of the first component to the second component. For example, the first component may view one or more I / O channels or function blocks hosted at the second component.

[0046] At block 406, a mismatch is identified between the first local list of mappings and the second local list of mappings of at least the second component. In some implementations, the mismatch at block 406 may be identified by the first component based on receiving a response from the second component to the query at block 404. In some implementations, the second component may identify a change to one or more features hosted at the second component. The response of the second component to the query from the first component may reflect the change to the one or more features. The identified mismatch may correspond to the change.

[0047] At block 408, the first component sends a request for an updated list of mappings. The request may be sent based on the inconsistency identified at block 406, but may alternatively be sent based on various other criteria, which may include, for example, the time elapsed since the previous request for an updated list, the estimated accuracy of a given local list corresponding to a given local component of the architecture, and / or feedback from a user / system integrator.

[0048] In some implementations, the query of block 404 and the request of block 408 may both be sent to the same (e.g., second) component. For example, the first component may be an OPC UA client (e.g., 350) and the second component may be a DCN (e.g., 330A / B). After querying DCN 330A / B to verify accuracy in step 404 and identifying a discrepancy during block 406, OPC UA client 350 may request an updated list of mappings from DCN 330A / B. This implementation may be particularly appropriate, for example, in situations where DCN 330A / B may be able to verify accuracy (e.g., DCN 330A / B may recognize that components previously hosted on DCN 330A / B have been removed) and may also be able to verify comprehensive updated mappings (e.g., DCN 330A / B may recognize exactly where components previously hosted on DCN 330A / B have been moved).

[0049] In some implementations, the sent request is to a third (e.g., not the second) component. In some of these implementations, the first component may be an OPC UA client (e.g., 350), the second component may be a DCN (e.g., 330A / B), and the third component may be a GDS (e.g., 104). After the OPC UA client 350 queries the DCN 330A / B in step 404 and identifies the inconsistency in block 406, the OPC UA client 350 may request an updated list of mappings from the GDS 104. This implementation may be particularly suitable in situations where, for example, DCN330A / B may be able to verify accuracy (e.g., DCN330A / B may recognize that a component previously hosted on DCN330A / B has been removed), but may not be able to immediately provide a comprehensive updated mapping (e.g., DCN330A / B may not recognize accurately where a component previously hosted on DCN330A / B has been moved).

[0050] In block 410, the first component receives the updated list of mappings and updates the first local list of mappings based on the updated list. The updated list of mappings may be received in response to the query of block 408.

[0051] In some implementations, prior to receiving the updated list of mappings at block 410, the first component may be made to browse one or more functions of the second component. After the updated list is received at block 410, based thereon, the first component's browsing to one or more functions of the second component may be changed. In some implementations, after receiving the updated list of mappings, based thereon, the first component may send a connection request to a third component of the architecture. In response to the sent connection request being confirmed by the third component of the architecture, the first component may identify one or more new browsing between the first component and the third component.

[0052] 5 is a flow chart illustrating an example method 500 for practicing selected aspects of the disclosure, according to implementations disclosed herein. For convenience, the operations of the flow chart are described with respect to a system that performs the operations. The system may include various components of various computer systems, such as one or more components described herein. Additionally, while the operations of method 500 are shown in a particular order, this is not intended to be limiting. One or more operations may be reordered, omitted, and / or added.

[0053] In block 502, the system queries the GDS (e.g., 104) by, for example, a cross-platform client (e.g., 270, 350) hosted by the DCN (e.g., 102, 202, 330A, 330B) for a mapping between aliases and connection strings of I / O channels or function blocks hosted by the DCN. In various implementations, the query may be performed by the DCN (or components included therein) and / or an OPC UA client if and / or to the extent that the DCN and / or OPC UA are considered different in a given implementation. As shown in FIG. 3, in some implementations, the query may be conveyed from the query component through one or more non-query components. The GDS may include an ANS (e.g., 290), which specializes in mapping OPC UA components, such as I / O channels and / or function blocks, to one or more aliases. In some implementations, an alias may be a string of characters that is easily interpreted by a human, such as a word or phrase.

[0054] At block 504, the system allows the cross-platform client to browse the I / O channels or function blocks. The browsing may include, for example, establishing a persistent network connection between the cross-platform client and the DCN using a connection string. In some implementations, the browsing may be temporary or persistent (e.g., similar to and / or using a TCP connection). In various implementations, the connection string may be static or dynamic.

[0055] In block 506, the system retrieves a locally updated list of mappings between aliases and connection strings from a local alias database of the DCN via a persistent network connection, e.g., via a cross-platform client. As described herein, in some implementations, OPC UA components, including the DCN, may include one or more local databases, including one or more local alias databases (e.g., 332, 352).

[0056] At block 508, the system identifies a mismatch between a locally updated list of mappings, e.g., by the cross-platform client, and a mapping between aliases and connection strings of I / O channels hosted by the DCN viewed by the cross-platform client. In various implementations, the mismatch may include a duplicate alias detected based at least in part on the locally updated list of mappings. Alternatively, the mismatch may include an alias being missing from the locally updated list of mappings.

[0057] Based on the mismatch, in block 510, the system establishes a temporary network connection between the cross-platform client and the GDS. In various implementations, the temporary network connection between the cross-platform client and the GDS may be direct or indirect. In some implementations where the temporary network connection between the cross-platform client and the GDS is indirect, the network connection may also include one or more intermediate components included in OPC UA. In various implementations, a network connection that includes at least one or more intermediate components of OPC UA may involve data packets being conveyed through and / or by the intermediate component and / or being stored by the intermediate component.

[0058] At block 512, the system retrieves an updated mapping between the alias and the new connection string from the GDS over the temporary network connection. In various implementations, the new connection string of the updated mapping may be associated with a different DCN. In some implementations, the new connection string of the updated mapping may be associated with a different I / O channel of the same DCN. In some implementations, the GDS sends one or more alias updates in response to one or more changes in the compilation of the mapping between the alias and the connection string.

[0059] In some implementations, method 500 may further include causing the cross-platform client to view the updated I / O channel based on the new connection string of the updated mapping. In some implementations, method 500 may further include closing the temporary network connection upon receiving the updated mapping.

[0060] 6 is a block diagram of an exemplary computing device 610 that may optionally be utilized to implement one or more aspects of the techniques described herein. The computing device 610 generally includes at least one processor 614 that communicates with a number of peripheral devices via a bus subsystem 612. These peripheral devices may include a storage subsystem 624, including, for example, a memory subsystem 625 and a file storage subsystem 626, a user interface output device 620, a user interface input device 622, and a network interface subsystem 616. The input and output devices enable user interaction with the computing device 610. The network interface subsystem 616 provides an interface to external networks and is coupled to corresponding interface devices of other computing devices.

[0061] The user interface input devices 622 may include a keyboard, a pointing device such as a mouse, a trackball, a touchpad, or a graphics tablet, a scanner, a touch screen integrated into a display, a voice recognition system, an audio input device such as a microphone, and / or other types of input devices. In general, use of the term "input device" is intended to include all conceivable types of devices and methods for inputting information into the computing device 610 or into a communications network.

[0062] The user interface output devices 620 may include a display subsystem, a printer, a fax machine, or a non-visual display such as an audio output device. The display subsystem may include a flat panel device such as a cathode ray tube (CRT), a liquid crystal display (LCD), a projection device, or some other mechanism for producing a visible image. The display subsystem may also provide a non-visual display, such as via an audio output device. In general, use of the term "output device" is intended to include all conceivable types of devices and methods for outputting information from the computing device 610 to a user or to another machine or computing device.

[0063] Storage subsystem 624 stores programming and data configurations that provide the functionality of some or all of the modules described herein. For example, storage subsystem 624 may include logic for performing selected aspects of the methods illustrated in Figures 4 and 5, as well as for implementing the various components illustrated in Figures 1-3.

[0064] These software modules are typically executed by the processor 614 alone or in combination with other processors. The memory 625 used by the storage subsystem 624 may include several memories including a main random access memory (RAM) 630 for storing instructions and data during program execution, and a read-only memory (ROM) 632 in which fixed instructions are stored. A file storage subsystem 626 may provide persistent storage for program and data files and may include a hard disk drive, a floppy disk drive with associated removable media, a CD-ROM drive, an optical drive, or a removable media cartridge. Modules implementing the functionality of some implementations may be stored by the file storage subsystem 626, in the storage subsystem 624, or in other machines accessible by the processor 614.

[0065] The bus subsystem 612 provides a mechanism for allowing the various components and subsystems of the computing device 610 to communicate with each other as intended. Although the bus subsystem 612 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may use multiple buses.

[0066] The computing device 610 may be of different types, including a workstation, a server, a computing cluster, a blade server, a server farm, or any other data processing system or computing device. Due to the ever-changing nature of computers and networks, the description of the computing device 610 shown in Figure 6 is intended as a specific example only for purposes of illustrating some implementations. Many other configurations of the computing device 610 are possible, having more or fewer components than the computing device shown in Figure 6.

[0067] Although several implementations have been described and illustrated herein, various other means and / or structures for performing the functions and / or obtaining the results and / or one or more of the advantages described herein may be utilized, and each such variation and / or modification is considered to be within the scope of the implementations described herein. More generally, all parameters, dimensions, materials, and configurations described herein are intended to be exemplary, and the actual parameters, dimensions, materials, and / or configurations will depend on the particular application or applications for which the teachings are used. Those skilled in the art will recognize or be able to ascertain using no more than routine experimentation many equivalents to the specific implementations described herein. Thus, it should be understood that the above implementations are presented by way of example only, and that within the scope of the appended claims and equivalents thereof, implementations may be performed in ways other than as specifically described and claimed. Implementations of the present disclosure are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, articles, materials, kits, and / or methods is included within the scope of the present disclosure, provided such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent. Furthermore, one or more portions of the disclosure herein may illustratively reference components and / or methods related to an open platform communication integration architecture. The present disclosure is in no way limited to OPC UA, and may be implemented across one or more cross-platform architectures and / or cross-platform components. References herein to OPC UA are illustrative of one or more applications of the disclosure herein, and should not be construed as limiting the disclosure in any manner. [Explanation of symbols]

[0068] 100 Example Environment 102 Distributed Control Node (DCN) 104 Global Discovery Server (GDS) 105 Open Platform Communications Unified Architecture (OPC UA) Client 106 OPC UA Server 202 DCN 204 OPC UA Server 250 Input / Output (I / O) channels 260 I / O channels 270 OPC UA Clients 290 Alias ​​Name Service (ANS) 300 OPC UA 330 DCN 332 local alias database 350 OPC UA clients 352 local alias database 610 Computing Devices 612 Bus Subsystem 614 processor 616 Network Interface Subsystem 620 User Interface Output Device 622 User Interface Input Devices 624 Storage Subsystem 625 Memory Subsystem 626 File Storage Subsystem 630 Random Access Memory (RAM) 632 Read-Only Memory (ROM)

Claims

1. Querying a Global Discovery Server (GDS) for a mapping between aliases and connection strings of input / output (I / O) channels hosted by a Distributed Control Node (DCN); permitting a cross-platform client to view the I / O channel, the permitting including establishing a persistent network connection between the cross-platform client and the DCN using the connection string; obtaining a locally updated list of mappings between aliases and connection strings from a local alias database of the DCN over the persistent network connection; identifying a mismatch between the locally updated list of mappings and the mappings between the aliases and the connection strings of the I / O channels hosted by the DCN; establishing a temporary network connection between the cross-platform client and the GDS based on the mismatch; retrieving an updated mapping between the alias and a new connection string from the GDS via the temporary network connection; A method comprising:

2. The method of claim 1 , wherein the new connection string of the updated mapping is associated with a different DCN.

3. The method of claim 1 , wherein the new connection strings of the updated mapping are associated with different I / O channels of a same DCN.

4. The method of claim 1 , wherein the GDS sends one or more alias updates in response to a change to a compilation of a global list of mappings between aliases and connection strings.

5. causing the cross-platform client to view an updated I / O channel based on the new connection string of the updated mapping. The method of claim 1, further comprising:

6. The method of claim 1 , wherein the inconsistency comprises a duplicate alias detected based at least in part on the locally updated list of mappings.

7. The method of claim 1 , wherein the inconsistency includes the alias being missing from the locally updated list of mappings.

8. The method of claim 1 , further comprising the step of closing the temporary network connection upon receipt of the updated mapping.

9. identifying, in a first component of the architecture, a first local list of mappings between aliases and connection strings; based on said identification, querying a second component of said architecture for verification of accuracy corresponding to said first local list; identifying a mismatch between the first local list of mappings and a second local list of mappings of at least the second component based on receiving a response to the query; sending a request for an updated list of mappings to the second component or other components of the architecture based on the discrepancy; updating the first local list of mappings in response to receiving the updated list of mappings, at the first component; A method comprising:

10. 10. The method of claim 9, wherein the first component is a cross-platform client and the second component is a global discovery server (GDS).

11. 10. The method of claim 9, wherein the first component is a cross-platform client and the second component is a distributed control node (DCN).

12. The method of claim 11 , wherein the transmitted request is to the other component, the other component being a Global Discovery Server (GDS).

13. 10. The method of claim 9, wherein the first component is a first distributed control node (DCN) and the second component is another DCN.

14. After updating said first local list of mappings, modifying one or more views of the first component based on the updated list of mappings.

10. The method of claim 9, further comprising:

15. prior to interrogating the second component of the architecture; determining a current persistent connection with the second component; 10. The method of claim 9, further comprising:

16. 16. The method of claim 15, wherein the current persistent connection corresponds to a browse of the first component to the second component prior to querying the second component.

17. 17. The method of claim 16, wherein prior to querying the second component, the second component identifies changes to one or more features hosted by the second component, and the updated list of mappings reflects the changes.

18. 20. The method of claim 17, wherein the view of the first component to the second component is updated or terminated based on the updated list of mappings that reflect the changes.

19. After updating said first local list of mappings, sending a connection request from the first component to a third component of the architecture based on the updated list; in response to the connection request being acknowledged by the third component, identifying one or more new browses between the first component and the third component; 10. The method of claim 9, further comprising:

20. 1. A system comprising: one or more computers; and one or more storage devices storing instructions operable, when executed by the one or more computers, to cause the one or more computers to perform operations, the operations comprising: Querying a Global Discovery Server (GDS) for mappings between aliases and connection strings of input / output (I / O) channels hosted by a Distributed Control Node (DCN); permitting a cross-platform client to view the I / O channel, the permitting including establishing a persistent network connection between the cross-platform client and the DCN using the connection string; retrieving a locally updated list of mappings between aliases and connection strings from a local alias database of the DCN over the persistent network connection; identifying a mismatch between the locally updated list of mappings and the mappings between the aliases and the connection strings of the I / O channels hosted by the DCN; establishing a temporary network connection between the cross-platform client and the GDS based on the inconsistency; retrieving an updated mapping between the alias and a new connection string from the GDS via the temporary network connection; Including, the system.

Images