WO2020046301A1

WO2020046301A1 - Automatic generation of opc ua servers and clients from knowledge models

Info

Publication number: WO2020046301A1
Application number: PCT/US2018/048682
Authority: WO
Inventors: Simon Mayer; Richard Gary Mcdaniel
Original assignee: Siemens Aktiengesellschaft; Siemens Corporation
Priority date: 2018-08-30
Filing date: 2018-08-30
Publication date: 2020-03-05

Abstract

A system and method for automatic generation of a server based on a knowledge model includes a translator performs a structure translation of a knowledge model of a physical component in an autonomous system to generate instances of an Open Platform Communications (OPC) Unified Architecture (UA) model by parsing implicit semantics of the knowledge model and applying heuristic mapping of elements of knowledge model instances to attributes and references of the OPC UA model. A synthesizer synthesizes code to expose OPC UA instances in a server by matching the instances with instance implementations stored in a library and creating an object or class for each instance implementation.

Description

AUTOMAT!C GENERATION OF OPC UA SERVERS AND CLIENTS

FROM KNOWLEDGE MODELS

TECHNICAL FIELD

[0001] This application relates to autonomous systems. More particularly, this application relates to creating servers for autonomous systems.

BACKGROUND

[0002] The Open Platform Communications (OPC) Unified Architecture (UA) is a standardized machine~to~machine cross-platform communication protocol for data collection and control of autonomous industrial equipment and systems. The OPC UA Information Model (IM) is defined as a full mesh network based on nodes and references. The nodes may include meta Information, and may relate to an object, a variable, a method (e.g., a command), a triggered event, or process data. References are directed relations between two nodes. Apart from a standardized set of nodes and references, companion specifications may be created to extend the set. Applying the OPC UA protocol for a particular autonomous system design is favorable since it is backed by a strong, integrated community with common motivation, challenges, use cases, and goals. OPC UA servers are useful for allowing a user to query a system for data related to a particular object or system component. For instance, a server may be created for a conveyor as an OPC UA IM object having a variable for its speed. The conveyor may send the speed information to the server, and the user may query the server to obtain the speed information.

[0003] However, tool support for creating OPC UA servers is limited and incorporating existing knowledge from semantic models of various domains must be done manually by converting this knowledge into instances of the OPC UA IM that form the basis of OPC UA server implementations. OPC UA servers usually exist in isolated and/or tailored deployment scenarios, which require speciaiized knowledge and skill to maintain the server for future modifications to physical components. For instance, when a component or equipment may be built by a supplier and deployed by the designer, the supplier may have server software hard coded to the OPC UA model. Later modifications to the equipment, particularly if a long time has passed, may require the tailored software to be modified by a third party who lacks the requisite knowledge. For instance, following deployment of a system and after system is up and running, original source and development information is typically discarded or lost. There is a need for creating interoperable servers and clients within a domain and based upon an updatable and maintained knowledge model, and for cross-domain interoperability in autonomous systems.

SUMMARY

[0004] Aspects according to embodiments of the present disclosure include a process and a system to automatically generate Open Platform Communications (OPC) Unified Architecture (UA) servers from knowledge models of an automation system component configured to perform tasks in an automated process. The system may include a translator component for parsing Implicit semantics from knowledge models, and capable of reading all relevant formats for knowledge models (e.g., RDF format). The translator maps the parsed semantics to OPC UA instances of identifiers, nodes and references. A synthesizer exposes the instances as a server, which serves as a digital twin of a physical component, such as an industrial automation device. A corresponding client may also be generated by the synthesizer, the client being an interface for access to the server and having command, reporting and query functionality corresponding to requests for information and making parameter adjustments to the physical component via the server

BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Non-limiting and non-exhaustive embodiments of the present embodiments are described with reference to the following FIGURES, wherein like reference numerals refer to like elements throughout the drawings unless otherwise specified.

[0006] FIG. 1 is a diagram showing an example of an engine for automatically generating an OPC UA server from available knowledge models in accordance with one or more embodiments of the disclosure.

[0007] FIG. 2 is a flow diagram showing an example of a process for automatically generating an OPC UA server from available knowledge models in accordance with one or more embodiments of the disclosure.

[0008] FIG. 3 is a diagram showing an example of structure translation from a knowledge model protocol to an OPC UA address space protocol in accordance with one or more embodiments of the disclosure.

[0009] FIG. 4 shows an exemplary computing environment within which embodiments of the disclosure may be implemented.

DETAILED DESCRIPTION

[0010] Methods and systems are disclosed for automatic generation of Open Platform Communications (OPC) Unified Architecture (UA) servers from knowledge models of automation components, the servers configured as a digital twin of corresponding automation components to serve industrial control features to an operator. In contrast, conventional approaches for constructing OPC UA servers are performed manually by writing code according to OPC UA IM protocol, one-by-one for each instance of control features related to a particular automation component, which requires a specialized skill set, demands greater resources, and consumes significantly more time. Moreover, the automatic servers generation disclosed herein greatly reduce production downtime in the industrial process when modifications are performed on automation system components, needing only minor updates to the associated knowledge model and the server may be quickly resynthesized without need for manual coding. Another advantage of the disclosed methods and systems over conventional approaches is that the synthesized servers are not limited to exist in isolated deployment scenarios, but rather enable bridging across scenarios and automatically detecting changes to be propagated to server data, thus implementing server agility. The methods and systems disclosed herein further include automatic generation of OPC UA clients for interfacing with the synthesized server, as a proposed extension of the OPC UA IM to include both standardized and customized objects and references. Client implementations may explicitly hide or ignore custom references, and users are enabled to selectively switch between hiding and showing the custom references. The custom references and objects may be browsed using customized OPC UA clients.

[0011] FIG. 1 shows an example of an engine for automatically generating an OPC UA client-server from available knowledge models of automation components in accordance with one or more embodiments of the disclosure. A client-server generation engine 1 1 1 may reside in a storage device, such as memory 101 , and may include various program modules of executable instructions, including a translator module 1 12 and a synthesizer module 1 13, useful for creating associations between instances of a knowledge model and instances of an OPC UA information model. Processor 121 may fetch and execute the executable instructions via data bus 1 15, and inputs/outputs for the executions may be stored in a secondary data storage 131.

[0012] In an embodiment, translator module 1 12 may be configured to read knowledge models of various protocols and to parse implicit semantics of the knowledge models, which may be then stored in data storage 131 into bins by categories. For example, a knowledge model of a component in a particular automation system may be encoded using a query language for databases, such as Resource Description Framework (RDF), XML-based languages (e.g., DQL), graph query languages (e.g., GraphQL), and topic map query languages. The knowledge model may have been generated by a knowledge-based engineering or design phase of an automation system. Translator module 1 12 may be configured to read and parse instances in the knowledge model for such various query languages, and to complete a structure translation from knowledge model protocol that maps the parsed instances to OPC UA !M node identifiers and references. The mapped OPC UA IM node identifiers and references may be stored in data storage 131 according to an organized structure.

[0013] In an embodiment, synthesizer module 1 13 may be configured to execute a code synthesis to create a server, where the server exposes the OPC UA code for access by an OPC UA client, making the digital twin of the component accessible to a user for sending data and control requests and commands from the client, and sending responses from the server to the client. The server and client may be stored in data storage 131 for access upon demand.

[0014] FIG. 2 is a flow diagram showing an example of a process for automatically generating an OPC UA server from available knowledge models in accordance with one or more embodiments of the disclosure. In an automation environment having multiple industrial components arranged to perform designed tasks, where it is desirable to permit automated controls of the components using a client-server model, the components may first be represented according to a virtual knowledge model in a way useful for compiling machine readable information. For example, a RDF model may consist of a collection of statements of resources expressed as subject-object-predicate triples representative of a resource, where the subject is the resource, attributes of the resource are the object, and the predicate is the relationship between the subject and object. In one such abstract model, a physical component 201 (e.g., a robotic device, or a conveyor used in a production environment) may be represented according to the resource statements which intrinsically represent a labeled and directed graph stored as a relational database. Translator 204 may be configured to identify implicit semantics of the knowledge model 203. For example, translator 204 may parse the knowledge model statements, and may isolate subjects and predicates in the knowledge model to identify candidate OPC node identifiers and references of OPC UA instances 205 corresponding to the knowledge model instances.

[0015] FIG. 3 is a diagram showing an example of structure translation from a knowledge model protocol to an OPC UA address space protocol in accordance with one or more embodiments of the disclosure, and will now be described in conjunction with FIG. 2. In an embodiment, translator 204 may perform a structure translation 310 as shown in FIG. 3 from a knowledge model to a structured OPC UA model by a process that involves mapping of instances. The knowledge model may be of a structured database language with instances 301 being triples having subject 302, object 303 and predicate 304. One such database triple-based language is RDF. Other compatible relational database languages that can build the knowledge model as a mapped graph, including but not limited to GraphQL and DQL, may be applied to implement the embodiments described in this disclosure. Structure translations 310 may be performed on the knowledge model instances 301 using the translator 204, by parsing the knowledge model instances 301 and extracting implicit semantics for mapping to nodes of relevant OPC UA instances. FIG. 3 shows an example in which the elements of a knowledge model triplet 301 , such as subject 302, object 303, and predicate 304, may be mapped to elements of an OPC UA instance, such as node 31 1 identifier 312, attribute 313, and reference 314. For example, a triplet predicate 304 may be mapped to an OPC reference 314. One problem to be addressed for the translator 204 mapping is that predicate 304 and object 303 can be mapped to either an OPC attribute 313 or an OPC reference 314:

{RDF predicate => OPC attribute field name,

RDF object => OPC attribute value} or

{RDF predicate => OPC reference link name,

RDF object ^ OPC reference to object} Accordingly, there needs to be a way to distinguish the two when the RDF object is a member of the same set of values as an RDF subject in OPC, an attribute value can be another OPC object, so distinguishing based on the type of the RDF object is not sufficient in an embodiment, the heuristic coding for transiator 204 may include the following mapping elements: VariableNode corresponding to attributes and/or attribute values, ReferenceNodes corresponding to references/objects, and ArrayReferences for references to multiple objects. The distinction may be achieved using the following heuristic. Any subject/predicate/object triple that has a graph literal” as an object (https://www.w3.org/TR/rdf1 1 -concepts/#section~Graph~Uteral) may be mapped to a routine that creates a new typed VariableNode (e.g., using Eclipse Milo, UaVariab!eNode with a type identifiers. String

[https://github.com/eciipse/miio/biob/master/opc-ua-stack/stack- core/src/main/java/org/eclipse/milo/opcua/stack/core/ldentifiers.java]), and the node may be added as an OPC Attribute/Property. A literal in an RDF object is used for values such as strings, numbers and dates, and may include a lexical form (Unicode string), a datatype IR! (identifying datatype that determines how the lexical form maps to a literal value), and/or a language tag. For other triples in which the object does not include a literal, the transiator code may check the cardinality of the RDF relationship to decide whether to create a Reference or an Array Reference (e.g., one or multiple instances of UaObjectNode in Eclipse Milo plus a Reference object per reference). Accordingly, RDF literals may be identified either directly by identifying the data type, or by considering the position in an RDF graph. Alternatively, an algorithm may be used that determines whether a specific RDF object is mappable to a VariableNode, which can be done based on the OPC UA library that is used for implementing the synthesis. For example, based on an enumeration of Variable Node Types in Eclipse Milo (https://github.com/eclipse/milo/blob/master/opc-ua-stack/stack- core/src/main/java/org/eclipse/milo/opcua/stack/core/ldentifiers.java) and its utility functions to create VariableNodes (in particular UaVariableNode.setDataTypeQ). In some embodiments, the type of reference in the RDF may be explicitly encoded.

[0016] As a practical example of the translator 204 mapping, one of these OPC nodes 31 1 might represent the upper arm of a robot, another node 31 1 might represent a hinge of that robot, and both of these nodes might reference other components (e.g., a node that represents the rigid body of the arm). The nodes 31 1 may also reference each other - the rigid body of the hinge might be physically connected to the rigid body of the upper arm. All these relationships are evident in the RDF, getting parsed by the translator 204, and may be mapped to relationships as“references” 314 in the OPC UA model. With respect to programming this example, adding an “attach” reference between a hinge and a rigid body of an arm looks may be coded as follows: addReference(hinge6, armObody, ASRWhiteidentifiers. attach. getNode!dQ)

This function may retrieve the OPC UA node ID of the hinge6 and of the armObody objects (both these had earlier been created), then it may create a new OPC UA reference of the class“attach”. This type of reference also carries an OPC UA node ID that is, in this case, loaded from a group of specialized node IDs“ASRWhiteidentifiers”.

[0017] Returning to FIG. 2, synthesizer 206 may be configured to synthesize code for server 210 that represent physical component 201 as a digital twin of the physical component 201. The synthesizer 206 may be implemented using a library that contains OPC UA instance implementations (e.g., generic implementations, implementations templates). The synthesizer 206 may tap into the library and match the mapped OPC instances 205 created by translator 204 to library templates. In an embodiment, the library may be open source, such as Eclipse Milo or Open 62541 , and for each OPC instance, the synthesizer 206 may create a class or object (e.g., JAVA class, or JAVA object) that implements and exposes the instance of the OPC UA Information Model. The synthesizer 206, being one step meta from a compiler, may automatically run to create source code, which may then be compiled.

[0018] The synthesizer 206 may similarly synthesize a client 220 for displaying and managing data from the server 210, which allows the OPC UA code to be exposed by the server 210 to the client 220. Client 220 may be a specialized OPC UA client (i.e., an application specific client) or a generic OPC UA client. Accordingly, a client-server may be generated that makes the digital twin of the component 201 accessible to a user for sending data and control requests 223 and commands 221 from the client 220, and receiving responses 225 from the server 206 responsive to the requests 223. The server 210 and client 220 may be stored in data storage 131 for access upon demand.

[0019] In an embodiment, the server 210 and client 220 may be automatically generated when physical component is initially deployed in an industrial system. Another embodiment may be implemented to cover a scenario when physical component 201 is modified, such as for maintenance purposes. Examples include a robotic arm receiving a control software update, or a motor replacement. As an illustrative example, physical component 201 may be a conveyor used in a production operation, and knowledge model 203 may include instances related to attributes of the conveyer, such as belt characteristics. The server 210 for this example may include coding that enables the response 225 to comply with a request 223 for conveyor speed Information. In the event of altering a part of the conveyor, such as replacing the belt, the server 210 may require recoding to accurately process the speed information, as the new belt material does not behave identically to the previous belt material (e.g., friction coefficient is different). There may be multiple OPC attributes affected by such a modification, which when using conventional OPC server implementations would necessitate manual coding of every OPC instance for the physical component 201. Additionally, there would be the added burden for the user to have an understanding of the server coding, which may now be several versions out of date, or by passage of time and personnel changes, may not be possible. However, as an advantageous feature of this embodiment, knowledge model 203 may be easily modified to update the changed attribute, such as belt material, due to the explicit nature of the graphical language (Le , a visible presentation of the knowledge model) compared with relationships buried in a server code. Then the translator 204 may be rerun to analyze the revised knowledge model 203, automatically translating the knowledge model, followed by synthesizer 206 automatically synthesizing an updated server 210 as described above for the initial server 210 generation, while the user avoids the hassle of manual coding. Similarly, the client 220 may be automatically resynthesized to capture the updated knowledge model.

[0020] The advantages of using semantic knowledge models to automatically generate OPC UA servers include the following. Tools for working with semantic models are readily available and they can even be automatically generated themselves from a broad range of formats, e.g. from UML models or XML descriptions of systems. Since semantic knowledge models are interconnected for enabling interoperability between systems (within individual domains as weil as across domains), the generated OPC UA servers from such knowledge models may then enjoy the same interoperability. Furthermore, semantic modelling (in particular with embedded functional profiles) is a primary enabler of autonomous systems (together with machine learning systems) and consequently the generated OPC UA servers would automatically inherit this enabling property as well. Finally, basing servers on semantic models facilitates the interaction of client software with them, since the models can be readily exchanged between tiers and language bindings exist for most relevant programming languages (e.g., libraries for handling RDF data, the predominant format for serializing knowledge models). Automatic generation of OPC UA servers from knowledge models saves time and effort, especially if the models themselves can be generated from other files. In addition, human error introduced during switching between formats (e.g., UML, RDF, OPC UA) may be eliminated. Representations of OPC UA equipment may be automatically upgraded when underlying standards change or when the systems are integrated with other systems that were not foreseen at the time of implementation.

[0021] FIG. 4 shows an exemplary computing environment within which embodiments of the disclosure may be implemented. As shown in FIG. 4, the computer system 410 may include a communication mechanism such as a system bus 421 or other communication mechanism for communicating information within the computer system 410. The computer system 410 further includes one or more processors 420 coupled with the system bus 421 for processing the information. [0022] The processors 420 may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art. More generally, a processor as described herein is a device for executing machine- readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and/or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may include any type of suitable processing unit including, but not limited to, a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System-on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 420 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read/write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor may be capable of supporting any of a variety of instruction sets. A processor may be coupled (electrically and/or as comprising executable components) with any other processor enabling interaction and/or communication there-between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

[0023] The system bus 421 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may permit exchange of information (e.g., data (including computer-executable code), signaling, etc.) between various components of the computer system 410. The system bus 421 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The system bus 421 may be associated with any suitable bus architecture including, without limitation, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnects (PCI) architecture, a PCI-Express architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.

[0024] Continuing with reference to FIG. 4, the computer system 410 may also include a system memory 430 coupled to the system bus 421 for storing information and instructions to be executed by processors 420. The system memory 430 may include computer readable storage media in the form of volatile and/or nonvolatile memory, such as read only memory (ROM) 431 and/or random access memory (RAM) 432. The RAM 432 may include other dynamic storage device(s) (e.g., dynamic RAM, static RAM, and synchronous DRAM). The ROM 431 may include other static storage device(s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory 430 may be used for storing temporary variables or other intermediate information during the execution of instructions by the processors 420. A basic input/output system 433 (BIOS) containing the basic routines that help to transfer information between elements within computer system 410, such as during start-up, may be stored in the ROM 431. RAM 432 may contain data and/or program modules that are immediately accessible to and/or presently being operated on by the processors 420. System memory 430 may additionally include, for example, operating system 434, application programs 435, and other program modules 436.

[0025] The operating system 434 may be loaded into the memory 430 and may provide an interface between other application software executing on the computer system 410 and hardware resources of the computer system 410. More specifically, the operating system 434 may include a set of computer-executable instructions for managing hardware resources of the computer system 410 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). In certain example embodiments, the operating system 434 may control execution of one or more of the program modules depicted as being stored in the data storage 440. The operating system 434 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system. [0026] The application programs 435 may a set of computer-executable instructions for performing the iterative keypoint and viewpoint invariant feature learning for visual recognition process in accordance with embodiments of the disclosure.

[0027] The computer system 410 may also include a disk/media controller 443 coupled to the system bus 421 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 441 and/or a removable media drive 442 (e.g., floppy disk drive, compact disc drive, tape drive, flash drive, and/or solid state drive). Storage devices 440 may be added to the computer system 410 using an appropriate device interface (e.g., a small computer system interface (SCSI), integrated device electronics (IDE), Universal Serial Bus (USB), or FireWire). Storage devices 441 , 442 may be external to the computer system 410, and may be used to store image processing data in accordance with the embodiments of the disclosure.

[0028] The computer system 410 may also include a display controller 465 coupled to the system bus 421 to control a display or monitor 466, such as a cathode ray tube (CRT) or liquid crystal display (LCD), for displaying information to a computer user. The computer system includes a user input interface 460 and one or more input devices, such as a user terminal 461 , which may include a keyboard, touchscreen, tablet and/or a pointing device, for interacting with a computer user and providing information to the processors 420. The display 466 may provide a touch screen interface which allows input to supplement or replace the communication of direction information and command selections by the user terminal device 461. [0029] The computer system 410 may perform a portion or all of the processing steps of embodiments of the invention in response to the processors 420 executing one or more sequences of one or more instructions contained in a memory, such as the system memory 430 Such instructions may be read into the system memory 430 from another computer readable medium, such as the magnetic hard disk 441 or the removable media drive 442. The magnetic hard disk 441 may contain one or more data stores and data files used by embodiments of the present invention. The data store may include, but are not limited to, databases (e.g., relational, object-oriented, etc.), file systems, flat files, distributed data stores in which data is stored on more than one node of a computer network, peer-to-peer network data stores, or the like. The processors 420 may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory 430. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0030] As stated above, the computer system 410 may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the invention and for containing data structures, tables, records, or other data described herein. The term“computer readable medium” as used herein refers to any medium that participates in providing instructions to the processors 420 for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk 441 or removable media drive 442. Non-iimiting examples of volatile media include dynamic memory, such as system memory 430. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus 421. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0031] Computer readable medium instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (iSA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server in the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider) in some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0032] Aspects of the present disclosure are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, may be implemented by computer readable medium instructions.

[0033] The computing environment 400 may further include the computer system 410 operating in a networked environment using logical connections to one or more remote computers, such as remote computing device 480. The network interface 470 may enable communication, for example, with other remote devices 480 or systems and/or the storage devices 441 , 442 via the network 471. Remote computing device 480 may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system 410. When used in a networking environment, computer system 410 may include modem 472 for establishing communications over a network 471 , such as the Internet Modem 472 may be connected to system bus 421 via user network interface 470, or via another appropriate mechanism.

[0034] Network 471 may be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or series of connections, a cellular telephone network, or any other network or medium capable of facilitating communication between computer system 410 and other computers (e.g., remote computing device 480). The network 471 may be wired, wireless or a combination thereof. Wired connections may be implemented using Ethernet, Universal Serial Bus (USB), RJ-6, or any other wired connection generally known in the art. Wireless connections may be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellite or any other wireless connection methodology generally known in the art. Additionally, several networks may work alone or in communication with each other to facilitate communication in the network 471.

[0035] It should be appreciated that the program modules, applications, computer- executable instructions, code, or the like depicted in FIG. 4 as being stored in the system memory 430 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming interface(s) (AP!(s)), or any other suitable computer-executable code hosted locally on the computer system 410, the remote device 480, and/or hosted on other computing device(s) accessible via one or more of the network(s) 471 , may be provided to support functionality provided by the program modules, applications, or computer-executable code depicted in FIG. 4 and/or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules depicted in FIG. 4 may be performed by a fewer or greater number of modules, or functionality described as being supported by any pariicular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices in accordance with any suitable computing model such as, for example, a client-server model, a peer- to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 4 may be implemented, at least partially, in hardware and/or firmware across any number of devices.

[0036] An executable application, as used herein, comprises code or machine readable instructions for conditioning the processor to implement predetermined functions, such as those of an operating system, a context data acquisition system or other information processing system, for example, in response to user command or input. An executable procedure is a segment of code or machine readable instruction, sub-routine, or other distinct section of code or portion of an executable application for performing one or more particular processes. These processes may include receiving input data and/or parameters, performing operations on received input data and/or performing functions in response to received input parameters, and providing resulting output data and/or parameters.

[0037] The functions and process steps herein may be performed automatically or wholly or partially in response to user command. An activity (including a step) performed automatically is performed in response to one or more executable instructions or device operation without user direct initiation of the activity.

[0038] The system and processes of the figures are not exclusive. Other systems, processes and menus may be derived in accordance with the principles of the invention to accomplish the same objectives. Although this invention has been described with reference to particular embodiments, it is to be understood that the embodiments and variations shown and described herein are for illustration purposes only. Modifications to the current design may be implemented by those skilled in the art, without departing from the scope of the invention. As described herein, the various systems, subsystems, agents, managers and processes can be implemented using hardware components, software components, and/or combinations thereof. No claim element herein is to be construed under the provisions of 35 U.S.C. 1 12(f), unless the element is expressly recited using the phrase“means for.”

Claims

What is claimed is:

1. A system for automatic generation of a server based on a graphical knowledge model, comprising:

at least one storage device storing computer-executable instructions configured as one or more modules; and

at least one processor configured to access the at least one storage device and execute the instructions, wherein the modules comprise:

a translator configured to perform a structure translation of the graphical knowledge model of a physical component in an autonomous system to instances of an Open Platform Communications (OPC) Unified Architecture (UA) model by parsing implicit semantics of the knowledge model, and applying heuristic mapping of elements of knowledge model instances to attributes and references of the OPC UA model, wherein the mapping to an attribute is based on a knowledge model element containing a literal; and

a synthesizer configured to synthesize code to expose OPC UA instances in a server by matching the instances with instance implementations stored in a library and creating an object or class for each instance implementation.

2. The system of claim 1 , wherein the elements of the knowledge model include subject-object-predicate triples, and the translator performs the structure translation by applying heuristic mapping of predicates to references of the OPC UA instances.

3. The system of claim 1 , wherein the elements of the knowledge model include subject-object-predicate triples, and the translator identifies the object as containing a literal, and the translator maps the object to an OPC attribute.

4. The system of claim 3, wherein the translator directly identifies the literal in the object by identifying the data type for the knowledge model instance.

5. The system of claim 3, wherein the translator identifies the literal in the object based on a position of the knowledge model instance within the graph of the knowledge model

6. The system of claim 1 , wherein the elements of the knowledge model include subject-object-predicate triples, and the translator determines that the object does not contain a literal and responsive to absence of the literal, the translator maps the object to an OPC reference or an OPC array reference based on cardinality of relationship for the knowledge model instance.

7. The system of claim 1 , wherein the synthesizer is further configured to generate a client configured to communicate with the server by transmitting request messages and receiving response message for data and control information related to the physical component.

8. A method for automatic generation of a server based on a graphical knowledge model, comprising:

performing a structure translation of a knowledge model of the graphical physical component in an autonomous system to instances of an Open Platform Communications (OPC) Unified Architecture (UA) model by parsing implicit semantics of the knowledge model, and applying heuristic mapping of elements of knowledge model instances to attributes and references of the OPC UA model, wherein the mapping to an attribute is based on a knowledge model element containing a literal; and

synthesizing code to expose OPC UA instances in a server by matching the instances with instance implementations stored in a library and creating an object or class for each instance implementation.

9. The method of claim 8, wherein the elements of the knowledge model include subject-object-predicate triples, and the translator performs the structure translation by applying heuristic mapping of predicates to references of the OPC UA instances.

10. The method of claim 8, wherein the elements of the knowledge model include subject-object-predicate triples, further comprising identifying the object as containing a literal, and mapping the object to an OPC attribute.

1 1. The method of claim 10, wherein the literal is directly identified in the object by identifying the data type for the knowledge model instance.

12. The method of claim 10, wherein the literal is identified in the object based on a position of the knowledge model instance within the graph of the knowledge model.

13. The method of claim 8, wherein the elements of the knowledge model include subject-object-predicate triples, further comprising determining that the object does not contain a iiteral and responsive to absence of the literal, mapping the object to an OPC reference or an OPC array reference based on cardinality of relationship for the knowledge model instance.