Method for verifying ethernet configuration of an automation system

Abstract

The invention relates to a method for verifying an Ethernet configuration of an automation system comprising a plurality of industrial devices, the method comprising obtaining a device identifier of each industrial device, an indication of a device port, and an indication of a device port connection. Device Ethernet parameters are obtained, and a system object model of the Ethernet configuration of the automation system is instantiated based on the device identifiers, the device ports, the device port connections, and the Ethernet parameters. The system object model allows to apply predefined rules to generate a graph model representing the Ethernet configuration. As known from graph theory, a loop detection can be applied to the generated graph model by a depth-first search. A verification result can be indicated based on a result of the loop detection. The invention also relates to a generic Ethernet object model, and to a topology manager.

Description

BACKGROUND

[0001] The present invention relates to an industrial automation system interconnecting a plurality of components, e.g. automation devices, and in particular to a method for detecting communication configuration problems within such an industrial automation system. The method can be implemented by an engineering tool used during the initial design phase of the automation system or during subsequent updates or upgrades.

[0002] Ethernet is a layer 2 protocol that can be used between wired connected industrial devices, e.g. in a factory. These industrial devices can involve controllers, e.g. programmable logic controllers (PLCs), drives, human machine interfaces (HMIs), as well as network devices, e.g. routers and switches.

[0003] The Ethernet configuration of the system corresponds to the way the industrial devices are interconnected via their Ethernet ports and depends on the Ethernet parameters of the industrial devices.

[0004] Generally, an operational technology (OT) engineer can be responsible for the design of an industrial system and creates the industrial system by interconnecting various devices. Once connected, the devices constituting the industrial system need to be programmed and configured. Here, a dedicated programming tool can be used, e.g. EcoStruxure Control Expert or EcoStruxure Machine Expert by Schneider Electric can be used. Such a tool is able to detect and identify the connected devices within the industrial system via a discovery process or similar. For the identified devices, a pre-arranged model can be selected from one or more catalogs, including a suggested basic industrial configuration that can be modified using the programming tool.

[0005] In addition to programming and configuring each device to perform its industrial function, the communication between these devices needs to be configured. Accordingly, to ensure proper communication, it is also necessary to ensure that the Ethernet configuration of the industrial system is correct.

[0006] However, the OT engineer can have limited knowledge in information technology (IT). Therefore, once the industrial system is created, the Ethernet configuration can typically be assessed using an IT tool. It is also possible that an Ethernet configuration scheme is provided upfront by an IT engineer and then implemented by the OT engineer. However, the implementation of the Ethernet configuration plan can still need to be verified.

[0007] Moreover, if some Ethernet parameters of the industrial devices are modified, the Ethernet configuration can need to be re-evaluated or verified. This causes an efficiency loss when designing an industrial system involving the Ethernet protocol. SUMMARY

[0008] It is an object of the present invention to alleviate at least some of the above-mentioned drawbacks.

[0009] In a first aspect of the invention, a method for verifying an Ethernet configuration of an automation system comprising a plurality of industrial devices is disclosed. The method comprises obtaining a device identifier of each industrial device, an indication of device ports of the industrial device, and an indication of device port connections between the ports of the industrial device, and obtaining device Ethernet parameters applied to each industrial device. The method further comprises instantiating a system object model of the Ethernet configuration of the automation system based on the device identifiers, the device ports, the device port connections, and the device Ethernet parameters, and generating a graph model representing the Ethernet configuration from the system object model by applying a set of predefined rules. Cycle detection is applied to the generated graph model by a depth-first search, and a verification result is indicated based on a result of the cycle detection.

[0010] In another aspect, the invention relates to a generic Ethernet object model comprising at least one of the following classes: an Ethernet class, a switching capability class, a routing capability class, a port class, an IP range class, an endpoint class, an interface class, and / or a broadcast domain class.

[0011] In another aspect, the invention relates to a topology manager configured to generate a graph model of the automation system, wherein each industrial device is represented by an instance of the generic Ethernet object model. The topology manager is further configured to apply cycle detection by a depth-first search according to graph theory.

[0012] The disclosed method facilitates the automated verification of various Ethernet functionalities required for the automation system, such as loop detection, communication, data flow evaluation, logical connections, and broadcast domains. Another purpose of the verification can involve a predictive analysis of the communication between new devices added to the automation system.

[0013] The disclosed method can be implemented on a computer system. Moreover, the invention can relate to a computer program which is executable by a processor and comprises instructions for carrying out the steps of the disclosed method when executed by the processor. Furthermore, the invention can relate to a non-transitory computer readable medium having stored thereon a computer program comprising instructions for carrying out the steps of the disclosed method when executed by a processor.

[0014] Other objects, aspects, effects and details of the present application are described in the detailed description of multiple exemplary embodiments below with reference to the drawings. BRIEF DESCRIPTION OF DRAWINGS

[0015] Embodiments of the present disclosure will be described below by way of example only, with reference to the drawings, in which:

[0016] Figure 1 An example of an industrial system with an Ethernet communication network is shown;

[0017] Figure 2 A configuration model of the industrial system of Figure 1 is shown;

[0018] Figure 3 is an example of a generic Ethernet object model;

[0019] Figure 4 is an example of the resulting object model for a PC;

[0020] Figure 5 is an example of the resulting object model for a four-port unmanaged switch;

[0021] Figure 6 is an example of a graph generated from the configuration model of Figure 2 ;

[0022] Figure 7 Loop detection within the graph of Figure 4 is shown;

[0023] Figure 8 is a flowchart of a method according to an embodiment of the present application;

[0024] Figure 9 is a graph showing the operation of a method according to an embodiment of the present application;

[0025] Figure 10 is another example of a graph generated from the configuration model of Figure 2 ;

[0026] Figure 11 is yet another example of a graph generated from the configuration model of Figure 2 . DETAILED DESCRIPTION

[0027] With reference to Figure 1 , an example of an industrial system 100 is shown. A computer PC 1 is connected via a router 2 to a Modicon M580 processing unit 4 installed in a slot of an Ethernet I / O backplane 3. Installed in another slot of the Ethernet I / O backplane 3 is a NOC 311 Ethernet module 5 to which two Altivar speed drives 6, 7 are connected. The speed drives 6, 7 are also connected to each other.

[0028] refer to Figure 2 , showed Figure 1 The basic model of the industrial system 100. Various components can be represented (i.e. modeled) as switches. PC 1 is represented as PC 201, router 2 is modeled as switch 202, Ethernet backplane 3 is modeled as switch 203, processing unit 4 is modeled as switch 204, Ethernet module is modeled as switch 205, and speed drivers 6 and 7 are modeled as switches 206 and 207.

[0029] Figure 2 The model can be presented in the OT configuration tool (i.e., the engineering tool), which can actually be... Figure 1 It will be executed on PC1. Models of various components can be selected from catalogs or libraries available in the engineering tools. These models will include representations of the communication circuitry for each component. These representations can be used to create diagrams.

[0030] Figure 3 An example of a generic Ethernet object model is shown. This object model includes various classes, each defining specific Ethernet characteristics for an industrial piece of equipment. When the user of the engineering tool designs a system and declares various devices as part of the system, an instance of the equipment class is created for each device, and instances of the generic model Ethernet object are linked to instances of that equipment class. Different classes of the object model are instantiated depending on the type of device. For each type of device, a number of predefined classes are associated, which are obtained from libraries within the engineering tool. When the associated classes are instantiated and parameter settings are defined, these class instances collectively describe the overall Ethernet behavior of an industrial piece of equipment in terms of aspects such as communication, security, and configuration capabilities.

[0031] The general Ethernet object model can include a central Ethernet class 30, a switch capability class 31, a routing capability class 32, a port class 33, and an IP range class 34. The general Ethernet object model may also include an endpoint class 36, an interface class 35, and / or a broadcast domain class 37. Parameters for the switch capability class 31 can be defined by obtaining settings directly from a library available in the engineering tools. Similarly, parameters for the routing capability class 32 can be defined by obtaining settings from another available library. Port class 33 and IP range class 34 can obtain their respective parameter settings from other classes. In the graphical representation of the object model, arrows indicate that one class is aware of the existence of another class.

[0032] Ethernet 30 instances define further classes that constitute the device for each specific type of device, such as port classes, interface classes, and switching capability classes.

[0033] One or more instances of the port class 33 represent the physical ports of the device. Attributes such as name, enable / disable are defined for each port instance.

[0034] An instance of the IP range class 34 represents a range of reserved IP addresses associated with the device that are not partially modeled by instances of the generic Ethernet object model.

[0035] An instance of the endpoint class 36 defines an IP address that will belong to an interface instance and can be associated with a broadcast domain.

[0036] An instance of the interface class 35 represents a network interface of the device. It defines attributes such as name, enable / disable, physical address, set of endpoints and set of associated physical ports.

[0037] An instance of the switching capability class 31 represents the type and number of physical ports that exist. It also holds information about which Ethernet frames can be forwarded from one port to another based on MAC address through the data link layer (i.e. layer 2 of the OSI model).

[0038] An instance of the routing capability class 32 represents the type and number of interfaces. It also holds information about which Ethernet frames can be transmitted from one network to another based on the interfaces using the routes defined in this routing capability. This reflects the network layer, i.e. layer 3 of the OSI model.

[0039] An instance of the broadcast domain class 37 defines a logical division of the network. It determines which nodes in the network can communicate through broadcast.

[0040] As an example of a device and its associated object model, a user can declare a PC with a single Ethernet card as part of its system. As shown in Figure 4 The resulting object model will include one port instance 43, one Ethernet instance 40, one interface instance 45 and one endpoint instance 46, as shown.

[0041] As another example of a device and its associated object model, a user can declare an unmanaged switch with four ports as part of its system. As shown in Figure 5 The resulting object model will include one switching capability instance 51, four port instances 53-1, 53-2, 53-3 and 53-4, and one Ethernet instance 50. Such an unmanaged switch has no interfaces or endpoints.

[0042] Referring to Figure 6 , an example of a diagram generated from the configuration model of Figure 2 is shown. The various components within the network can be identified and the relationships between them can be determined by Figure 3The example shown in the diagram represents each component of a generic Ethernet object model, used to generate such a diagram for any industrial system. Figure 6 The generated graph shown can already be easily visually identified as having loops. By generating the graph based on a set of rules applied to the object model of an industrial system using a generic Ethernet object model, automatic detection of such loops is possible. For loop detection, the required information involves the ports present in the device, the wiring connections between these ports and switching capability instances, which signify the ability to switch a connection from one port to another.

[0043] Topology managers can be part of engineering tools, and can be based on Figure 3 The general Ethernet object model is Figure 1 Instances are created for each component of the industrial network. For example, for PC1, an instance PC401 with only one port is created. For the 2U switch router 2, an instance switch 402 with one switching capability and four ports through which it is switched is created. For the Ethernet I / O backplane 3, an instance switch 403 with one switching capability and four ports is created, one port for the CPU socket and three ports for the module sockets.

[0044] For Modicon M580 processing unit 4, an instance 404 is generated with one (CPU) port (connected to an internal port via a wired connection) and switching capability (for switching the four ports by it, including the internal port). For NOC311 Ethernet module 5, an instance 405 is generated with one port connected to an internal port via a wired connection and switching capability (for switching all four ports by it). For each of Altivar speed drivers 6 and 7, corresponding instances 406 and 407 are generated, each instance having one switching capability and two ports switched by it.

[0045] To allow the topology manager to generate a graph, a vertex is created for each port, and an edge is created for each wired connection. Secondly, for each switching capability, a vertex is created, and each port switched through it is connected to it via an edge. Therefore, using these rules... Figure 6 The image can be directly from Figure 2 It is generated in the configuration model.

[0046] By applying graph theory known in the art, loop detection can be performed using the generated graph. Correspondingly, loops such as... Figure 7 The loop L1 is shown, which can remind design engineers of the existence of such a loop in the current design of industrial systems.

[0047] In graph theory, a cycle (i.e. a loop in a graph) is a non-empty path in which the only repeated vertices are the first and last. A directed cycle in a directed graph is a non-empty directed path in which the only repeated vertices are the first and last.

[0048] The presence of cycles in directed and undirected graphs can be determined by whether a Depth-First Search (DFS) finds an edge pointing to an ancestor of the current vertex (meaning whether it contains a back edge). All back edges skipped by the DFS are part of a cycle. In the case of an undirected graph, an edge to a node's parent should not count as a back edge, but finding any other already visited vertex would indicate a back edge. In the case of an undirected graph, it is possible to find cycles in O(n) time in an n-vertex graph, since at most n-1 edges can be tree edges.

[0049] Reference Figure 8 Fig. 1 shows a flowchart of a method for verifying an Ethernet configuration of an automation system. The method can be executed by an engineering tool during an engineering phase of designing an automation system. The method comprises obtaining 501 identifiers of industrial devices, indications of device ports and indications of device port connections between the ports of the industrial devices. These can be obtained from the tool at which a user of the engineering tool has entered or declared them. Or they can be easily obtained from a catalog or library. The method further comprises obtaining 502 Ethernet parameters for each respective industrial device. These parameters can again be obtained from a library available in the engineering tool or can be provided by the user at the engineering phase.

[0050] The method continues with instantiating 503 a system object model of the Ethernet configuration of the automation system based on the device identifiers, the device ports and the device port connections and the set of Ethernet parameters obtained as described above. By applying a set of predefined rules, a graph model representing the Ethernet configuration of the automation system can be generated 504 from the system object model. The set of predefined rules can differ depending on the verification required. There can be a set of predefined rules for cycle detection or other types of errors. There can be a further set of predefined rules for physical path detection to verify whether communication between certain devices is possible or whether a firewall present in a router, for example, is configured correctly. A further set of predefined rules can be applied to detect logical networks, for example, to verify which ports belong to the same logical network.

[0051] After the graph model has been created, the method continues by applying 505 cycle detection to the generated graph model by means of a depth-first search. Based on the results of the applied cycle detection, a verification result can be indicated. For example, the result can indicate a cycle error, a physical connection is present or not present, or a port is part of a logical network.

[0052] refer to Figure 9 A flowchart illustrating the entire process is shown. The automation system designer 60 can use engineering tools during the design phase. The user 60 selects equipment that will constitute the automation system from a catalog or other software library 62. For the selected equipment 61, data on Ethernet configuration settings and other parameters can also be obtained from the catalog database 62. The selected devices are instantiated 63 using a topology manager 64. The instantiated devices can be further configured by the user 65. The user can further define the wired connections 66 between various devices and equipment.

[0053] With the automated system designed as described above, the user can initiate functions for verifying Ethernet configurations, such as loop detection. After initiating the verification function, the engineering tool will execute the methods described in detail above. In short, the topology manager 64 will obtain all devices from the tool, including all device identifiers and the indicated device ports and device port connections. Using the object model described above for each identified device, a graph model 69 will be created by applying a set of predefined rules associated with the desired verification (loop detection in this example). In this embodiment, a dedicated graph engine 70 is provided as part of the engineering tool that will generate the desired graph model. After the graph model is generated, the graph engine will perform loop detection, which, as is known from general graph theory, can be applied by performing a depth-first search. Therefore, in this example, loop detection 71 is performed by detecting graph loops. Other computations familiar from graph theory can be implemented and applied to verify the Ethernet configuration.

[0054] Based on the results of the loop detection, the topology manager 64 will report whether a loop has been detected. Correspondingly, if an error is detected in the Ethernet configuration, an alert can be issued.

[0055] In addition to loop detection, other Ethernet configuration properties can also be verified. For example, refer to Figure 10 The diagram shown allows verification of whether an OSI Layer 3 communication path is possible between two devices. For loop detection, only ports, line connections, and switching capabilities are considered. To generate a diagram representing a Layer 3 communication path, routing capabilities, interfaces, and endpoints are also considered when generating the diagram.

[0056] In this example, to verify the availability between device PC 801 and Altivar speed driver 806, the topology manager creates vertices for each port and edges for each wired connection. Next, for routing capability 802, vertices are created for each port, and the configured routes connecting ports within the router are represented by directed edges. For each interface and each endpoint associated with such an interface, corresponding vertices are also created. Edges are created between the vertices of each interface and the vertices of each endpoint associated with that interface. Therefore, using these rules, it is possible to directly...Figure 3 a directed graph as shown in Figure 10

[0057] If the router also comprises a firewall comprising certain firewall rules, the directed graph can be adjusted accordingly. For example, if the PC 801 needs to communicate with a Modbus server running on the ATV (e.g. running on port 502).

[0058] As another example, reference is made to the graph shown in Figure 11 which allows to verify which ports belong to a certain broadcast domain, i.e. which ports belong to the same logical network. To generate such a graph, consider the data related to ports, switching capabilities, interfaces, endpoints and broadcast domains. The same rules described in the example above for creating vertices and edges are also used to create the graph. In addition, a vertex is created for each broadcast domain and an edge is created between the broadcast domain vertex and each endpoint having an IP address belonging to that broadcast domain. Thus, using such rules, a graph as shown in Figure 3 can be generated directly from the generic object model of Figure 11 .

[0059] In this example, the PC 901 is configured to belong to the logical network 1 (192.168.1.0 / 24) with IP address 192.168.1.1. The CPU 904 of the P58 belongs to the same logical network 1 with IP address 192.168.1.2. To verify whether the simple switch 2U belongs to the same logical network, the topology manager creates a vertex for each port and an edge for each line connecting the ports. Secondly, a vertex LN1 for the logical network 1 is created and the vertices of the ports having an IP address being part of the logical network 1 are connected to the vertex LN1 for the logical network 1 by edges. Starting from the vertex LN1, it can be evaluated using graph theory which other physical ports belong to the same logical network. Thus, using these rules, a graph as shown in Figure 3 can be generated directly from the generic object model of Figure 11 .

[0060] Similarly, for network security purposes, it can be evaluated whether one device is connected to an external network and, in turn, which other devices are connected to that one device. Thus, mitigation measures such as configuring a firewall can be proposed.

[0061] Although the present application has been described above with reference to particular embodiments, the application is not intended to be limited to the particular forms disclosed herein. Instead, the application is to cover all modifications and alternatives falling within the scope of the appended claims and equivalents thereof. The application is not limited to the embodiments described above, but can also be implemented in other embodiments than the ones disclosed.

[0062] ​Furthermore, while example embodiments have been described above in terms of some exemplary combinations of components and / or functions, it should be understood that other combinations of components and / or functions are also possible and are contemplated within the scope of the disclosure. Additionally, it is contemplated that features described herein individually or as part of an embodiment can be combined with other features described individually or as part of other embodiments.

Claims

1. A computer-implemented method for verifying the Ethernet configuration of an automation system comprising multiple industrial devices, the method comprising: Obtain the device identifier of each industrial device, the device port indication, and the device port connection indication between the ports of each industrial device (501). Obtain the device Ethernet parameters (502) for each corresponding industrial device. Based on the device identifier, the device port and device port connection, and the Ethernet parameters, instantiate the system object model of the Ethernet configuration of the automation system (503). A graph model representing the Ethernet configuration is generated from the system object model by applying a set of predefined rules (504). Ring detection is applied to the generated graph model by depth-first search (505). The verification result (506) is indicated based on the ring detection result; The instantiation of the system object model of the automation system includes creating an instance of a generic Ethernet object model for each corresponding industrial device based on the device identifier, the device port, the device port connection, and the device Ethernet parameters for each corresponding device; The general Ethernet object model includes a switching capability class, which represents the type and number of physical ports that exist and stores information about which Ethernet frames can be forwarded from one port to another through the data link layer based on MAC addresses. The general Ethernet object model includes a routing capability class, which represents the type and number of interfaces and stores information about which Ethernet frames can be transmitted from one network to another based on the routes defined in the routing capability using this interface.

2. The method of claim 1, further comprising issuing an alarm if the verification result indicates an error in the Ethernet configuration.

3. The method according to claim 1, wherein, The set of predefined rules that apply includes: Create a vertex for each device port; Create an edge for each device port connection; Create a vertex for each switching capability; and Create an edge between the switching capability vertex and the vertex of each device port switched by the switching capability.

4. The method according to claim 3, wherein, The set of predefined rules also includes: Create a vertex for each port of the routing capability (802); and Create a directed edge for each configured route that connects the ports within the routing capability.

5. The method according to claim 3, wherein, The set of predefined rules also includes: Create a corresponding vertex for each interface and each endpoint associated with such an interface; An edge is created between the vertex of each interface and the vertex of each endpoint associated with that interface.

6. The method according to claim 5, wherein, The set of predefined rules also includes: Create vertices for the broadcast domain; and Create edges that connect broadcast domain vertices to each endpoint that has an IP address belonging to that broadcast domain.

7. The method of claim 1, wherein the Ethernet parameters include IP address, broadcast domain and / or routing configuration.

8. The method according to claim 1, wherein, The general Ethernet object model also includes at least one of the following classes: Ethernet class, port class, IP range class, endpoint class, interface class, and / or broadcast domain class.

9. A topology manager configured as follows: Obtain the device identifier, device port indication, and device port connection indication between the ports of each of the multiple industrial devices in the automation system. Obtain the device Ethernet parameters for each corresponding industrial device; The system object model for the Ethernet configuration of the automation system is instantiated based on the device identifier, the device port and device port connection, and the Ethernet parameters. A graph model representing the Ethernet configuration is generated from the system object model by applying a set of predefined rules; The instantiation of the system object model of the automation system includes creating an instance of a generic Ethernet object model for each corresponding industrial device based on the device identifier, the device port, the device port connection, and the device Ethernet parameters for each corresponding device; The general Ethernet object model includes a switching capability class, which represents the type and number of physical ports that exist and stores information about which Ethernet frames can be forwarded from one port to another through the data link layer based on MAC addresses. The general Ethernet object model includes a routing capability class, which represents the type and number of interfaces and stores information about which Ethernet frames can be transmitted from one network to another based on the routes defined in the routing capability using this interface.

10. The topology manager of claim 9 is further configured to apply cycle detection via depth-first search based on graph theory.

11. A non-transitory computer-readable medium having a computer program stored thereon, the computer program comprising instructions for performing the steps of the method according to any one of claims 1-8 when executed by a processor.

Images