WO2021040727A1

WO2021040727A1 - Plc code generation with a knowledge graph

Info

Publication number: WO2021040727A1
Application number: PCT/US2019/048970
Authority: WO
Inventors: Oswin Noetzelmann
Original assignee: Siemens Aktiengesellschaft; Siemens Corporation
Priority date: 2019-08-30
Filing date: 2019-08-30
Publication date: 2021-03-04

Abstract

Code may be automatically developed for programmable logic controllers. A knowledge graph including a domain ontology may be received by a processor. Specification of a development environment for a programmable logic controller (PLC) may be received. The knowledge graph may be updated based on the development environment for the PLC. One or more links in the knowledge graph may be generated between the domain ontology and the development environment. The links may be based on the specifications and the domain ontology. A code target specific to the development environment may be generated based on the one or more links, the knowledge graph, and the specifications.

Description

PLC CODE GENERATION WITH A KNOWLEDGE GRAPH

FIELD

[0001] The following disclosure relates to generating code for programmable logic controllers using a knowledge graph.

BACKGROUND

[0002] Programmable Logic Controllers (PLCs) are computers that direct and control industrial processes. PLCs may help automate the industrial processes. For example, PLCs may control an assembly or manufacturing line, such as an assembly line for building a car door, by automatically coordinating the operation of the machines, such as robots and conveyors. PLCs may be required to be reliable, predictable, and stable in operation. At the same time, because PLCs may control a variety of different processes, PLCs are also flexible in application and programmable. In this way, a particular PLC may be adapted to control different processes depending on the programming.

[0003] Because a given PLC may be used in many different applications, the PLC is programmed for the specific industrial process controlled by the PLC. A common problem is to write the PLC programs quickly and efficiently. Typically, a PLC programmer must learn detailed knowledge about a real- world process in order to be able to develop the program for the PLC. This knowledge may be complex and often available in the form of natural language or from the programmer’s experience with the domain of the industrial application (e.g. the industry in general, a factory, a manufacturing process, or even a specific installation of the process). Developing the PLC programs this way may require the programmer to perform manual abstraction and manual modeling of the industrial process. The result is that PLC program development may be a lengthy, complex, and potentially error- prone task. SUMMARY

[0004] By way of introduction, the preferred embodiments described below include methods, systems, instructions, and computer readable media for generating code for programmable logic controllers using a knowledge graph. [0005] In a first aspect, a method is provided for developing code for programmable logic controllers. A processor receives a knowledge graph including a domain ontology. The processor receives specifications of a development environment for a programmable logic controller. The processor updates the knowledge graph based on the development environment. The processor generates one or more links in the knowledge graph between the domain ontology and the development environment based on the specifications and the domain ontology. The processor generates a code target specific to the development environment based on the one or more links, the knowledge graph, and the specifications.

[0006] In a second aspect, a system is provided for developing code for programmable logic controllers. An adapter is configured to receive a domain ontology, translate the domain ontology into a knowledge graph, and modify the knowledge graph to include a code generation ontology with a code source node having incomplete code. The code generation ontology is based on a development environment for a programmable logic controller. An ontology processor is configured to generate a code target node executable on the programmable logic controller by incorporating data from the domain ontology into the code source node via a link between the domain ontology and the code source node.

[0007] In a third aspect, a programmable logic controller code development system is provided. An ontology processor is coupled with a memory. The memory contains instructions that, when executed, cause the ontology processor to receive a knowledge graph including a structured model of an industrial instance, receive specifications of a programming environment for a programmable logic controller, generate one or more data associations between the model and the programming environment based on the specifications and the model, and generate a code target specific to the programming environment based on the one or more data associations, the knowledge graph, and the specifications.

[0008] The present invention is defined by the following claims, and nothing in this section should be taken as a limitation on those claims. Further aspects and advantages of the invention are discussed below in conjunction with the preferred embodiments and may be later claimed independently or in combination.

BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The components and the figures are not necessarily to scale, emphasis instead being placed upon illustrating the principles of the invention. Moreover, in the figures, like reference numerals designate corresponding parts throughout the different views.

[0010] Figure 1 illustrates a flowchart for generating PLC code from domain knowledge captured in a knowledge graph;

[0011] Figure 2 illustrates another embodiment of a method of generating PLC code;

[0012] Figure 3 illustrates a knowledge graph including a domain ontology; [0013] Figure 4 illustrates a knowledge graph including a domain ontology and a code generation ontology;

[0014] Figure 5 illustrates a knowledge graph including a domain ontology and a code generation ontology for a specific manufacturing process;

[0015] Figure 6 illustrates an interaction between a code generation system and an automation engineering system; and [0016] Figure 7 is a block diagram of one embodiment of a system for generating code for programmable logic controllers using a knowledge graph.

DETAILED DESCRIPTION OF THE DRAWINGS AND PRESENTLY PREFERRED EMBODIMENTS

[0017] While many PLC programs are coded using the vendor specific engineering systems, ranging from simple text editor and compiler combinations to complete development environments (for example TIA Portal from Siemens), some PLC code may be developed automatically. In some cases, domain specific software solutions are available from a single company for use in a narrow industry niche. For example, a company may generate PLC control programs for a certain brand of cranes or generate PLC programs for robot cells in the automotive industry. These approaches are limited to a particular industry, brand, or model and are unable to generate code for PLCs to be used outside of those limits.

[0018] By using a knowledge graph, a visual representation of a collection of interlinked descriptions of entities, to organize and connect domain-specific knowledge to the PLC code development environment, the PLC programs may be, at least in part, generated automatically, thereby formalizing and accelerating the PLC programming process. The domain ontology and representation of the ontology in the knowledge graph may apply to PLCs used in any variety of industrial applications and is not limited to code generation for particular domains like the approaches described above. Because the domain knowledge is captured in a knowledge graph, transparency of the programming process is increased because the knowledge graph may be reviewed more easily. The result is that PLC programming becomes faster, easier, and less prone to errors. PLCs running programs developed in this way may be more efficient, reliable, and safe because errors in the PLC program are more easily avoided and detected. [0019] Figure 1 illustrates a flowchart for generating PLC code. The system specific PLC code 117 is generated based on a knowledge graph 101. [0020] The knowledge graph 101 is a structured representation of the world, or a part thereof. Nearly any kind of information, e.g. from internet searches to information about industrial and automation technologies may be represented in the knowledge graph 101. The knowledge graph 101 may include information from a domain specific ontology 103. In some cases, the knowledge graph 101 may include information from a code generation ontology 105. The knowledge graph is shown in greater detail in figures 3, 4, and 5. Though examples of a knowledge graph are shown in the figures, the knowledge graph may be implemented in the form of a textual, graphical, three-dimensional, augmented reality, virtual reality interface, spreadsheet, linked files, or otherwise. The knowledge graph may conform to one or more standards, such as RDF, OWL, SPARQL, Tinkerpop, or Gremlin.

[0021] The domain specific ontology 103 is data that represents a specific industry or domain. For example, the domain ontology 103 may include information about an industry, a particular industrial facility, a particular industrial process within the facility, and/or a particular instance of the industrial process. Some domain ontologies 103 may include information at more than one level in the hierarchy. For example, the domain ontology 103 may include information about both an industry in general and a particular instance of an industrial process. Other combinations are possible.

[0022] The domain ontology 103 may initially be part of the knowledge graph 101 or may be added. For example, the domain ontology 103 may be manually or automatically added to the knowledge graph 101.

[0023] The domain ontology 103 may be expressed in the knowledge graph 101 as an ontology defined by a semantic web of the knowledge graph. The semantic web may structure the information of the domain ontology 103 and include information about hierarchies, dependencies, and information and material flows within the domain ontology 103.

[0024] The domain ontology 103 may represent a part of the information contained in the knowledge graph 101 and elements of the domain ontology may be linked to other information in the knowledge graph 101. For example, nodes, entities, or other elements of the domain ontology 103 may be linked to information of the code generation ontology 105.

[0025] The code generation ontology 105 includes information about the code generation system 109. By including both the domain specific ontology 103 and the code generation ontology 105 in the knowledge graph 101 , code may be generated based on the code generation ontology 105 using information in the domain ontology 103. For example, links in the knowledge graph may connect the code generation ontology 105 and the domain specific ontology 103 in the knowledge graph 101. The code generation ontology may include specifications of the code generation system 109, sometimes referred to as a development environment. The specifications may include identifications of code sources and code target. Code sources are building blocks of code that, when completed with external information (e.g. external to the source code), create the code target. The code target may be specified so that the correct information that is missing in incomplete source code may be added to the source code, e.g. via a link or call to another source of information. The incomplete areas in the source code may be annotated in the specifications of the code generation system as an interface. The interface allows for the importation of information from an external source to cure the incompleteness. The interface may identify code or variable data that needs to be acquired during the code generation process to complete the source code. The specifications may also identify the starting points in the source code, criteria, or other information based on which links between the code generation ontology and the domain specific ontology may be established. [0026] The knowledge graph adapter 107 may be configured to transform other information into the proper format for use in the knowledge graph 101. Additionally or alternatively, the knowledge graph adapter 107 may be configured to modify the knowledge graph. For example, the adapter 107 may receive instructions from the code generation system 109 (e.g. contained in the code generation ontology 105 or in another form) to add, remove, modify, update, or manipulate knowledge graph data. The adapter 107 may be configured to transform the domain specific ontology 103 and/or the code generation ontology 105 into a proper form at for inclusion in the knowledge graph 101. The adapter 107 may update the knowledge graph to include information in the domain specific ontology 103 and/or the code generation ontology 105. In some cases, the adapter 107 may be configured to query the knowledge graph. For example, the code generation system 109 may send a query that is received by the adapter 107. The adapter 107 may execute the query on the knowledge graph 101 and return information to the code generation system 109 based on the query.

[0027] The code generation system 109 develops the PLC code based on the knowledge graph 101. The code generation system 109 may be referred to as a development environment in some cases. The code generation system 109 may identify source code and code target (e.g. through specifications or through the code generation ontology 105). The code generation system 109 may receive user input via the input device 111. The specifications or ontology 105 may be changed, selected, identified, or defined based on user input or predefined rules.

[0028] The input device 111 may include a keyboard, mouse, display, touchscreen, or other human interface device. A user may change, select, identify, or define the specifications or ontology 105 of the code generation system 109 via the input device 111. For example, a user may use the input device 111 to generate an input to the code generation system 109 identifying a code target, a source code, an interface, or another property of the specifications or ontology 105. The identified code target, source code, interface, or another property may be incorporated in the knowledge graph 101. In some cases, the user may input a query to the code generation system 109 using the input device 111. The query may be executed by the adapter 107.

[0029] The engineering system adapter 113 is an intermediate adapter used to translate the generated code for compatibility with a PLC. Though a single adapter 113 is shown, multiple adapters 113 may be present. The adapter 113 may accept as input the generated code target from the code generation system 109 and output PLC system code 115.

[0030] The PLC code system 115 is an engineering code system that compiles, executes, and runs the system specific PLC code 117 on the PLC. The PLC code system 115 may accept the completed code target entries from the code generation system (in some cases, via an adapter 113) and communicates with the PLC to execute the code. The interaction between the code generation system 109 and the PLC code system 115 is shown in greater detail in Figure 6.

[0031] The system-specific PLC code 117 is code generated by the code generation system 109 (and, in some cases, transformed by one or more adapters 113) that is specific to a particular PLC. Because the knowledge graph 101 includes information from the domain ontology 103 and the code generation ontology 105, the PLC code 117 is specific to a particular PLC.

The system specific code 117 may include instructions for the PLC to operate the industrial process. For example, the system specific code 117 may instruct the PLC to control one or more pieces of machinery (e.g. robots, conveyors, or other machines).

[0032] Figure 2 illustrates a method of generating PLC code. More, fewer, or different acts may be performed. In some cases, act 201 may be omitted. The acts may be performed in a different order than shown. A processor coupled to a memory may be configured to perform one or more of the acts. For example, the ontology processor 703 of Figure 7 may be configured to perform one or more of the acts of Figure 1.

[0033] In act 201 , a knowledge graph is received. In some cases, the knowledge graph may be received or accessed by an adapter, such as the knowledge graph adapter 107. The knowledge graph may include a domain ontology. In some cases, the knowledge graph may not contain the domain ontology and the domain ontology may be incorporated into the knowledge graph. For example, the adapter 107 may modify or update the knowledge graph to include information from the domain ontology. Because knowledge graphs (and ontologies) may exist in different formats, standardized and proprietary, the adapter may be configured to translate the domain ontology as well as queries into the right target format for the knowledge graph. In this way, the knowledge graph may accept information from different graph databases and presented in different standards (e.g. triple/quad stores, property graphs, RDF/OWL/SPARQL, and/or tinker pop/gremlin).

[0034] In the knowledge graph, the domain ontology may be represented in semantic form. In semantic form, the entities (e.g. nodes) and structure of the domain ontology are represented in the knowledge graph by a semantic web of the knowledge graph. The semantic web, or semantic network, expresses the relationships (e.g. including dependencies, flows, and hierarchies) between the entities of the domain ontology. The domain ontology may contain information at different levels of generality or in a hierarchy. For example, the domain ontology may contain information about classes of entities (e.g. as shown in the knowledge graphs of figures 3 and 4) and about specific entities (e.g. as shown in the knowledge graph of Figure 5). [0035] In act 203, specifications of a development environment are received. The development environment may be a software programming development environment or code generation system specific to a PLC. For example, the development environment may be the code generation system 109 of Figure 1. In some cases, the specifications may be received by or accessed by an adapter, such as the knowledge graph adapter 107. The specifications may include information about an ontology of the development environment. For example, the specifications may include the code generation ontology 105 of Figure 1. Additionally or alternatively, the specifications (or the ontology 105) may include identifications of a code source. The code source contains the actual raw code that is used in the generation process as source. The code source may include incomplete code that requires external input for completion. Each instance of incompletion may be represented as an interface in the knowledge graph (e.g. as the knowledge graph is updated based on the development environment). The interface can then be linked to a data source in the domain specific ontology for indicating which domain data has to be used for completion of the code source. In some cases, the specifications may include an identification of a generation target. The generation target may be the code generated from the incomplete code source and the external data (e.g. from the domain ontology) used to complete the code source. By identifying the generation target, the proper data to complete the code source may be found in the domain ontology and code may be generated for an industry-specific or domain-specific ontology. [0036] In act 205, the knowledge graph is updated based on the development environment. In some cases, the adapter 107 or the ontology processor 703 may be configured to update the knowledge graph. The knowledge graph may be updated to include the specifications of the development environment. For example, the knowledge graph may be updated to include the code generation ontology, the code source, and/or the generation target. The code sources and generation targets (and other entities of the specifications or code generation ontology) may be semantically represented in the knowledge graph. In this way, once updated, the knowledge graph may include information about the domain ontology and the code generation ontology, which may be linked together. [0037] As part of updating the knowledge graph, code sources may be annotated with interfaces for connecting the incomplete code of the code source with data in the domain ontology to complete the incomplete code. The interface may have one of multiple classes. The variable interface class represents an instance of variable data to be acquired during the code generation process for completing the code source. Each variable interface instance is tied to a position in the code source that requires additional variable data for completeness. Examples of variable data are network addresses for devices, a number and identity of in-memory variables (e.g. generated on instance properties of connected objects in the knowledge graph), timing settings for the PLC code (e.g. how often a PLC block may be executed, determined based on requirements information in the knowledge graph or a functional model in the knowledge graph), and other information. Each instance of a variable interface may be linked to nodes, entities, or properties in the domain specific ontology to indicate the source of the variable data (e.g. by a variable link). Another interface class is the call interface class. A call interface represents the need for adding one or multiple calls to the code source to complete the code source. The call interface represents a specific position in the code source where the calls may be inserted. The external source of code may be referred to as the caller target (e.g. a recipient of a callee link, as described below). Additionally or alternatively, the call interface may be linked to a domain specific node or entity which may indicate how to generate the calls (e.g. via a caller link, as described below)

[0038] In act 207, one or more links in the knowledge graph are generated. The links may be generated between the domain ontology and the development environment (or the code generation ontology). For example, a link may connect a code source to data in the domain ontology. The link may be made with an interface of the code source. For example, a property of the interface may be used to define a link to data in the domain ontology. The links may be based on information in the specifications or code generation ontology. There may be different kinds of links, such as variable links, caller links, callee links, and “generated from” links. [0039] A variable link is a type of relation in the code generation ontology (or, more generally, the knowledge graph) that connects a variable interface to any other node, entity, or property in the knowledge graph, which may be interpreted as a source of variable data for the interface in the code generation process. For example, the variable link may connect an entity in the code generation ontology (such as the variable interface of a code source) to an entity within the domain specific ontology.

[0040] A caller link is a type of relation in the code generation ontology (or, more generally, the knowledge graph) that connects a call interface to any other node, entity, or property in the knowledge graph, which may be interpreted as a source for call generation. For example, the caller link may connect an entity in the code generation ontology (such as the call interface of a code source) to an entity within the domain specific ontology. The caller link may have an attribute that indicates different types of call generation. For example, the attribute may specify “one call for each entity”, “only call once”, and/or “number of calls determined by attribute value.”

[0041] A callee link is a type of relation in the code generation ontology that connects a call interface to a code source or target to indicate a target of a call or caller link.

[0042] A “generated from” link (GF link) is a type of relation in the code generation ontology that connects a code target to an originating code source. When traced from the code source(s), the code target may be identified, and when traced from the code target, the fundamental code source(s) may be identified.

[0043] In act 209, code target is generated. The code target may be generated based on the entities and links in the knowledge graph. For example, the code target may be generated based on one or more links, the knowledge graph, and the specifications. The code target may be specific to the development environment or code generation ontology. In some cases, the code target may also be specific to the domain ontology (e.g. to the industry, manufacturing facility, manufacturing process, or other real-world application represented in the domain ontology). The code target may be executable by the PLC. As described above, the code target may be generated based on the code source as completed by data from the domain ontology. Each code source may be evaluated and completed with the acquired data to build the corresponding code target. The Completed code targets may be added back to the knowledge graph and linked to the code sources. In the knowledge graph, a code target node may be a node or entity representing a generation target that contains the completed code as prepared by the code generation process. The completed code contains everything required by a target automation engineering system to compile, deploy and run the code. The code target node may be linked to the code source with a GF link. The completed code target may be output to the PLC for execution. In some cases, the completed code target may be output to one or more intermediate systems which may perform other operations on the code target or transfer the code to the PLC.

[0044] In act 211 , the code target is received at the PLC. The PLC may execute the code target. In this way, the PLC may control a real-world process using the automatically generated code target.

[0045] Figure 3 illustrates a knowledge graph including a domain ontology. As described above, the knowledge graph may be received with the domain ontology contained within, or the domain ontology may be added to the knowledge graph (e.g. via an adapter). Though a particular example of a knowledge graph is shown for one industrial process, the knowledge graph may be adapted to represent any process contained in a domain ontology. [0046] In this example, the domain ontology contains information about a manufacturing line 301 for producing a car door 303. The entities (or nodes) in the manufacturing line 301 include the car door 303 being built by a robot cell 305 welding a doorframe 307 built from sheet metal 309. The robot cell 305 includes a robot 311 , a worker 313, a controller 315, and a conveyor 317. The conveyor may have a property, such as a conveyor address 319. The arrows show the relations between the entities 301-319 and form part of the semantic web of the knowledge graph.

[0047] The manufacturing line 301 produces the car door 303 consisting of a doorframe 307 made from sheet metal 309 welded by a robot cell 305. [0048] The robot cell 305 includes many of the entities for welding the door frame 307. For example, the robot 311 may be a robotic arm welder for welding the door frame 307. The worker 313 may be a human worker assisting or supervising the robot 311. The worker 313 may include a safety zone within which the robot 311 may not operate.

[0049] The controller 315 may be the PLC for controlling the robot cell 305 and the entities of the robot cell 305. For example, the PLC may control the robot 311 and the conveyor 317.

[0050] The conveyor 317 may move material in the manufacturing line 301. For example, the conveyor may move the sheet metal 309, the door frame 307, and/or the car door 303. The conveyor may have a conveyor address 319. The conveyor address 319 may indicate a network address of the conveyor. For example, the conveyor 317 may receive instructions at the network address 319. In some cases, the controller 315 may send commands to the conveyor 317 at the conveyor address 319.

[0051] Figure 4 illustrates a knowledge graph including a domain ontology and a code generation ontology. For example, the knowledge graph of Figure 3 may be updated based on information from a development environment or code generation ontology including entities or nodes, and links. The knowledge graph may be updated according to acts 205 and 207 of Figure 2. The entities added from the development environment or code generation ontology include a first code source 401 having a call interface 403 and a variable interface 405, a second code source 407, and a code target node 409.

[0052] The first code source 401 and the robot cell 305 are linked by a caller link. The caller link means that the first code source is called based on the robot cell 305 (as opposed to another entity in the knowledge graph, such as the car door 303, the door frame 307, or the sheet metal 309). The first code source 401 has two instances of incompleteness. The first code source 401 uses two interfaces for incorporating external data to complete the two instances of incompleteness. The call interface 403 is used to call a second code source 407. The second code source 407 may provide code to the first code source 401 via the link and call interface 403 to complete a part of the first code source 401. The call interface 403 is also linked to the conveyor 317. The link specifies “call for each,” meaning that an instance of the call interface 403 and/or the second code source 407 will be called for each instance of the conveyor 317. For example, where there are two conveyors 317 in the robot cell 305, the call interface may call two instances of the second source code 407. Though only one conveyor 317 is shown in Figure 4, the element 317 may, in some cases, represent multiple conveyors.

[0053] The variable interface 405 is used to provide variable data to the first code source 401. The variable interface 405 is linked to the conveyor address 319. In this way, the address 319 of the conveyor 317 (e.g. a network address that may change or be different for different conveyors) may be provided for completing the first code source 401.

[0054] The first code source 401 generates, or is used to generate (e.g. by an ontology processor or a code generation system), the code target 409. The code target may be generated based on the code source as completed by data from the interfaces (e.g. the second code source 407 and the conveyor address 319). Moving from the code source 401 to the code target, the link may be referred to as a generates link. In the opposite direction, going from the code target, the link may be referred to as the GF link. The code target may be run by the PLC 315. Though the “is run by” link connects the code target 409 and the controller 315, one or more systems or intermediaries may separate the code target 409 and the controller 315.

[0055] Figure 5 illustrates a knowledge graph including a domain ontology and a code generation ontology for a specific manufacturing process. As discussed above, the domain ontology may contain information at different levels of generality or in a hierarchy. While Figure 4 shows a knowledge graph for the manufacturing line 301 as a class of entities, the knowledge graph in Figure 5 shows an instance of the domain ontology for a specific instance of the manufacturing line (“manufacturing line A”) having a specific robot cell 305 (“robot cell 1337”). The knowledge graph of Figure 5 may be considered at a lower level in the hierarchy of the domain ontology. Figure 5 shows that the links may be made to and from any and all layers of the domain ontology. Because the links between the domain ontology and the code generation ontology were generated for the class-level knowledge graph of Figure 4, the “lower level” or instance knowledge graph of Figure 5 may also retain those links. In this way, the code target 409 may be generated for a specific controller 315 (“controller A”) controlling a specific robot cell 305 including a specific robot 311 (“Robot X”) and conveyor 317 (“conveyor 0001”) having a specific conveyor address 319 (“192.168.0.1”). The resulting code target may be specific to the domain ontology and/or the code generation ontology (also known as the development environment).

[0056] Figure 6 illustrates an interaction between a code generation system 601 and an automation engineering system 603. The interaction describes the process of the generated code target being made available to the PLC for execution.

[0057] The code generation system 601 may be the code generation system 109 or 701 of Figure 1 or Figure 7, respectively. The code generation system 601 may include an ontology processor. The code generation system 601 receives information from the knowledge graph 605 and generates the code target. The information may include instance and semantic data from the knowledge graph. For example, and as described above with respect to figures 1-5, the code target may be generated based on code sources completed by data from a domain ontology in the knowledge graph 605. Depending on whether the generated code target is standardized, the code generation system may output the code target to industry standard adapters 607 and/or to target system adapters 609. The adapters 607, 609 interact with the automation engineering system 613 and translate data as necessary, thereby allowing the code generation system 601 to be compatible with additional or different automation engineering systems.

[0058] The industry standard adapters 607 may receive the code target to ensure that the code target complies with industry standards or to modify the code target to comply with the standards. The standards may include safety standards for the use and implementation of safety switches, safety programs, and PLC redundancy for safety-critical tasks (e.g. when humans interact or are present around robots). Ensuring compliance with the standards may include checking on the use of certified hardware, certified software, and specific programming languages for the code blocks, as well as checking that required safety devices are included in the code blocks and controllers. Additionally or alternatively, the standards may include machine-specific standards, such as standards for controlling conveyor belt groups. For example, the standards may define logic for controlling the conveyor group for parking or level-switching. They conveyor group hardware setup and/or the conveyor control code blocks may be checked against the standards to ensure best practices are used.

[0059] The result of the modification is standardized PLC code 611 . The format of the code target may change. For example, the adapter may convert the code target to an industry format, such as PLC Open file formatting. By converting the code target to an industry standard, the converted code target may be used by any system supporting the standard. For example, the standardized PLC code may be output to an automation engineering system 613 when the system 613 supports the industry standard of the standardized PLC code 611. The automation system 613 may then provide the standardized code 611 to the PLC 615 for execution.

[0060] The target system adapters 609 may receive the code target to ensure that the code target complies with rules and standards of the target system (e.g. the engineering system 613 for the PLC 615). In some cases, the standards of the target system may be contained in the code generation ontology (or as part of the specifications incorporated in the knowledge graph). When the knowledge graph already contains such information, the generated code target may be compliant with the target system standards, and the code target may be provided to the automation engineering system. A generated code target compliant with the standards of the target system may be referred to as system specific PLC code 617.

[0061] An interface 619 may receive the system specific PLC code 617.

For example, the interface 619 may be Siemens TIA Portal Openness interface. The interface 619 may expose the relationships between code targets and code sources in the knowledge graph. Certain entities and links in the knowledge graph may be marked as protected from editing through the interface 619. The interface 619 may allow for browsing, editing, and querying of the knowledge graph, thereby enabling users of the automation system 613 to inspect, understand, and audit the knowledge graph. Using the interface, users may input commands creating or modifying entities in the knowledge graph, establishing links between the entities in the knowledge graph, and creating instances of the knowledge graph. Because the interface 619 works with the knowledge graph, users of any automation system 613 may benefit from the transparency, reliability, and other benefits of generating the PLC code based on the knowledge graph. In some cases, the interface 619 may be provided by the automation engineering system 613. In some other cases, the interface may be implemented by one or more components of the code generation system, for example, the display 711 and adapter 707 of Figure 7. [0062] In some cases, the system specific PLC code 617 may be received at the automation engineering system 613 without the use of an interface. The system specific PLC code 617 may be provided by the automation system 613 and received at the PLC 615 for execution.

[0063] Figure 7 is a block diagram of one embodiment of a system for generating code for programmable logic controllers using a knowledge graph. The code generation system 701 may include an ontology processor 703 coupled with a memory 705 and in communication with an adapter 707, a PLC 709, and a display 711.

[0064] The code generation system 701 may be the code generation system 109 of Figure 1. Additionally or alternatively, the code generation system 701 may be the code generation system 601 of Figure 6. The code generation system 701 including one or more components 703-711 of the code generation system 701 may be configured to perform one or more of the acts of Figure 2 or other acts. The code generation system 701 may be implemented in one or many different forms. For example, the code generation system 701 may be implemented as a desktop computer program, a server-based computer program, a mobile application, a cloud-based service, or otherwise. The code generation system 701 may be general and not specific to an industry or domain. This is achieved by a method of domain integration by linking to data in the knowledge graph that represents a specific industry or domain (e.g. Figure 2). [0065] The ontology processor 703 may be a general purpose or application specific processor. The ontology processor 703 may be configured to or may execute instructions that cause the ontology processor 703 to generate a code target node executable on the programmable logic controller by incorporating data from the domain ontology into the code source node via a link between the domain ontology and the code source node. In some cases, the ontology processor 703 may be configured to generate the link between the domain ontology and the code source node based on a property of the interface of the code source. The ontology processor 703 may interface with the knowledge graph through the adapter 707. The ontology processor 703 may access, send, or receive data from the knowledge graph through the adapter 707. For example, the ontology processor 703 may receive the code sources and data received through one or more interfaces of the code sources (e.g. by one or more links in the knowledge graph) through the adapter. Additionally or alternatively, the ontology processor 703 may interface with the knowledge graph directly or through another intermediary. The ontology processor 703 may communicate with the PLC 709. In some cases, the ontology processor 703 communicates with the PLC 709 directly.

In some other cases, the ontology processor 703 communicates with the PLC 709 via an interface. For example, the ontology processor 703 may communicate with the PLC 709 using a network adapter or another device. In another example, and as described in Figure 6, the ontology processor as part of the code generation system 601 may communicate with the PLC 615, 709 via one or more adapters and an automation engineering system 613. [0066] The memory 705 may be a non-transitory computer readable storage medium. The memory 705 may be configured to store instructions that cause the processor to perform an operation. For example, the memory 705 may store instructions that, when executed by the processor 703, cause the processor 703 to perform one or more acts of Figure 2 or other acts. The memory 705 may be configured to store a domain ontology, a code generation ontology, a knowledge graph, a code source, a code target, call data, variable data, a system specific PLC code, standardized PLC code or other information. The instructions for implementing the processes, methods, and/or techniques discussed herein are provided on non-transitory computer- readable storage media or memories, such as a cache, buffer, RAM, removable media, hard drive, or other computer readable storage media. Non-transitory computer readable storage media include various types of volatile and nonvolatile storage media.

[0067] The adapter 707 may be a software module executed by the ontology processor. In some cases, the adapter may be implemented by a separate processor or by standalone hardware. The adapter 707 may be configured to receive a domain ontology and translate the domain ontology into a knowledge graph. Additionally or alternatively, the adapter 707 may be configured to modify the knowledge graph to include a code generation ontology with a code source node having incomplete code. Additionally or alternatively, the adapter 707 may be configured to receive a query from the development environment, execute the query using the knowledge graph, and provide the code target node to the development environment. For example, a query may be generated based on user input (e.g. at the display 711 or the input device 111 of Figure 1) that requests inspection of the code target. In some cases, the query may include includes an identification of the source code of the development environment. The adapter may receive the query and return the queried code target. Additionally or alternatively, the adapter may be configured to modify the knowledge graph based on the query. For example, a user may provide input (e.g. through the display 711) containing instructions to create or modify entities or links in the knowledge graph and the adapter may be configured to carry out the instructions. The queried code target may be displayed to the user through the display 711. In some cases, the adapter may be the adapter 107 of Figure 1 .

[0068] The PLC 709 may be configured to receive and execute the completed code target. The PLC may be the PLC 315 or 615 of Figure 3 and Figure 6, respectively. Based on the received and executed code target, the PLC 709 may control one or more industrial processes. For example, the PLC 709 may instruct a robot to weld the frame of a car door in a manufacturing line. [0069] The display 711 may be configured to accept user input and to display audiovisual information to the user. In some cases, the display 711 may include a screen configured to present the audiovisual information. For example, the display 711 may present the knowledge graph. The interface 619 of Figure 6 may be implemented by the processor using the display 711. Via the display 711 , users of the interface 619 may inspect the knowledge graph and check the entities and links resulting in the code target. The display 711 may include a user input device. For example, the display may include a keyboard, mouse, and/or a virtual or augmented reality environment. In some cases, the user may input information relating to defining a new code target or for modifying the knowledge graph. In some cases, the input device 111 of Figure 1 may be part of the display 711.

[0070] While the invention has been described above by reference to various embodiments, it should be understood that many changes and modifications can be made without departing from the scope of the invention.

It is therefore intended that the foregoing detailed description be regarded as illustrative rather than limiting, and that it be understood that it is the following claims, including all equivalents, that are intended to define the spirit and scope of this invention.

Claims

I (WE) CLAIM:

1. A method for developing code for programmable logic controllers, the method comprising: receiving, by a processor, a knowledge graph including a domain ontology; receiving, by the processor, specifications of a development environment for a programmable logic controller; updating, by the processor, the knowledge graph based on the development environment; generating, by the processor, one or more links in the knowledge graph between the domain ontology and the development environment based on the specifications and the domain ontology; and generating, by the processor, a code target specific to the development environment based on the one or more links, the knowledge graph, and the specifications.

2. The method of claim 1 , wherein the development environment is a software programming development environment specific to the programmable logic controller.

3. The method of claim 1 , wherein the code target is executable by the programmable logic controller.

4. The method of claim 1 , wherein the development environment includes a code source, wherein the link connects the code source and data of the domain ontology, and wherein the code target is generated based on the code source and the data from the domain ontology.

5. The method of claim 4, wherein the code source includes incomplete code and an interface for completing the incomplete code, and wherein the link connects the interface of the source code with the data in the domain ontology.

6. The method of claim 5, wherein generating the one or more links is based on a property of the interface.

7. The method of claim 1 , further comprising: receiving, at the programmable logic controller, the code target, and executing, by the programmable logic controller, the code target.

8. The method of claim 1 , wherein the domain ontology is represented in semantic form in the knowledge graph, and wherein one or more entities or relations of the domain ontology are represented in the knowledge graph as an ontology defined by a semantic web of the knowledge graph.

9. A system for developing code for programmable logic controllers, the system comprising: an adapter configured to receive a domain ontology, translate the domain ontology into a knowledge graph, and modify the knowledge graph to include a code generation ontology with a code source node having incomplete code, the code generation ontology being based on a development environment for a programmable logic controller; and an ontology processor configured to generate a code target node executable on the programmable logic controller by incorporating data from the domain ontology into the code source node via a link between the domain ontology and the code source node.

10. The method of claim 9, wherein the code generation ontology includes a generation target, and wherein the code target node in the code generation specific ontology is based on the generation target of the development environment.

11. The method of claim 9, wherein the domain ontology is represented in semantic form in the knowledge graph, and wherein one or more entities or relations of the domain ontology are represented in the knowledge graph as an ontology defined by a semantic web of the knowledge graph.

12. The method of claim 9, wherein the code source node includes an interface for completing the incomplete code in the code source node, and wherein the link connects the interface of the code source node with the data in the domain ontology.

13. The method of claim 12, wherein the ontology processor is configured to generate the link between the domain ontology and the code source node based on a property of the interface.

14. The method of claim 13, wherein the code target node is generated based on the code source node as completed with data from the domain ontology received over the link through the interface.

15. The method of claim 9, wherein the adapter is configured to receive a query from the development environment, execute the query using the knowledge graph, and provide the code target node to the development environment.

16. The method of claim 15, wherein the query includes an identification of the source code of the development environment.

17. The method of claim 15, wherein the adapter is configured to modify the knowledge graph based on the query.

18. The method of claim 9, wherein the data of the domain ontology is a source of variable data, and wherein the variable data is provided to the code source node via the link.

19. The method of claim 9, further comprising: the programmable logic controller configured to receive and execute the code target node.

20. A programmable logic controller code development system comprising: an ontology processor, coupled with a memory containing instructions that, when executed, cause the ontology processor to: receive a knowledge graph including a structured model of an industrial instance; receive specifications of a programming environment for a programmable logic controller; generate one or more data associations between the model and the programming environment based on the specifications and the model; and generate a code target specific to the programming environment based on the one or more data associations, the knowledge graph, and the specifications.