WO2016038203A1 - Kommunikation zwischen netzwerkknoten mittels skripten - Google Patents

Kommunikation zwischen netzwerkknoten mittels skripten Download PDF

Info

Publication number
WO2016038203A1
WO2016038203A1 PCT/EP2015/070878 EP2015070878W WO2016038203A1 WO 2016038203 A1 WO2016038203 A1 WO 2016038203A1 EP 2015070878 W EP2015070878 W EP 2015070878W WO 2016038203 A1 WO2016038203 A1 WO 2016038203A1
Authority
WO
WIPO (PCT)
Prior art keywords
script
network node
node
function
nodes
Prior art date
Application number
PCT/EP2015/070878
Other languages
English (en)
French (fr)
Inventor
Carsten Moellers
Original Assignee
Nogs Gmbh
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nogs Gmbh filed Critical Nogs Gmbh
Publication of WO2016038203A1 publication Critical patent/WO2016038203A1/de

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/2807—Exchanging configuration information on appliance services in a home automation network
    • H04L12/2814—Exchanging control software or macros for controlling appliance services in a home automation network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/2803—Home automation networks
    • H04L12/283—Processing of data at an internetworking point of a home automation network
    • H04L12/2832—Interconnection of the control functionalities between home networks

Definitions

  • the invention relates to a method for controlling a network node, a system having a plurality of network nodes and a single network node for use in such a system.
  • a network node is understood to be a single computer that can execute programs and communicate with other network nodes via a communication connection. At least some of the network nodes are constrained by constraints, in particular with regard to power consumption, size and costs (constrained environments), so that correspondingly limited computing power and memory sizes are available.
  • the network nodes or the entire networks formed therefrom preferably form embedded systems. They can be used, for example, in the field of automation for carrying out monitoring, control or regulating functions. Such network nodes and networks formed therefrom are known, for example, in the form of wireless sensor networks.
  • US 2010/0205596 Ai describes a wireless sensor network having a number of sensor nodes which are each capable of detecting information for recognizing objects or information about environmental conditions and transmitting them in real time over a network.
  • a gateway transmits renewed firmware via an RS232C interface to a node which is forwarded sequentially to a plurality of nodes.
  • the respective nodes store the firmware in memory and reboot, with boot programs executing the renewed firmware.
  • US 8,204,971 B2 describes systems and methods for controlling sensor networks having a plurality of sensor nodes having sensors for monitoring operating parameters and wireless communication modules.
  • a user can be simple To dynamically configure or reconfigure the behavior of each network node without having physical access to the node.
  • a coordinator network node may coordinate or control various aspects of the network, for example, instructing a sensor node to enable a relay in response to a particular event.
  • the coordinator node is connected to a host.
  • the host configures the coordinator node according to the intended use of the network.
  • Part of the coordinator node logic may be implemented by one or more scripts that can be executed without compilation. For example. One of the scripts can be used to respond to a specific event.
  • scripts are downloaded from the coordinator node. For example.
  • a user may download a script that, when executed, allows the coordinator node to control an aspect of the network.
  • the user can also specify when to run the script.
  • Each of the sensor nodes can be configured by the coordinator node.
  • the coordinator node can transmit scripts and / or data.
  • the user can submit new scripts to the coordinator node from a central location without physical access to the nodes via the host. If desired, scripts can be sent to the sensor nodes and executed there.
  • a wireless network includes a plurality of nodes. By creating and uploading scripts to different nodes, a user can dynamically reconfigure the network.
  • Each node of the network includes a network stack and a virtual machine.
  • the virtual machine is implemented as a bytecode interpreter.
  • a script image includes byte-code executable by the virtual machine.
  • the core functions of a network node are written in the C language and the script image is written in the Python language.
  • US 2013/0123948 Ai describes an automation system. Components can open Access state information of multiple objects. If status information is changed, the changes can be transferred to a monitoring system. To avoid bandwidth issues in the complete transmission of state information, a distributed data model with local copies of data is used. For state changes delta scripts are transmitted. Components of the system may include local execution units. Delta scripts contain changed state elements as CRUD data (create, update and / or delete). When using delta scripts, copies of the state information are changed.
  • US 2006/0282498 Ai discloses a system and method for data processing in sensor networks with network nodes. Information observed by a sensor node is transmitted as events to a higher node.
  • a script for a lower-level node is extracted by a higher node in order to distribute it to the lower-level node and to execute it there.
  • an event is sent from a sensor node via an intermediate node to a client node.
  • the user is given a script and executed by a script manager.
  • the script contains subcripts that define the handling of events in child nodes.
  • a script manager executes the script, the part scripts are extracted and sent to subsequent nodes for execution.
  • the execution of scripts is carried out according to a tree structure in the manner of a functional language by an interpreter system.
  • US 2014/0142963 relates to a system for collecting, consolidating, distributing, storing and displaying medical data using mobile phone platforms and non-proprietary hardware and software modules.
  • Detection devices are coupled to sensor devices via wireless or wired connections.
  • Data is sent as encrypted messages in which a header is an executable program in a standardized script language such as Lua.
  • Lua standardized script language
  • the first aspect of the invention differs (claims 1, 7 and 11) in that a network node is not transmitted a complete function script that overwrites and replaces a previous function script, but that a script Fragment, d. H. a part of a function script is transmitted, which modifies an existing function script during its runtime.
  • the transmission of a script takes place upon the performance of a monitoring, control or regulating function, namely in dependence on a sensor value.
  • scripts thus proposed differs significantly from the transmission of scripts for the configuration of a system in a configuration phase and can be used in particular during the operating phase of the system.
  • the two aspects of the invention can be advantageously combined with each other.
  • each network node represents a stand-alone computer with memory, central processing unit and communication interface and optionally with coupling to a sensor and / or actuator.
  • the network nodes are preferably spatially distributed, that is arranged at a distance.
  • the communication connection is preferably a wireless or wired digital data connection according to any protocol.
  • the first network node executes a function script.
  • a function script which defines the function of the first network node, for example in the form of a control, regulation or monitoring function, ie particularly preferably the processing of input values (for example sensor values) and output of output values (for example for the activation of a Actuator).
  • the function script defines the function of the first network node in the operating phase of the system, i. H. if - depending on the purpose - the respective control, control or monitoring function is executed.
  • the function script is written in a script language and is executed by the first network node, for example by means of an interpreter or real-time compiler (just-in-time compiler).
  • An interpreter is understood to mean a functionality implemented by a program that executes script commands, be it as source text or in token form, by being read in at runtime. As is known to the person skilled in the art, this can include various individual program elements and individual steps, for example a tokenizer, with which the script source code is first converted into tokens, which are subsequently executed.
  • the most diverse script languages and for this purpose provided in the node execution means eg interpreter, JIT compiler
  • complex scripts are understood as meaning those scripts which contain complex language constructs such as, for example, function calls and in particular loops.
  • at least the first network node comprises means for executing complex scripts, in particular with the possibility of executing loops.
  • the execution means Turing machines are particularly preferred.
  • the second network node transmits a script fragment to it in the operating phase, that is to say during the execution of the function script at the first network node.
  • a script fragment may be a single script command or a group of script commands, for example script commands for defining one or more invocable functions (the term "invocable function" in this context referring to use in programming languages, Thus, predefined command sequences, which if necessary are called with parameters and can provide one or more return values.)
  • the script fragment is used to modify the function script of the first network node, for example, it can supplement this but also overwrite it in parts or parts thereof
  • the modification can be carried out by the first network node executing the script fragment, whereupon the latter makes the modification, or the modification can also take place in other ways, for example by a higher-level operating program of the first network node, which automatically executes the script Fragment adds to the function script bz w. carrying out the modification.
  • the function script is modified during its runtime by the script fragment. As explained above, no complete replacement takes place, but the function script preferably remains unchanged except for the modification made and continues to run.
  • the modification according to the invention at runtime allows control functions to be executed by the script fragment, that is, for example, the transmission of values, control commands etc.
  • the script fragments can thus be used so that they do not have the purpose of a one-time or occasional (Um-) configuration, but are part of the actual function of the entire system at runtime during the operating phase.
  • a switching function on the first network node can be triggered by the second network node transmitting a script fragment that modifies the function script of the first network node so that the switching function is executed.
  • the modification of the function script is performed such that the script fragment defines an invocable function which is called by the function script.
  • the script fragment can, for example, consist of the callable function itself, so that an installation routine at the first network node after receipt of the script fragment installs the function thus defined, ie makes it available.
  • an implementation in which the script fragment is executed directly by the first network node and thereby leads to the provision of the callable function is particularly preferred.
  • a special installation routine on the part of the first network node is not necessary, but the first network node simply executes the respective code transmitted by other network nodes, in the present context, the script fragment.
  • the transmission of a script fragment can be used particularly well and flexibly to signal sensor values, values derived therefrom or events based thereon (for example exceeding or falling below a threshold) via the network.
  • the second network node is connected to at least one sensor for a physical variable.
  • the script fragment can now be created as a function of at least one value supplied by the sensor, for example automatically generated or selected from a number of predefined script fragments.
  • control and regulation functions are particularly easy to implement.
  • the second network node can read out the sensor value and generate a script or script fragment containing the sensor value thus read.
  • the generated script or script fragment can also provide for further processing of the value, for example calculating a value dependent on one or more sensor values, checking the value for overshoot or undershoot of a threshold and triggering actions or making control specifications depending on the results thereof.
  • the script or script fragment generated in this way preferably only comes to execution there after being transmitted to the first network node.
  • the basic idea of creating or selecting a script may depend on sensor values and transmission of the script to another network node for execution also generally, regardless of the use of script fragments, provide significant advantages in terms of flexibility and configurability of a system.
  • a system analogous to the first aspect comprises two or more network nodes, or these network nodes are used in a control method.
  • at least one of the network nodes is connected according to the invention to a sensor for a physical variable.
  • a script is provided at the second network node. This can be done, for example, by automatically generating the script.
  • the generation of a script can be carried out, for example, on the basis of one or more script templates, in which placeholder the sensor value or values or instructions dependent on the sensor value are used.
  • the script may be provided by selecting from among a number of existing scripts, the selection depending on the sensor value.
  • the provision of the script can also be done by retrieving a script over the network, i. H. from another network object, as long as this is done depending on the sensor value.
  • the script thus provided depends on the sensor value, i. H. it may, for example, contain the sensor value or a value derived therefrom, or else make different control specifications depending on the sensor value.
  • the script can be a comprehensive function script, as well as a single script function call or a script fragment to modify a function script.
  • the script thus provided is transmitted to the first network node and executed there.
  • control and regulation functions can be carried out in a very advantageously flexible manner by the transmission and remote execution of scripts which depend on at least one sensor value.
  • the system or method comprises an actuator sensor node, which is connected to at least one actuator for specifying a physical quantity and is provided for the activation of the actuator.
  • the actuator sensor node can be one of the sensor nodes of the systems according to both aspects of the invention as described above, ie both the first and second network nodes described there can assume the role of such an actuator sensor node.
  • the actuator sensor node may be an additional sensor node of the system.
  • the activation of the actuator sensor node is carried out according to the development in that of another sensor node (again, this may be one of the nodes already described above or alternatively an additional node) a script (this includes full function scripts, script fragments or even single script function calls) is transmitted. This script is executed on the actuator sensor node. When the script is executed, the actuator is activated.
  • scripts In contrast to the transmission of simple default values or individual commands, the use of scripts allows a very flexible control, for example, depending on the design of the script, also conditional controls (if-then statements), repeated controls (loops), communication with other network nodes, etc ..
  • conditional controls if-then statements
  • repeated controls loops
  • communication with other network nodes etc .
  • no dedicated software is required for the control on the actuator sensor node, but this is transmitted in the form of the control script from another network node, which enables a dynamic configuration.
  • a network node may send a first (outer) script to a mediator network node (Here again, the term script covers all executable scripts including script fragments and individual script function calls.)
  • the intermediary network node is also involved, ie each of the above-described network nodes or an additional network node can take on this role executes the first (outer) script, which is constructed to pass a second (inner) script to another network node when executed.
  • the concept of "nesting” can be used flexibly, in particular in order to reach one or more further network nodes with the intermediary of the intermediary network node, for example, the first (outer) script can be designed such that, when it is executed, several second (inner) scripts are used. Similarly, the target or the contents of the second script may be subject to conditions that are checked during execution of the first (outer) script.
  • the nesting concept offers special advantages in overcoming protocol limits. If the first script is transmitted via a communication connection to a first communication protocol and the second script via a communication connection to a second, different communication protocol, a multi-protocol capability can be easily achieved with the help of such embedded scripts.
  • a general idea of the methods and systems presented here which can be used for both aspects of the invention, but can also be used separately, is the subdivision of network nodes into different node classes with different performance.
  • Preferred node classes may be defined as Smart Nodes, Clever Nodes and Primitive Nodes. Network nodes of these three node classes are each capable of executing scripts or at least individual script commands or script function calls.
  • Network nodes of a completely different type without the ability to execute scripts or script function calls, may additionally be present as alien nodes which, for example, can be addressed via a gateway.
  • each system comprises one or more network nodes of each of the three classes (Smart Nodes, Clever Nodes, Primitive Nodes).
  • Primitive nodes have the ability to execute individual script commands in the form of a single script function call. You can not execute complex scripts, for example, no loops, function definitions, etc. Primitive nodes can, for example, only have a single-line interpreter for executing individual function calls.
  • Clever nodes are distinguished by the ability to execute complex scripts. For this purpose, an interpreter or real-time compiler (JIT, just-in-time compiler) is present on Clever Nodes, preferably as a virtual machine. Clever Nodes have no graphical user interface, but at most have non-graphical output options, such as a text console.
  • JIT just-in-time compiler
  • GUI graphical user interface
  • the node classes differ with regard to the performance of the selected hardware, that is, for example, computing power and memory size.
  • Smart Nodes have i.d.R. about high computing power and memory size.
  • Clever Nodes usually have limited computing power and memory size. Primitive nodes can already be realized with low computing power and memory size.
  • the hardware used in a particular system is selected on the basis of the required information and given framework conditions (in particular costs, size, power consumption) so that they are sufficiently dimensioned for the respective intended use within the system, but not significantly oversized as far as possible.
  • smart nodes may be used in particular for user interaction.
  • a smart node can be used as the configuration system.
  • primitive nodes can, for example, be used for the direct control of an actuator or for reading out a sensor.
  • Clever Nodes which, by virtue of their ability to execute and transmit scripts, can represent the actual distributed intelligence of the system in the operational phase, but in contrast to Smart Nodes, they can be realized under close conditions. They are therefore versatile and possibly also usable in larger numbers, for example for control, regulation or monitoring tasks.
  • Fig. 1 is a schematic representation of a first example of a system of network nodes for controlling a heating element
  • FIG. 2 shows a schematic illustration of a network node of the node class Clever
  • FIG. 3 is a schematic representation of a software layer structure of the network node of FIG. 2;
  • FIG. 4 is a schematic representation of a second example of a system of network nodes with a configuration system in a configuration phase
  • Fig. 5 is a schematic representation of a screen display of the configuration system of Fig. 4;
  • FIG. 6 is a schematic representation of the system of FIG. 4 in an operating phase
  • Fig. 7 is a schematic representation of a third example of a system of network nodes having communication links with different communication protocols
  • FIG. 8 is a schematic representation of a system for configuring a network node of the system of FIG. 1.
  • Each network node is an independent computer and can be realized depending on the task and given conditions on very different hardware, for example, as an FPGA or single-chip system (system-on-chip, SoC).
  • each network node has a memory 12, which usually comprises volatile (RAM) memory and nonvolatile memory (eg ROM and / or flash memory) and for storing data and / or or programs is used.
  • a central unit 14 is provided for executing programs and may include one or more microprocessors, microcontrollers, signal processors, etc.
  • a network interface 16 enables digital network communication with other network nodes, wherein a variety of interface types, communication media (wired, wireless) and transmission paths and communication protocols can be used.
  • each network node has a power supply 18 (shown here symbolically in the form of a battery, depending on the design, in addition to or instead of a battery or a rechargeable accumulator, a network connection or any other energy source such as means for energy harvesting can be used, for example, a solar cell, a piezo element, a thermal element, etc. with a storage facility for the collected energy), with which the components of the network node are supplied with electrical power.
  • each network node can have one or more further interfaces 20, for example for direct connection to sensors and / or actuators.
  • the systems discussed here preferably form cyber-physical systems, ie a combination of information technology components with mechanical and electronic parts that communicate via a data infrastructure.
  • Such cyber-physical systems are currently in intensive exploration and development. Like cyber-physical systems in general, the systems presented here can also be used to advantage in applications such as medical devices and systems, age-appropriate assistance systems, traffic control and traffic logistics, automotive safety and assistance systems, industrial process controls, environmental management and monitoring systems, energy supply management systems, military System networking systems and communication infrastructure.
  • Sensors connected to network nodes can be used to detect a physical quantity. This may refer to environmental conditions, so for example. On pressure, brightness, temperature, etc., as well as on monitored devices, devices and systems where, for example. Operating parameters such as speed, rotation or displacement position, speed, etc. using a Sensors can be monitored. Actuators, on the other hand, serve to influence or prescribe physical quantities. The control is preferably carried out initially electrically, which then directly or indirectly by the actuator a control function of any kind, so for example. Mechanical or electrical, can be performed. Accordingly, actuators can, for example, include electrical driver and driver circuits for any electrical equipment and devices, but also controls for control valves, solenoids, motors, heating elements, lights, relays etc ..
  • the systems presented herein may be used in a variety of fields of technology, although use in automation is particularly preferred. Therefore, the systems preferably comprise at least one, usually several sensors and at least one, usually several actuators. Each of the sensors or actuators is preferably directly coupled to at least one of the network nodes, z. Such a direct coupling is also present when the sensor or actuator is integrated directly into the hardware or, for example, in the housing of a network node.
  • automation refers on the one hand to fields such as building and factory automation, eg functionalities such as heating control, lighting control, control and regulation of machines and plants, control and regulation of distribution networks (smart grids) etc.
  • automation but in addition to classical control, regulation and monitoring tasks also logistical processes affect, so for example, the goods traffic in a company, controlling a group of vehicles, etc ..
  • FIG. 1 shows, by way of example, a network 30 with four network nodes 32, 34, 36, 38 that can be used for automation, namely in this example a control of a heating element.
  • the network nodes are to be divided into different classes of nodes.
  • a smart node has the ability to execute complex scripts, ie an interpreter or just-in-time compiler, preferably a virtual machine, eg a Lua virtual machine for the scripting language Lua.
  • complex scripts differ, for example, from individual instructions or script function calls, which do not require a complete interpreter, but can be executed with a much simpler single-line interpreter
  • Complex scripts comprise at least one complex language element of the script language used, such as Loops and / or the definition of executable functions.
  • GUI graphical user interface
  • a smart node 32 can therefore have any desired high computing power and memory size.
  • this can be a notebook or desktop computer as well as other fully-featured commercial computers, a tablet or smart phone, or, for example, a dedicated control computer.
  • a smart node may be equipped with at least one multi-core processor and 1GB or more of memory.
  • the network node 32 of the node class Smart Node is used by a user to configure and visualize the behavior of the remaining nodes.
  • the network nodes 34 and 36 belong to the class of Clever Nodes.
  • This node class is functionally defined by the fact that the associated network nodes have means for executing complex scripts, for example an interpreter or JIT compiler (preferably as a virtual machine), but without a graphical user interface.
  • Clever nodes can do without a user interface or allow a non-graphical output, such as a text console.
  • Clever Nodes can be realized in any hardware, the o.g. Functions supported. Due to the limitations of power consumption, size and / or cost, Clever Nodes i.d.R. have lower processing power and memory than the Smart Nodes class. For example, a clever node may be equipped with a single or multi-core processor and may have a memory of, for example, 512 kb to typically less than 1 gb. For example, hardware available today can be equipped with microprocessors of the performance class of an ARM Cortex-M4 or M3.
  • primitive nodes to which the network node 38 belongs also has no graphical user interface. Even primitive nodes have a memory and microprocessor, but can not complete scripts, but with the help of a Single Line Interpreter execute only single script function calls, again preferred in Lua.
  • primitive nodes can comply with very narrow framework conditions, ie be realized on low-end hardware. From hardware available today, the central unit of a primitive node could be, for example, an Atmel AVR ATmega or comparable processor.
  • FIG. 3 schematically shows the layers of the software architecture of a Clever Node network node.
  • the lowest layer forms the hardware 40, on which a runtime system 41 first runs.
  • the runtime system 41 includes standard system routines such as memory management, interrupt handling, etc., as well as an interpreter (or alternatively just-in-time compiler) for a scripting language, preferably Lua here, preferably using a Lua virtual machine.
  • a system layer 42 which can be implemented as a library of callable functions, is set up on the runtime system.
  • the system layer 42 can be present as a machine code, for example as a compiled C program, at least partially but also in the form of scripts.
  • a hardware abstraction layer HAL 44 is set up, which in the preferred example is programmed in Lua or another chosen scripting language and executed on the interpreter.
  • the hardware abstraction layer HAL 44 serves to decouple the application layer 46 (application layer) based thereon from the actually existing hardware 40 in such a way that it can be addressed via standard calls, without the respective application being specific to the respectively existing hardware must be adjusted.
  • the networks discussed here may comprise in principle any number of network nodes of the different node classes.
  • network nodes of each node class it is not necessary that there are always network nodes of each node class.
  • other types of network nodes without the ability to execute scripts may also be part of the network, which are then grouped together in a node class of alien nodes.
  • the individual network nodes are usually spatially distributed, ie they are each at a distance from each other, but it is also possible in individual cases, that two or more network nodes next to each other, for example. In the same switching cabinet are arranged.
  • the nodes are coupled to each other by a digital data connection as a communication link, although not necessarily all data connections of the different nodes must be of the same type. Likewise, there need not be a direct connection between all pairs of nodes, but such may also be formed by averaging over one or more intermediate nodes.
  • Possible forms of the communication connection between network nodes can, for example, be wired, for example For example, as an Ethernet network or in the form of a serial interface, for example. RS-232, RS-422 etc ..
  • the network nodes can wirelessly communicate with each other, such as, for example, wireless sensor networks (Wireless Sensor Networks) is known. Possible wireless data connections include protocols such as Bluetooth, Zigbee, Thread etc.
  • a special feature of the systems preferably presented here is that the data transmitted between the nodes is not transmitted as individual values or control commands as conventionally known, but rather in the form of executable scripts or script fragments.
  • the system formed by the nodes is very flexible.
  • a network node connected directly to a physical quantity sensor transmits a value supplied thereto to another network node
  • dedicated programming for processing the value is inevitably required on the receiving network node.
  • the communication between two nodes can take the form of a node transmitting an executable script, preferably in Lua, or a script fragment, or even just a single script function call to another network node.
  • the receiving network node executes the transmitting script.
  • the respectively supplied sensor value (or values derived therefrom, eg signals, when the sensor value reaches a predetermined threshold) can be transmitted in script form, so that after execution of the In the receiving node, the value is available to transfer scripts, and an optional statement is already executed Processing of the value.
  • a sensor functionality with signaling in the form of a script can be carried out, wherein the script can be generated, for example, within the sending, with the sensor connected network node, for. For example, from a script template that still has values in it, or the script can be selected from a number of pre-saved scripts or script templates.
  • the activation of an actuator can also be effected by transmitting a script.
  • a control command for example, on / off
  • a control value for example: rotational speed
  • the systems presented here enable the control by means of an executable script, which is transmitted via the communication link and executed in the relevant network node and thereby causes the activation of the actuator.
  • a script is transmitted, which specifies the speed when running accordingly.
  • the parameters of the control can, for example, be fixed (that is to say, for example, as constants) in the script, or calculated or retrieved by it.
  • the primitive node network node 38 is connected to an actuator, in this example a drive of a heating element 48.
  • the Clever Node network node 34 is connected to a sensor, in this case a switch 50, which can be operated by a user.
  • the Clever Node network node 36 is connected to two sensors, in the example shown a brightness sensor 52 and a humidity sensor 54.
  • the system 30 is intended to be used by way of example for heating control, namely for controlling the heating element 48 as a function of the operation of the switch 50 and in dependence on the environmental conditions of the room brightness and air humidity detected by the sensors 52, 54.
  • the communication between the network nodes takes the form of the transmission of Lua scripts, be it as complete function scripts, script fragments or individual script function calls.
  • the configuration of the system behavior ie, in particular, the function according to which the heating power output by the heating element 48 or the resulting temperature is to be controlled as a function of the values supplied by the sensors 50, 52, 54 is specified by the smart node network node 32 in the form of a script 56 in that in this case the Clever Node network node 36 is transmitted.
  • the Clever Node network node 36 polls the sensors 52, 54, and transmits a drive value in response to the supplied values as instructed by the script 56.
  • control value is not transmitted as such, but in the form of a script 58 to the Clever Node network node 34.
  • the script 58 which is explained in more detail below in this example, is a script fragment, is generated within the Clever Node network node 36 starting from a script template.
  • the Clever Node network node 34 executes a function script 60 which queries the position of the switch 50.
  • the function script 60 is supplemented at runtime by the script fragment 58, as explained in more detail below.
  • a drive value for the heating element 48 is determined on further execution.
  • the heating element is driven by the primitive node network node 38.
  • the control value from the clever node network node 34 at the primitive node network node 38 is not transmitted as a pure value, but again in script form, in this case as a single script function call 62.
  • the script function call 62 is executed by the single line interpreter on the primitive node network node 38, thus driving the heating element 48.
  • the script 56 transmitted from the smart node network node 32 to the clever node network node 36 may be, for example, in Lua code as follows: join.attach (FIG.
  • the placeholder indicated above with ... corresponds to a function or calculation rule with which a temperature value is returned from values for light and moisture.
  • the script transmitted by the smart node network node 32 is executed by the Clever Node network node 36 after transmission.
  • the callable function LightAndHumidtyToTemp contained therein is not executed directly, but initially installed. This function can then be called in the context of the function script executed on the Clever Node network node 36.
  • the function script executed by the Clever Node network node 36 could, for example, be defined as follows:
  • This script first assigns the value to the variable t, which is calculated by calling the installed callable function LightAndHumidtyToTemp with transfer of the sensor values of the sensors 52, 54 as a parameter.
  • the sensors 52, 54 are doing by the Hardware abstraction layer HAL addressed (hal.getLight ()).
  • the script fragment 58 is first stored in a string variable with the designation "code.”
  • the script fragment 58 thereby defines the callable function GetTemp , wherein the return parameter of this invocational function is fixed by the previously calculated value and inserted in text form into the script fragment 58.
  • the command join.attach (code) transmits the script fragment thus formed to the Clever Node network node 34 and Then, in the Clever Node network node 34, the function GetTemp is installed as defined above.
  • the hal.setTemp function is first defined, in which depends from the passed parameter t, a single Lua function call can be generated as a string called "code" and handed over to the Primitive Node network node 38 for execution by means of join.send.Further, the switch event is triggered by switching the switch 50
  • Function OnSwitchEvent defines, which calls the function hal.setTemp with the parameter (o) when the switch is switched off to switch off the heating element or in the case of the switch on calls the function GetTemp installed by the script fragment 58 and the resulting values via hal.setTemp is communicated to the Primitive Node network node 38.
  • the respectively transmitted script function call Temp.set () is executed with the parameter specified therein and thus the activation of the heating element 48 is carried out accordingly.
  • the system 30 thus performs a control function in which the heating element 48 in response to the sensors 52, 54 and the switch 50 (which is also a sensor) with different drive values (t) is operated or turned off and on.
  • this functionality is achieved by always transmitting scripts between the network nodes. By changing the scripts, the control behavior is dynamically adaptable, even during operation.
  • the system proves to be particularly robust because there is no central control, but the respective functions are distributed decentralized to the nodes.
  • the Smart Node network node 32 after he has once configured the script 56 with specification of the function LightAndHumidtyToTemp, initially no longer needed. During runtime of the scheme, the smart node network node 32 need not be active, but it may be used to reconfigure the system, for example, by passing a modified LightAndHumidtyToTemp function to the Clever Node network node 36 to change system behavior.
  • the system 30 can be easily dynamically reconfigured by the illustrated use of scripts. For example. Through the smart node network node 32, a changed function script can be transmitted to each of the network nodes. So the system is very easily adaptable to changing requirements.
  • Fig. 4 shows a second example of a system 70 having a number of network nodes.
  • a smart node 72 as a configuration system and two clever nodes 74, 76 are provided, of which the first Clever Node network node 74 to an actuator (driver circuit for the heating element 75) and the second Clever Node network node 76 to a sensor (Switch 78) is connected.
  • the smart node network node 72 is needed only in a configuration phase.
  • the smart node network node 72 which has a graphical user interface GUI, may be used by a user to configure the system 70, i. H. to specify the behavior of the network nodes 74, 76 according to the desired automation task.
  • the function of the network nodes 74, 76 in the later operating phase is predefined by function scripts executed on the node as described above. It is now possible for the user to individually create the respective function scripts or to select predefined scripts on the configuration system, if necessary to adapt them and transmit them via the network connection to the network nodes for execution there. For this purpose, however, the user would first need information about the network nodes 74, 76 available in the system 70 and would have to manually make or adapt these for the subsequent programming of scripts in individual cases. The picking of the system 70 is simplified by the use of special scripts, here referred to as avatars.
  • An avatar script represents a network object, for example a single network node or a group of network nodes, and documents capabilities and / or properties of the network object, in particular preferably possible connections, ie possible outputs or reception possibilities for values or signals.
  • the avatar scripts are transmitted from the respective network object to the configuration system 72 and executed there and then enable the picking, so that subsequently the configuration system 72 sends function scripts to the respective network objects for execution in the subsequent operating phase.
  • the Clever Node network node 74 transmits an Avatar script 80 and the Clever Node network node 76 submits an Avatar script 82 to the configuration system 72.
  • the scripts in the preferred example are again Lua scripts which are executed on the configuration system 72.
  • Each avatar script represents and describes the respective network node and its properties and capabilities such that, for example, the avatar script 80 documents the capability of the Clever Node network node 74 to drive the heating element 75 and the avatar script 82 of the Clever Node network node 76 documents the Ability to interrogate the sensor 78.
  • the respective network nodes of the system 70 thus each log on as individual network objects to the configuration system 72 transmitting their avatar scripts so that a database of the available network objects and their respective properties, ports, etc. can be created in the configuration system 72.
  • the picking in the configuration system 72 can, for example, be carried out automatically on the basis of the database thus created, if the control or automation purpose makes this possible.
  • the database can also serve to support a user who carries out the picking on the configuration system on the basis of the respective desired automation task and the desired rule behavior.
  • the avatar scripts 80, 82 contain instructions for graphically representing the respective network objects, ie here the nodes 74, 76 on the GUI of the configuration system 72.
  • One possible screen output is shown by way of example in FIG.
  • the avatar script 80 of the actor network node 74 presents it graphically in the form of a heating element representation with a control input 84.
  • the avatar script 82 of the switch network node 76 displays this with a switch symbol and an output 86.
  • the system 70 (very simple in the illustrated example) may now be picked by the user. For example, a user may connect the output 86 to the input 84, as exemplified in FIG.
  • a script generator of the configuration system 72 automatically generates function scripts for the respective network nodes. Preference is given to an immediate processing by the script generator, so that user inputs are converted directly into a configuration of the current system (live coding).
  • the script generator automatically generates corresponding function scripts for the participating network nodes for the respective user-specified functionality.
  • the script generator interprets user inputs, in this case, for example, inputs on the graphical user interface, such as the connection of inputs and outputs, or other requirements, and converts these into one or more function or configuration scripts, here, for example the function script 88.
  • the sensor network node 76, a function script created in this way 88 is transmitted, which provides a control of the heating element 75 via the actuator network node 74 depending on the position of the switch 78.
  • a function script can also be transmitted to the actuator network node 74, but this is not necessary in the case of the very simple mode of operation shown here by way of example.
  • the user In order to store the respectively last configured configuration of a single network node 74, 76, but also of a system 70 with several network objects so that it can always be assumed in a new configuration of the previous configuration status, the user defaults (here: connection of the output 86 with the input 84) the participating network objects (here: network nodes 74, 76) transmitted to the local storage. This can be done, for example, in script form, i. The two network nodes 74, 76 each receive a script, with which the retain values are locally stored there.
  • each network object that already has a previous configuration stored locally as retain values will then send its respective avatar script 80, 82.
  • the retain values may be within the avatar script 80, 82 or in addition to this.
  • the avatar scripts 80, 82 they are put into a state corresponding to the previous configuration based on the retain values (i.e., the linkage of the output 86 to the input 84 is made in the following example).
  • the respective function scripts are executed on the network node, i. H. in the example shown, the function script 88 on the sensor network node 76.
  • the configuration system 72 is not needed in the operational phase, i. H. Communication taking place there can take place exclusively between the other network nodes 74, 76, which in this case are directly involved in the desired control function.
  • the function script 88 is designed such that the sensor network node 76 transmits a script 90 to the actuator network node 74 in the case of a switch operation (event), with the heating element 75 depending on the switching configuration - or is turned off.
  • the transmitted script 90 is executed on the actuator network node 74, so that the control function specified therein is also executed.
  • FIG. 7 shows a further example of a system 100 with three network nodes 102, 104, 106 of the node class Clever Node shown.
  • the network nodes 102, 104, 106 are not all connected to one another with the same communication connection, but there is a first communication connection 108 with a first communication protocol between the first network node 102 and an intermediary network node 104.
  • This first communication connection 108 can, for example. be a wired digital data transmission over an Ethernet connection.
  • a second communication connection 110 according to another protocol between the intermediary network node 104 and a further (destination) network node 106.
  • This may, for example, be a wired serial data transmission, for example according to the RS-485 protocol.
  • the first network node 102 is directly coupled to a sensor 112; the further network node 106 is connected to an actuator 114.
  • the system 100 In order to achieve control of the actuator 114 in response to a sensor value S of the sensor 112, the system 100 must be multi-protocol capable because there is no direct communication connection with only one communication protocol between the participating network nodes 102, 106.
  • This is solved by the concept of an embedded script, also referred to as nesting.
  • the first network node 102 is controlled by its function script so that it interrogates the sensor value S and generates in dependence on the sensor value S, a special script 116 for controlling the heating element.
  • This script also referred to as "outer”
  • This script also referred to as "outer”
  • Embedded in the outer script 116 is an inner script 118.
  • the embedding of the inner script 118 is thereby accomplished so that the outer script 116 assists its execution on the intermediary network node 104 generates the inner script 118 and sends it to the other, destination network node 106 for execution there.
  • the predetermined control function is executed.
  • the outer script 116 could be in JSON format
  • control behavior of the system 30 of FIG. 1 described above may be predefined on the GUI of a configuration system using an avatar script and a function script of the smart node network node 32, as well as optionally the respective function scripts of the network nodes 34, 36, 38, generated as automatically generated function scripts be transmitted to them for later execution.
  • 8 shows by way of example an additional smart node network node 33 as a configuration system for configuring the smart node network node 32.
  • the configuration system 33 has a touchscreen 35.
  • the network node 33 logs on to the configuration system by transmitting an avatar script 83.
  • This when executed on the touchscreen of the configuration system 33, represents the graph of the currently preset function LightAndHumidityTo-Temp and allows the user to change the curve shown by dragging on the touchscreen 35.
  • a corresponding configuration script 57 is transmitted to the smart node network node 32 (live coding).
  • the configuration script 57 installs a new function script 56 with a modified LightAndHumidityToTemp function.
  • the configuration script 57 can be generated, for example, from the graphical user specifications by approximation of the curve set by the user by means of splines.
  • Such a script contained in the avatar script 83 of the smart node network node 32 which in turn works as a script generator, could in basic features, for example, look like the following:
  • the specified hardware features of the Smart Node, Clever Node, and Primitive Node classes are exemplary in terms of hardware available today. With the future expected availability of hardware with higher computing power, larger memory equipment etc. with the same or lower requirements on size, power consumption and costs, the respective functions of the node classes can be realized in the future by other hardware. Therefore, the functional characteristics of the node classes are decisive.

Abstract

Die Erfindung betrifft ein Verfahren zur Steuerung eines Netzwerkknotens, ein System (30) mit mehreren Netzwerkknoten sowie einen einzelnen Netzwerkknoten zur Verwendung in einem solchen System. Gemäß einem Aspekt sind ein erster und zweiter Netzwerkknoten (34, 36) über eine Kommunikationsverbindung verbunden. Der erste Netzwerkknoten (34) führt ein Funktionsskript (60) aus. Der zweite Netzwerkknoten (36) übermittelt während der Ausführung des Funktionsskriptes (60) ein Skript-Fragment (58) zur Modifikation des Funktionsskriptes (60) an den ersten Netzwerkknoten (34). Während der Laufzeit des Funktionsskriptes (60) wird dieses durch das Skript-Fragment (58) modifiziert. Hierdurch kann ein sehr einfach konfigurierbares und dynamisch änderbares System erzielt werden, insbesondere für Automationsaufgaben. Gemäß einem weiteren Aspekt ist der zweite Netzwerkknoten (36) mit einem Sensor (52, 54) für eine physikalische Größe verbunden und generiert abhängig von einem von dem Sensor gelieferten Wert ein Skript (58), das an den ersten Netzwerkknoten (34) übermittelt wird. Der erste Netzwerkknoten (34) führt das Skript (58) aus. Dies erlaubt eine sehr flexible Programmierung des Systems, insbesondere für die Automatisierung.

Description

Beschreibung
Kommunikation zwischen Netzwerkknoten mittels Skripten
Die Erfindung betrifft ein Verfahren zur Steuerung eines Netzwerkknotens, ein System mit mehreren Netzwerkknoten sowie einen einzelnen Netzwerkknoten zur Verwendung in einem solchen System. Unter einem Netzwerkknoten wird dabei ein einzelner Rechner verstanden, der Programme ausführen und über eine Kommunikationsverbindung mit anderen Netzwerkknoten kommunizieren kann. Mindestens einzelne der Netzwerkknoten sind dabei durch Rahmenbedingungen insbesondere hinsichtlich Leistungsaufnahme, Baugröße und Kosten beschränkt (constrained environments), so dass entsprechend begrenzte Rechenleistung und Speicher- großen zur Verfügung stehen. Die Netzwerkknoten oder auch die gesamten hieraus gebildeten Netzwerke bilden bevorzugt eingebettete Systeme (embedded Systems). Sie können verwendet werden bspw. im Bereich der Automation zur Ausführung von Überwachungs-, Steuerungs- oder Regelfunktionen. Derartige Netzwerkknoten und hieraus gebildete Netzwerke sind bspw. bekannt in Form von drahtlosen Sensornetzwerken.
US 2010/0205596 Ai beschreibt ein drahtloses Sensornetzwerk mit einer Anzahl von Sensorknoten die jeweils dazu in der Lage sind, Informationen zur Erkennung von Objekten oder Informationen über Umgebungsbedingungen zu ermitteln und in Echtzeit über ein Netzwerk zu übermitteln. Um die Firmware der Knoten zu erneuern, überträgt ein Gateway erneuerte Firmware über eine RS232C-Schnittstelle an einen Knoten, die sequentiell an eine Mehrzahl von Knoten weitergeleitet wird. Die jeweiligen Knoten speichern die Firmware im Speicher und führen einen Neustart aus, wobei Boot-Programme die erneuerte Firm- wäre ausführen.
US 8,204,971 B2 beschreibt Systeme und Verfahren zur Steuerung von Sensornetzwerken mit einer Mehrzahl von Sensorknoten, die Sensoren zur Überwachung von Betriebsparametern und drahtlose Kommunikationsmodule aufweisen. Ein Benutzer kann auf einfache Weise dynamisch das Verhalten jedes Netzwerkknotens konfigurieren oder rekonfigurieren ohne physikalischen Zugriff auf den Knoten zu haben. Ein Koordinator-Netzwerkknoten kann verschiedene Aspekte des Netzwerks koordinieren oder steuern, bspw. einen Sensorknoten dazu anweisen, ein Relais in Abhängigkeit von einem bestimmten Ereignis zu akti- vieren. Der Koordinatorknoten ist mit einem Host verbunden. Der Host konfiguriert den Koordinatorknoten entsprechend der vorgesehenen Nutzung des Netzwerks. Ein Teil der Logik des Koordinatorknotens kann durch ein oder mehrere Skripte implementiert sein, die ohne Kompilierung ausgeführt werden können. Bspw. kann eines der Skripte verwendet werden, um auf ein bestimmtes Ereignis zu reagieren. In einer beispielhaften Ausführungs- form werden Skripte vom Koordinatorknoten heruntergeladen. Bspw. kann ein Benutzer ein Skript herunterladen, das bei Ausführung dem Koordinatorknoten ermöglicht, einen Aspekt des Netzwerks zu kontrollieren. Der Benutzer kann auch angeben, wann das Skript ausgeführt werden soll. Jeder der Sensorknoten kann vom Koordinatorknoten konfiguriert werden. Der Koordinatorknoten kann Skripte und/oder Daten übermitteln. Um das System zu rekonfigurieren, kann der Benutzer von einem zentralen Ort ohne physikalischen Zugriff auf die Knoten über den Host neue Skripte an den Koordinatorknoten übermitteln. Wenn gewünscht, können Skripte an die Sensorknoten übermittelt und dort ausgeführt werden.
Die US 8,438,250 beschreibt Systeme und Verfahren zur Erneuerung von Skript-Abbildern (script images) in drahtlosen Sensornetzwerken. Ein drahtloses Netzwerk umfasst eine Mehrzahl von Knoten. Durch das Erstellen und Hochladen von Skripten an verschiedene Knoten kann ein Benutzer das Netzwerk dynamisch rekonfigurieren. Jeder Knoten des Netzwerks umfasst einen Network Stack und eine virtuelle Maschine. In einem Beispiel ist die virtuelle Maschine als Bytecode Interpreter ausgeführt. Ein Script image umfasst durch die virtuelle Maschine ausführbaren Bytecode. Die Kernfunktionen eines Netzwerkknotens sind in der Sprache C geschrieben und das Script image ist in der Sprache Python geschrieben. Wenn ein Benutzer eine bestimmte Funktion ausführen möchte, kann er ein Quell- skript schreiben zur Ausführung durch einen Netzwerkknoten. Ein herkömmlicher Quellparser parst, kompiliert und tokenisiert das Quellskript, um ausführbaren Bytecode zu erzeugen.
Die US 2013/0123948 Ai beschreibt ein Automationssystem. Komponenten können auf Zustandsinformationen mehrerer Objekte zugreifen. Wenn Zustandsinformationen geändert werden, können die Änderungen an ein Monitoring-System übertragen werden. Um Bandbreitenproblemen bei der vollständigen Übertragung von Zustandsinformationen zu vermeiden, wird ein verteiltes Datenmodell mit lokalen Kopien von Daten verwendet. Bei Zustandsänderungen werden Delta-Skripte übertragen. Komponenten des Systems können lokale Ausführungseinheiten aufweisen. Delta-Skripte enthalten geänderte Zustandsele- mente als CRUD - Daten (create, update und/oder delete). Bei Anwendung von Delta- Skripten werden Kopien der Zustandsinformationen geändert. In der US 2006/0282498 Ai ist ein System und Verfahren zur Datenverarbeitung in Sensornetzwerken mit Netzwerkknoten offenbart. Informationen, die von einem Sensorknoten beobachtet werden, werden als Ereignisse an einen höheren Knoten übermittelt. Dabei wird von einem höheren Knoten ein Skript für einen niedriger angeordneten Knoten extrahiert, um dieses zum niedriger angeordneten Knoten zu verteilen und dort auszuführen. Basie- rend auf von jedem Knoten ausgeführten Skripten wird ein Ereignis von einem Sensorknoten über einen Zwischenknoten an einen Client-Knoten gesendet. Um den Ablauf des Betriebs festzulegen, wird vom Benutzer ein Skript vorgegeben und durch einen Skriptmanager ausgeführt. Das Skript enthält Teilskripte, die in untergeordneten Knoten die Behandlung von Ereignissen definieren. Wenn ein Skriptmanager das Skript ausführt, werden die Teilskripte extrahiert und an nachfolgende Knoten zur Ausführung übermittelt. Die Ausführung von Skripten erfolgt entsprechend einer Baumstruktur nach Art einer funktionalen Sprache durch ein Interpreter-System.
Die US 2014/0142963 betrifft ein System zur Erfassung, Konsolidierung, Verteilung, Spei- cherung und Darstellung von medizinischen Daten unter Verwendung von Mobiltelefon- Plattformen und nicht-proprietären Hardware- und Softwaremodulen. Erfassungsgeräte sind mit Sensorgeräten über drahtlose oder drahtgebundene Verbindungen gekoppelt. Daten werden als verschlüsselte Nachrichten gesendet, bei denen ein Header ein ausführbares Programm in einer standardisierten Skript-Sprache wie Lua ist. Wenn ein Empfänger eine Nachricht erhält, führt er das Programm aus um die Nachricht in lesbarer Form zu erhalten.
In dem Artikel„A Framework for Efficient and Programmable Sensor Networks" von A. Bo- ulis und M. B. Srivastava, Open Architectures and Network Programming Proceedings, 2002 IEEE, S. 117-128 ist eine Architektur für drahtlose Sensor-Netzwerke offenbart, die wesentli- chen Beschränkungen hinsichtlich Energieversorgung, Rechen - und Speicherkapazitäten und Bandbreite unterliegen. Eine Abfrage an das Netzwerk wird in Form eines Skriptes formuliert. Skripte können sich innerhalb des Netzwerkes von Knoten zu Knoten replizieren und Code sowie Daten migrieren. Eine Applikation besteht aus vielen einfachen Skripten die in verschiedenen Knoten ausgeführt werden und eng zusammenarbeiten. Durch die Mobilität der Skripte wird der so gebildete verteilte Algorithmus im Netzwerk verteilt.
Es kann als eine Aufgabe der Erfindung angesehen werden, ein System und ein Verfahren sowie einen Netzwerkknoten vorzuschlagen, mit dem ein besonders flexibler Aufbau von Netzwerken insbesondere für Automationsaufgaben möglich ist.
Diese Aufgabe wird gemäß einem ersten Aspekt der Erfindung gelöst durch ein Verfahren nach Anspruch l, ein System nach Anspruch 7 und einen Netzwerkknoten hierfür nach Anspruch 11. Gemäß einem alternativen Aspekt der Erfindung wird die Aufgabe weiter gelöst durch ein Verfahren gemäß Anspruch 12.
Die Verwendung von Skripten zur Ausführung auf Netzwerkknoten ist an sich bekannt, ebenso wie zu Konfigurationszwecken die Übermittlung derartiger Skripte von einem Netzwerkknoten an einen anderen Netzwerkknoten. Von solchen bekannten Netzwerken, Kno- ten und Verfahren unterscheidet sich der erste Aspekt der Erfindung (Ansprüche 1, 7 und 11) dadurch, dass einem Netzwerkknoten nicht ein vollständiges Funktionsskript übermittelt wird, das ein vorheriges Funktionsskript überschreibt und ersetzt, sondern dass ein Skript- Fragment, d. h. ein Teil eines Funktionsskripts übermittelt wird, das ein bestehendes Funktionsskript zu dessen Laufzeit modifiziert. Gemäß dem zweiten Aspekt der vorliegenden Erfindung (Anspruch 12) findet die Übertragung eines Skripts bei Wahrnehmung einer Überwachungs-, Steuer- oder Regelfunktion statt, nämlich in Abhängigkeit von einem Sensorwert. Wie insbesondere im Zusammenhang mit den bevorzugten Ausführungen deutlich wird, unterscheidet sich die somit vorgeschlagene Verwendung von Skripten deutlich von der Übermittlung von Skripten zur Konfiguration eines Systems in einer Konfigurationspha- se und kann insbesondere während der Betriebsphase des Systems verwendet werden. Die beiden Aspekte der Erfindung sind dabei vorteilhaft miteinander kombinierbar.
Bei dem Verfahren, dem System und dem Knoten gemäß dem ersten Aspekt der Erfindung sind mindestens ein erster und ein zweiter Netzwerkknoten vorgesehen, die über eine Kommunikationsverbindung verbunden sind. Wie oben erläutert stellt jeder Netzwerkknoten einen eigenständigen Rechner dar mit Speicher, Zentraleinheit und Kommunikationsschnittstelle sowie optional mit Ankopplung an einen Sensor und/oder Aktor. Die Netzwerkknoten sind bevorzugt räumlich verteilt, d. h. im Abstand angeordnet. Die Kommuni- kationsverbindung ist bevorzugt eine drahtlose oder drahtgebundene digitale Datenverbindung nach beliebigem Protokoll.
Der erste Netzwerkknoten führt ein Funktionsskript aus. Hierunter wird ein Skript verstanden, das die Funktion des ersten Netzwerkknotens bspw. in Form einer Steuer-, Regelungs- oder Überwachungsfunktion definiert, also insbesondere bevorzugt die Verarbeitung von Eingangswerten (bspw. Sensorwerten) und Ausgabe von Ausgabewerten (bspw. zur Ansteu- erung eines Aktors) umfasst. Das Funktionsskript definiert die Funktion des ersten Netzwerkknotens in der Betriebsphase des Systems, d. h. wenn - je nach Einsatzzweck - die betreffende Regel-, Steuer- oder Überwachungsfunktion ausgeführt wird.
Das Funktionsskript ist in einer Skript-Sprache verfasst und wird durch den ersten Netzwerkknoten ausgeführt, bspw. mittels eines Interpreters oder Echtzeit-Compilers (Just-In- Time-Compiler). Dabei wird unter einem Interpreter eine durch ein Programm realisierte Funktionalität verstanden, die Skript-Kommandos, sei es als Quelltext oder in Token-Form ausführt, indem diese zur Laufzeit eingelesen werden. Wie dem Fachmann bekannt ist, kann dies verschiedene einzelne Programm-Elemente und Einzelschritte umfassen, bspw. einen Tokenizer, mit dem Skript-Quelltext zunächst in Tokens umgewandelt wird, die anschließend ausgeführt werden. Dabei können die verschiedensten Skript-Sprachen und hierfür in den Knoten vorgesehene Ausführungsmittel (bspw. Interpreter, JIT-Compiler) verwendet werden. Dies umfasst prinzipiell jede Skript-Sprache mit ausführbaren Befehlen. Bevorzugt sind dabei komplexe Skripte und Ausführungsmittel, die zur Ausführung von komplexen Skripten geeignet sind. Unter komplexen Skripten werden solche Skripte verstanden, die komplexe Sprachkon- struktionen wie bspw. Funktionsaufrufe und insbesondere bevorzugt Schleifen beinhalten. Bevorzugt weist mindestens der erste Netzwerkknoten Mittel zur Ausführung von komplexen Skripten auf, insbesondere mit der Möglichkeit zur Ausführung von Schleifen. Besonders bevorzugt sind die Ausführungsmittel Turing-Maschinen. Erfindungsgemäß übermittelt der zweite Netzwerkknoten in der Betriebsphase, also während der Ausführung des Funktionsskripts am ersten Netzwerkknoten, an diesen ein Skript- Fragment. Ein Skript-Fragment kann ein einzelner Skript-Befehl oder eine Gruppe von Skript-Befehlen sein, bspw. Skript-Befehle zur Definition einer oder mehrerer aufrufbarer Funktionen (wobei der Begriff„aufrufbare Funktion" in diesem Zusammenhang Bezug nimmt auf die Verwendung in Programmiersprachen, also vordefinierte Befehlsfolgen, die ggf. mit Parametern aufgerufen werden und einen oder mehrere Rückgabewerte liefern können). Das Skript-Fragment dient erfindungsgemäß zur Modifikation des Funktionsskripts des ersten Netzwerkknotens. Bspw. kann es dieses ergänzen, ebenso aber auch in Teilen überschreiben oder Teile davon löschen oder neu definieren. Die Modifikation kann erfolgen, indem der erste Netzwerkknoten das Skript-Fragment ausführt, woraufhin dieses die Modifikation vornimmt. Ebenso kann die Modifikation auch anderweitig, bspw. durch ein über- geordnetes Betriebsprogramm des ersten Netzwerkknotens erfolgen, das automatisch das Skript-Fragment dem Funktionsskript hinzufügt bzw. die Modifikation ausführt.
Im Gegensatz zu bekannten Update-Mechanismen wird das Funktionsskript dabei während seiner Laufzeit durch das Skript-Fragment modifiziert. Dabei erfolgt wie erläutert keine vollständige Ersetzung, sondern das Funktionsskript bleibt bevorzugt bis auf die vorgenommene Modifikation unverändert und läuft weiter.
Durch die erfindungsgemäße Modifikation zur Laufzeit wird ermöglicht, dass durch das Skript-Fragment Steuerfunktionen ausgeführt werden, also bspw. die Übermittlung von Werten, Steuerkommandos etc.. Die Skript-Fragmente können also so genutzt werden, dass sie nicht den Zweck einer einmaligen oder gelegentlichen (Um-)Konfiguration erfüllen, sondern Teil der eigentlichen Funktion des Gesamtsystems zur Laufzeit während der Betriebsphase sind. So kann bspw. eine Schaltfunktion auf dem ersten Netzwerkknoten dadurch ausgelöst werden, dass der zweite Netzwerkknoten ein Skript-Fragment übermittelt, das das Funktionsskript des ersten Netzwerkknotens so modifiziert, dass die Schaltfunktion ausgeführt wird.
Das Verhalten des Systems kann hierdurch sehr flexibel gestaltet werden. Gemäß einer Weiterbildung der Erfindung erfolgt die Modifikation des Funktionsskripts derart, dass das Skript-Fragment eine aufrufbare Funktion definiert, die durch das Funktionsskript aufgerufen wird. Dabei kann das Skript-Fragment bspw. aus der aufrufbaren Funktion selbst bestehen, so dass eine Installationsroutine am ersten Netzwerkknoten nach Erhalt des Skript-Fragments die so definierte Funktion installiert, d. h. aufrufbar bereitstellt. Besonders bevorzugt ist allerdings eine Implementierung, bei der das Skript- Fragment vom ersten Netzwerkknoten direkt ausgeführt wird und dabei zur Bereitstellung der aufrufbaren Funktion führt. So ist eine spezielle Installationsroutine auf Seiten des ersten Netzwerkknotens nicht notwendig, sondern der erste Netzwerkknoten führt einfach den jeweils von anderen Netzwerkknoten übermittelten Code aus, im vorliegenden Kontext das Skript-Fragment.
Die Übermittlung eines Skript-Fragments lässt sich besonders gut und flexibel dazu nutzen, Sensor- Werte, hiervon abgeleitete Werte oder hierauf basierende Ereignisse (bspw. Über- /Unterschreitung einer Schwelle) über das Netzwerk zu signalisieren. Gemäß einer entsprechenden Weiterbildung der Erfindung ist der zweite Netzwerkknoten mit mindestens einem Sensor für eine physikalische Größe verbunden. Das Skript-Fragment kann nun in Abhängigkeit von mindestens einem von dem Sensor gelieferten Wert erstellt werden, bspw. automatisch generiert oder aus einer Anzahl von vordefinierten Skript-Fragmenten ausge- wählt.
Hierdurch sind Steuer- und Regelungsfunktionen besonders einfach implementierbar. Bspw. zur Signalisierung eines aktuellen Sensor- Wertes kann der zweite Netzwerkknoten den Sensorwert auslesen und ein Skript oder Skript-Fragment generieren, das den so ausge- lesenen Sensorwert enthält. Das generierte Skript oder Skript-Fragment kann dabei auch eine weitere Verarbeitung des Wertes vorsehen, bspw. einen von einem oder mehreren Sensorwerten abhängigen Wert berechnen, den Wert auf Über-/Unterschreitung einer Schwelle prüfen und abhängig von Ergebnissen hiervon Aktionen auslösen oder Steuervorgaben machen. Das so generierte Skript oder Skript-Fragment kommt allerdings bevorzugt erst nach Übermittlung zum ersten Netzwerkknoten dort zur Ausführung.
Wie nachfolgend im Hinblick auf den zweiten Aspekt der Erfindung näher erläutert wird, kann der Grundgedanke der Erstellung bzw. Auswahl eines Skripts abhängig von Sensor- Werten und Übermittlung des Skripts an einen anderen Netzwerkknoten zur Ausführung auch generell, unabhängig von der Verwendung Skript-Fragmenten, erhebliche Vorteile hinsichtlich der Flexibilität und Konfigurierbarkeit eines Systems bieten.
Gemäß dem zweiten Aspekt der Erfindung umfasst ein System analog zum ersten Aspekt zwei oder mehr Netzwerkknoten, bzw. werden diese Netzwerkknoten in einem Steuerverfahren verwendet. Dabei ist mindestens einer der Netzwerkknoten erfindungsgemäß mit einem Sensor für eine physikalische Größe verbunden.
Abhängig von einem Sensorwert wird am zweiten Netzwerkknoten ein Skript bereitgestellt. Dies kann bspw. erfolgen, indem das Skript automatisch generiert wird. Das Generieren eines Skriptes kann bspw. auf Basis von einer oder mehreren Skript-Vorlagen erfolgen, wobei in dort vorgesehene Platzhalter der Sensorwert oder von dem Sensorwert abhängige Werte bzw. Anweisungen eingesetzt werden. Das Skript kann alternativ auch bereitgestellt werden durch Auswahl unter einer Anzahl von vorhandenen Skripten, wobei die Auswahl abhängig vom Sensorwert erfolgt. Weiter kann die Bereitstellung des Skriptes auch erfolgen durch Abruf eines Skriptes über das Netzwerk, d. h. von einem anderen Netzwerkobjekt, sofern auch dies in Abhängigkeit vom Sensorwert erfolgt.
In jedem Fall ist das so bereitgestellte Skript abhängig vom Sensorwert, d. h. es kann bspw. den Sensorwert oder einen daraus abgeleiteten Wert enthalten, oder aber abhängig von dem Sensorwert verschiedene Steuervorgaben machen.
Bei dem Skript kann es sich um ein umfassendes Funktionsskript, ebenso aber auch um einen einzelnen Skript-Funktionsaufruf oder um ein Skript-Fragment zur Modifikation eines Funktionsskriptes handeln.
Das so bereitgestellte Skript wird an den ersten Netzwerkknoten übermittelt und dort ausgeführt.
Wie im Zusammenhang mit bevorzugten Ausführungsformen genauer erläutert wird, können durch die Übertragung und entfernte Ausführung von Skripten, die von mindestens einem Sensorwert abhängen, auf sehr vorteilhaft flexible Weise Steuer- und Regelungsfunktionen ausgeführt werden. Eine Anzahl von Weiterbildungen betreffen beide Aspekte der Erfindung. Gemäß einer Weiterbildung umfasst das System bzw. Verfahren einen Aktor-Sensorknoten, der mit mindestens einem Aktor zur Vorgabe einer physikalischen Größe verbunden ist und zu der Ansteu- erung des Aktors vorgesehen ist. Bei dem Aktor-Sensorknoten kann es sich um einen der Sensorknoten der Systeme gemäß beider Aspekte der Erfindung wie oben beschrieben handeln, d. h. sowohl der dort jeweils beschriebene erste als auch zweite Netzwerkknoten kann die Rolle eines solchen Aktor-Sensorknotens einnehmen. Ebenso kann der Aktor- Sensorknoten ein zusätzlicher Sensorknoten des Systems sein. Die Ansteuerung des Aktor-Sensorknotens erfolgt gemäß der Weiterbildung dadurch, dass von einem anderen Sensorknoten (wiederum kann es sich hierbei um einen der oben bereits beschriebenen Knoten handeln oder alternativ um einen zusätzlichen Knoten) ein Skript (dies umfasst vollständige Funktionsskripte, Skript-Fragmente oder auch nur einzelne Skript-Funktionsaufrufe) übermittelt wird. Dieses Skript wird auf dem Aktor-Sensorknoten ausgeführt. Bei der Ausführung des Skriptes erfolgt eine Ansteuerung des Aktors.
Die Verwendung von Skripten ermöglicht im Gegensatz zur Übermittlung von einfachen Vorgabewerten oder Einzelkommandos eine sehr flexible Steuerung, bspw., je nach Ausgestaltung des Skripts, auch bedingte Ansteuerungen (wenn-dann-Anweisungen), wiederholte Ansteuerungen (Schleifen), Kommunikation mit weiteren Netzwerkknoten etc.. Vor allem ist zur Ansteuerung auf dem Aktor-Sensorknoten zunächst keine dezidierte Software erforderlich, sondern diese wird in Form des Ansteuer-Skripts von einem anderen Netzwerkknoten übermittelt, was eine dynamische Konfiguration ermöglicht. Eine andere Weiterbildung der Erfindung in beiden Aspekten ist der auch separat verwendbare Gedanke von Skripten, die in umgebenden Skripten eingebettet sind, was als„Nesting" bezeichnet werden kann. In einer Ausführung kann ein Netzwerkknoten ein erstes (äußeres) Skript an einen Mittler-Netzwerkknoten übermitteln (auch hier umfasst der Begriff Skript sämtliche ausführbaren Skripte inklusive Skript-Fragmenten und einzelnen Skript- Funktionsaufrufen). Der Mittler-Netzwerkknoten ist auch hierbei eine Rolle, d. h. jeder der vorbeschriebenen Netzwerkknoten oder ein zusätzlicher Netzwerkknoten kann diese Rolle übernehmen. Der Mittler-Netzwerkknoten führt das erste (äußere) Skript aus. Dieses ist so aufgebaut, dass es bei der Ausführung ein zweites (inneres) Skript an einen weiteren Netzwerkknoten übermittelt. Das Konzept des„Nesting" kann flexibel eingesetzt werden, insbesondere um unter Zwischenschaltung des Mittler-Netzwerkknotens einen oder mehrere weitere Netzwerkknoten zu erreichen. Bspw. kann das erste (äußere) Skript so ausgebildet sein, dass es bei seiner Ausführung mehrere zweite (innere) Skripte an verschiedenen Netzwerkknoten übermittelt. Ebenso können das Ziel oder der Inhalt des zweiten Skripts von Bedingungen abhängig gemacht werden, die bei der Ausführung des ersten (äußeren) Skripts überprüft werden.
Besondere Vorteile bietet das Nesting-Konzept bei der Überwindung von Protokollgrenzen. Wird das erste Skript über eine Kommunikationsverbindung nach einem ersten Kommunikationsprotokoll und das zweite Skript über eine Kommunikationsverbindung nach einem zweiten, hiervon verschiedenen Kommunikationsprotokoll übermittelt, kann mit Hilfe derart eingebetteter Skripte sehr einfach eine Multiprotokoll-Fähigkeit erreicht werden. Ein genereller Gedanke der hier vorgestellten Verfahren und Systeme, der für beide Aspekte der Erfindung verwendet werden kann, ebenso aber auch separat verwendbar ist, ist die Unterteilung von Netzwerkknoten in verschiedene Knotenklassen mit unterschiedlicher Leistungsfähigkeit. Als bevorzugte Knotenklassen können Smart Nodes, Clever Nodes und Primitive Nodes definiert sein. Netzwerkknoten dieser drei Knotenklassen sind jeweils in der Lage, Skripte oder mindestens einzelne Skript-Befehle bzw. Skript-Funktionsaufrufe auszuführen. Netzwerkknoten völlig anderen Typs, ohne die Fähigkeit zum Ausführen von Skripten oder Skript-Funktionsaufrufen, können als Alien Nodes zusätzlich vorhanden sein, die bspw. über ein Gateway angesprochen werden können. Bevorzugt umfasst ein System jeweils einen oder mehrere Netzwerkknoten jeder der drei Klassen (Smart Nodes, Clever Nodes, Primitive Nodes).
Die verschiedenen Knotenklassen sind durch ihre Funktion voneinander abzugrenzen. Primitive Nodes verfügen über die Möglichkeit, einzelne Skript-Befehle in Form jeweils eines einzelnen Skript-Funktionsaufrufs auszuführen. Sie können keine komplexen Skripte aus- führen, also bspw. keine Schleifen, Funktionsdefinitionen, etc.. Primitive Nodes können bspw. nur über einen Einzelzeilen-Interpreter zur Ausführung einzelner Funktionsaufrufe verfügen.
Clever Nodes unterscheiden sich hiervon durch die Fähigkeit, komplexe Skripte auszufüh- ren. Hierfür ist auf Clever Nodes ein Interpreter oder Echtzeit-Compiler (JIT, Just-in-time Compiler) vorhanden, bevorzugt als virtuelle Maschine. Clever Nodes weisen dabei keine grafische Benutzeroberfläche auf, sondern verfügen allenfalls über nicht-grafische Ausgabemöglichkeiten, bspw. eine Text-Konsole.
Smart Nodes hingegen verfügen über eine grafische Benutzeroberfläche (GUI) und die Möglichkeit zur Ausführung von komplexen Skripten.
In derzeit bevorzugten Ausführungen unterscheiden sich die Knotenklassen hinsichtlich der Leistungsfähigkeit der gewählten Hardware, also bspw. Rechenleistung und Speichergröße. Smart Nodes verfügen i.d.R. über hohe Rechenleistung und Speichergröße. Clever Nodes verfügen im Vergleich meist über begrenzte Rechenleistung und Speichergröße. Primitive Nodes können bereits mit geringer Rechenleistung und Speichergröße realisiert sein. Die in einem konkreten System jeweils verwendete Hardware wird anhand der benötigten Informationen und gegebenen Rahmenbedingungen (insbesondere Kosten, Baugröße, Leistungsaufnahme) jeweils so ausgewählt, dass sie für den jeweils angestrebten Verwendungszweck innerhalb des Systems ausreichend dimensioniert sind, allerdings möglichst nicht deutlich überdimensioniert.
Wie nachfolgend anhand von bevorzugten Ausführungsformen im Detail erläutert wird, können Smart Nodes insbesondere für die Benutzer-Interaktion dienen. Bei der Kommissi- onierung eines Systems kann ein Smart Node als Konfigurations-System verwendet werden. Primitive Nodes können je nach Anforderung bspw. zur direkten Ansteuerung eines Aktors oder zum Auslesen eines Sensors verwendet werden.
Eine besonders wichtige Rolle kommt den Clever Nodes zu, die aufgrund ihrer Fähigkeit zum Ausführen und Übermitteln von Skripten die eigentliche verteilte Intelligenz des Systems in der Betriebsphase darstellen können, dabei aber im Gegensatz zu Smart Nodes be- reits realisierbar sind unter Einhaltung enger Rahmenbedingungen . Sie sind somit vielfältig und ggf. auch in größerer Zahl einsetzbar, bspw. für Steuer-, Regelungs- oder Überwachungsaufgaben.
Nachfolgend werden Beispiele von Systemen aus Netzwerkknoten und Steuer- sowie Kom- munikationsverfahren hiefür anhand von Zeichnungen näher beschrieben. In den Zeichnungen zeigen:
Fig. l eine schematische Darstellung eines ersten Beispiels eines Systems von Netzwerkknoten zur Steuerung eines Heizelements;
Fig. 2 in schematischer Darstellung einen Netzwerkknoten der Knotenklasse Clever
Node mit Darstellung von Hardwarekomponenten;
Fig. 3 eine schematische Darstellung einer Software-Schichtstruktur des Netzwerkknotens aus Fig. 2;
Fig. 4 in schematischer Darstellung ein zweites Beispiel eines Systems von Netzwerkknoten mit einem Konfigurationssystem in einer Konfigurationsphase;
Fig. 5 in schematischer Darstellung eine Bildschirmausgabe des Konfigurationssystems aus Fig. 4;
Fig. 6 in schematischer Darstellung das System aus Fig. 4 in einer Betriebsphase;
Fig. 7 in schematischer Darstellung ein drittes Beispiel eines Systems von Netzwerkknoten mit Kommunikationsverbindungen mit unterschiedlichen Kommunikationsprotokollen;
Fig. 8 in schematischer Darstellung ein System zur Konfiguration eines Netzwerkknotens des Systems aus Fig. 1.
Nachfolgend werden beispielhaft Systeme von Netzwerkknoten sowie Verfahren zur Steuerung, Konfiguration und zum Betrieb von derartigen Systemen und einzelnen Knoten beschrieben. Die nachfolgend dargestellten Systeme stellen Beispiele von Netzwerken dar, die durch miteinander verknüpfte Netzwerkknoten gebildet sind. Jeder Netzwerkknoten ist dabei ein eigenständiger Rechner und kann je nach Aufgabe und gegebenen Rahmenbedingungen auf sehr unterschiedlicher Hardware realisiert werden, bspw. auch als FPGA oder Ein-Chip- System (System-on-Chip, SoC).
Beispielhaft erläutert an einem in Fig. 2 schematisch dargestelltem Netzwerkknoten 10 verfügt jeder Netzwerkknoten über einen Speicher 12, der üblicherweise flüchtigen (RAM)- Speicher sowie nichtflüchtigen Speicher (bspw. ROM und/oder Flash-Speicher) umfasst und zur Speicherung von Daten und/oder Programmen genutzt wird. Eine Zentraleinheit 14 ist zum Ausführen von Programmen vorgesehen und kann einen oder mehrere Mikroprozessoren, Mikrokontroller, Signalprozessoren etc. umfassen. Eine Netzwerkschnittstelle 16 ermöglicht eine digitale Netzwerkkommunikation mit anderen Netzwerkknoten, wobei verschiedenste Schnittstellentypen, Kommunikationsmedien (kabelgebunden, drahtlos) und Übertragungswege sowie Kommunikationsprotokolle verwendet werden können. Weiter verfügt jeder Netzwerkknoten über eine Leistungsversorgung 18 (hier symbolisch dargestellt in Form einer Batterie; je nach Ausführung kann neben oder statt einer Batterie oder einem wiederaufladbaren Akkumulator auch eine Netzverbindung oder jede andere Energiequelle wie Mittel zum Energy Harvesting genutzt werden, bspw. eine Solarzelle, ein Piezo-Element, ein Thermo-Element, etc. mit einer Speichermöglichkeit für die gesammelte Energie), mit der die Komponenten des Netzwerkknotens mit elektrischer Leistung versorgt werden. Optional kann jeder Netzwerkknoten eine oder mehrere weitere Schnittstellen 20 aufweisen, bspw. zur direkten Verbindung mit Sensoren und/oder Aktoren. Die hier behandelten Systeme bilden bevorzugt cyber-physische Systeme, d.h. einen Verbund informationstechnischer Komponenten mit mechanischen und elektronischen Teilen, die über eine Dateninfrastruktur kommunizieren. Derartige cyber-physische Systeme sind gegenwärtig in intensiver Erforschung und Weiterentwicklung. Wie cyber-physische Systeme im Allgemeinen können auch die hier vorgestellten Systeme vorteilhaft verwendet wer- den in Einsatzbereichen wie medizinische Geräte und Systeme, altersgerechte Assistenzsysteme, Verkehrssteuerung und Verkehrslogistik, automobile Sicherheits- und Assistenzsysteme, industrielle Prozesssteuerungen, Umweltbeeinflussungs- und Beobachtungssysteme, Energieversorgungsmanagementsysteme, militärische Systemvernetzungssysteme und Kommunikationsinfrastruktur.
Sensoren, die mit Netzwerkknoten verbunden sind, können zur Erfassung einer physikalischen Größe dienen. Dies kann sich auf Umgebungsbedingungen beziehen, also bspw. auf Druck, Helligkeit, Temperatur etc., ebenso aber auf überwachte Vorrichtungen, Geräte und Anlagen, an denen bspw. Betriebs-Parameter wie Drehzahl, Dreh- oder Verschiebeposition, Geschwindigkeit etc. mit Hilfe eines Sensors überwacht werden können. Aktoren dienen hingegen zur Beeinflussung bzw. Vorgabe physikalischer Größen. Die Ansteuerung erfolgt dabei bevorzugt zunächst elektrisch, wodurch dann mittelbar oder unmittelbar durch den Aktor eine Steuerfunktion beliebiger Art, also bspw. mechanisch oder elektrisch, ausgeführt werden kann. Dementsprechend können Aktoren bspw. elektrische Treiber- und Ansteuer- schaltungen für beliebige elektrische Geräte und Vorrichtungen sein, ebenso aber Ansteue- rungen für Stellventile, Elektromagnete, Motoren, Heizelemente, Leuchten, Relais etc..
Die hier vorgestellten Systeme können in einer Vielzahl von Gebieten der Technik verwendet werden, wobei allerdings die Verwendung in der Automationstechnik besonders bevorzugt ist. Daher umfassen die Systeme bevorzugt mindestens einen, meist mehrere Sensoren und mindestens einen, meist mehrere Aktoren. Jeder der Sensoren oder Aktoren ist dabei bevorzugt an mindestens einem der Netzwerkknoten direkt angekoppelt, z. B. an einer der in Fig. 2 dargestellten Schnittstellen 20. Eine solche direkte Ankopplung liegt dabei auch dann vor, wenn der Sensor oder Aktor unmittelbar in die Hardware oder bspw. auch in das Gehäuse eines Netzwerkknotens integriert ist.
Der Begriff der Automation bezieht sich dabei einerseits auf Felder wie die Gebäude- und Fabrikautomation, also bspw. Funktionalitäten wie eine Heizungsregelung, Lichtsteuerung, Steuerung und Regelung von Maschinen und Anlagen, Steuerung und Regelung von Verteilnetzen (smart grids) etc.. Andererseits kann Automation aber neben klassischen Steuer-, Regelungs- und Überwachungsaufgaben auch logistische Prozesse betreffen, also bspw. der Warenverkehr in einem Unternehmen, Steuerung einer Gruppe von Fahrzeugen, etc..
Fig. 1 zeigt beispielhaft ein für eine Automatisierung, nämlich in diesem Beispiel eine Steuerung eines Heizelements nutzbares Netzwerk 30 mit vier Netzwerkknoten 32, 34, 36, 38. Entsprechend ihrer unterschiedlichen Hardware-Ausstattung sind die Netzwerkknoten dabei in verschiedene Klassen von Knoten einzuteilen.
Die Unterteilung der Klassen erfolgt dabei anhand von bereitgestellten Funktionen in Smart Nodes, Clever Nodes und Primitive Nodes. Eine Smart Node verfügt über die Möglichkeit zur Ausführung von komplexen Skripten, also einen Interpreter oder Just-in-Time Compiler, bevorzugt eine virtuelle Maschine, z.B. eine Lua Virtual Machine für die Skriptsprache Lua. Derartige„komplexe Skripte" unterscheiden sich bspw. von einzelnen Anweisungen oder Skript-Funktionsaufrufen, die keinen vollständigen Interpreter benötigen, sondern mit einem deutlich einfacheren Single Line Interpreter ausgeführt werden können. Komplexe Skripte umfassen dabei mindestens ein komplexes Sprach element der verwendeten Skript- Sprache wie Schleifen und/oder die Definition ausführbarer Funktionen. Weiter umfasst eine Smart Node eine grafische Benutzeroberfläche (GUI), z. B. Touchscreen und/oder Bildschirm, Maus, Tastatur. Die Hardware - Ausstattung einer Smart Node muss ausreichen, um die Funktionalität (komplexe Skripte, GUI) zu erfüllen. Dabei gibt es in der Regel keine deutlichen Beschränkungen hinsichtlich Leistungsaufnahme, Größe und Kos- ten. Ein Smart Node 32 kann daher beliebig hohe Rechenleistung und Speichergröße aufweisen. Bspw. kann es sich hierbei um einen Notebook- oder Desktoprechner sowie anderen voll ausgestatteten handelsüblichen Computer handeln, um ein Tablet oder Smart Phone, oder bspw. um einen dedizierten Steuerrechner. Ein Smart Node kann beispielsweise ausgerüstet sein mit mindestens einem Mehrkernprozessor und Arbeitsspeicher von 1 GB oder mehr.
Im dargestellten Beispiel wird der Netzwerkknoten 32 der Knotenklasse Smart Node von einem Benutzer dazu verwendet, das Verhalten der übrigen Knoten zu konfigurieren und zu visualisieren.
Die Netzwerkknoten 34 und 36 gehören der Klasse der Clever Nodes an. Diese Knotenklasse ist funktional dadurch definiert, dass die zugehörigen Netzwerkknoten Mittel zum Ausführen von komplexen Skripten aufweisen, also bspw. einen Interpreter oder JIT-Compiler (bevorzugt als virtuelle Maschine), dabei aber keine grafische Benutzeroberfläche. Clever Nodes können ohne Benutzerschnittstelle auskommen oder eine nicht-grafische Ausgabe erlauben, also beispielsweise eine Text-Konsole.
Clever Nodes können dabei in beliebiger Hardware realisiert werden, die die o.g. Funktionen unterstützt. Aufgrund von regelmäßig vorhandenen Einschränkungen hinsichtlich Leis- tungsaufnahme, Baugröße und/oder Kosten werden Clever Nodes i.d.R. eine geringere Rechenleistung und Speicherausstattung aufweisen als die Klasse der Smart Nodes. Ein Clever Node kann bspw. mit einem Ein- oder Mehrkernprozessor ausgerüstet und über Arbeitsspeicher von bspw. 512 kB bis üblicherweise weniger als 1GB verfügen. Von heute verfügbarer Hardware können Clever Nodes bspw. mit Mikroprozessoren der Leistungsklasse eines ARM Cortex-M4 oder M3 ausgestattet sein.
Die Klasse der Primitive Nodes, der der Netzwerkknoten 38 angehört, weist ebenfalls keine grafische Benutzeroberfläche auf. Auch Primitive Nodes verfügen über einen Speicher und Mikroprozessor, können aber keine vollständigen Skripte, sondern bspw. mit Hilfe eines Single Line Interpreter nur einzelne Skript-Funktionsaufrufe ausführen, wiederum bevorzugt in Lua. Hardwaremäßig können Primitive Nodes sehr enge Rahmenbedingungen einhalten, d.h. auf gering ausgestatteter Hardware realisiert werden. Von heute verfügbarer Hardware könnte die Zentraleinheit einer Primitive Node bspw. ein Atmel AVR ATmega oder vergleichbarer Prozessor sein.
In Fig. 3 sind schematisch die Schichten der Software-Architektur eines Clever Node Netzwerkknotens dargestellt. Die unterste Schicht bildet die Hardware 40, auf der zunächst ein Runtime-Sytem 41 läuft. Das Runtime-System 41 umfasst übliche Systemroutinen wie bspw. Speicherverwaltung, Interupt-Handling, etc. sowie einen Interpreter (oder alternativ: Just- In-Time-Compiler) für eine Skriptsprache, hier bevorzugt Lua, bevorzugt unter Verwendung einer Lua Virtual Machine.
Auf dem Runtime-System setzt eine Systemschicht 42 auf, die als Bibliothek von aufrufba- ren Funktionen realisiert sein kann. Die Systemschicht 42 kann als Maschinencode vorliegt, bspw. als kompiliertes C-Programm, mindestens zum Teil aber auch in Form von Skripten. Auf der Systemschicht 42 setzt eine Hardware-Abstraktionsschicht HAL 44 auf, die im bevorzugten Beispiel in Lua bzw. einer anderen gewählten Skriptsprache programmiert ist und auf dem Interpreter ausgeführt wird. Die Hardware-Abstraktionsschicht HAL 44 dient dazu, die darauf aufsetzende Anwendungsebene 46 (Application Layer) von der jeweils tatsächlich vorhandenen Hardware 40 so zu entkoppeln, dass diese über Standard-Aufrufe angesprochen werden kann, ohne dass die jeweilige Applikation spezifisch auf die jeweils vorhandene Hardware angepasst werden muss. Die hier behandelten Netzwerke können eine im Prinzip beliebige Anzahl von Netzwerkknoten der verschiedenen Knotenklassen umfassen. Je nach Verwendungszweck ist es dabei nicht erforderlich, dass immer Netzwerkknoten jeder Knotenklasse vorhanden sind. Zusätzlich können Netzwerkknoten anderen Typs ohne die Fähigkeit zur Ausführung von Skripten ebenfalls Teil des Netzwerks sein, wobei diese dann in einer Knotenklasse von Alien Nodes zusammengefasst werden.
Die einzelnen Netzwerkknoten sind in der Regel räumlich verteilt angeordnet, d. h. sie befinden sich jeweils im Abstand voneinander, wobei es in einzelnen Fällen aber ebenso möglich ist, dass zwei oder mehr Netzwerkknoten nebeneinander, bspw. im selben Schalt- schrank angeordnet sind. Untereinander sind die Knoten durch eine digitale Datenverbindung als Kommunikationsverbindung miteinander gekoppelt, wobei allerdings nicht zwingend alle Datenverbindungen der verschiedenen Knoten vom selben Typ sein müssen. Ebenso muss nicht zwischen allen Paaren von Knoten eine direkte Verbindung bestehen, sondern eine solche kann auch durch Mittelung über einen oder mehrere zwischengeschaltete Knoten gebildet sein. Mögliche Formen der Kommunikationsverbindung zwischen Netzwerkknoten können bspw. drahtgebunden sein, z. B. als Ethernet-Netzwerk oder auch in Form einer seriellen Schnittstelle, bspw. RS-232, RS-422 etc.. Ebenso können die Netzwerkknoten drahtlos miteinander in Verbindung stehen, wie es bspw. von drahtlosen Sen- sornetzwerken (Wireless Sensor Networks) bekannt ist. Mögliche drahtlose Datenverbindungen umfassen Protokolle wie bspw. Bluetooth, Zigbee, Thread etc..
Eine Besonderheit der hier bevorzugt vorgestellten Systeme besteht darin, dass die zwischen den Knoten übermittelten Daten nicht wie herkömmlich bekannt als einzelne Werte bzw. Steuerbefehle übermittelt werden, sondern jeweils in Form ausführbarer Skripte oder Skript-Fragmente.
Dadurch, dass die einzelnen Netzwerkknoten der drei Knotenklassen wie erläutert jeweils dazu in der Lage sind, ganze Skripte oder wenigstens einzelne Skript-Funktionsaufrufe aus- zuführen, ist das aus den Knoten gebildete System sehr flexibel. Übermittelt bspw. in herkömmlichen Netzwerken ein Netzwerkknoten, der direkt mit einem Sensor für eine physikalische Größe verbunden ist, einen von diesem gelieferten Wert an einen anderen Netzwerkknoten, so ist auf dem empfangenden Netzwerkknoten zwangsläufig eine dedizierte Programmierung zur Verarbeitung des Wertes notwendig. Bei den hier vorgestellten Netzwer- ken hingegen kann die Kommunikation zwischen zwei Knoten in der Form erfolgen, dass ein Knoten ein ausführbares Skript, bevorzugt in Lua, oder ein Skript-Fragment, oder auch nur einen einzelnen Skript-Funktionsaufruf an einen anderen Netzwerkknoten überträgt. Der empfangende Netzwerkknoten führt das übertragende Skript aus. Im Fall eines Netzwerkknotens, der direkt mit einem Sensor verbunden ist, kann demnach der jeweils gelieferte Sensorwert (oder ebenso hiervon abgeleitete Werte, bspw. Signale, wenn der Sensorwert eine vorgegebene Schwelle erreicht) in Skript-Form übertragen werden, so dass nach Ausführung des übertragenden Skripts im empfangenden Knoten der Wert zur Verfügung steht sowie optional bereits eine Anweisung ausgeführt wird, die eine Verarbeitung des Wertes vorgibt. Somit kann eine Sensor- Funktionalität mit Signalisierung in Form eines Skriptes erfolgen, wobei das Skript innerhalb des sendenden, mit dem Sensor verbundenen Netzwerkknotens bspw. generiert werden kann, z. B. aus einer Skript-Vorlage, in die noch Werte eingesetzt werden, oder das Skript kann aus einer Anzahl von vorgespei- cherten Skripten oder Skript-Vorlagen ausgewählt werden.
In gleicher Weise wie die oben dargestellte Verarbeitung von Sensordaten kann auch die Ansteuerung eines Aktors durch Übermittlung eines Skriptes erfolgen. Während herkömmlich bspw. an einen Netzwerkknoten, der direkt mit einem Aktor, bspw. einer Motorsteue- rung verbunden ist ein Steuerkommando (bspw. an/aus) oder ein Ansteuerwert (bspw.: Drehzahl) übermittelt wird, ermöglichen die hier vorgestellten Systeme die Ansteuerung mittels eines ausführbaren Skriptes, das über die Kommunikationsverbindung übertragen und in dem betreffenden Netzwerkknoten ausgeführt wird und dabei die Ansteuerung des Aktors bewirkt. Statt also bspw. eine bestimmte Drehzahl für den zu steuernden Motor zu übertragen, wird ein Skript übertragen, das bei Ausführung die Drehzahl entsprechend vorgibt. Die Parameter der Ansteuerung (im Beispiel also an/aus, Drehzahl) können bspw. fest (d.h. bspw. als Konstanten) im Skript enthalten sein, oder von diesem ausgerechnet oder abgerufen werden. Bei dem in Fig. 1 dargestellten System ist der Primitive Node Netzwerkknoten 38 mit einem Aktor, in diesem Beispiel einer Ansteuerung eines Heizelements 48 verbunden. Der Clever Node Netzwerkknoten 34 ist mit einem Sensor, in diesem Fall einem Schalter 50 verbunden, der von einem Benutzer bedient werden kann. Der Clever Node Netzwerkknoten 36 ist mit zwei Sensoren verbunden, im gezeigten Beispiel einem Helligkeitssensor 52 und einem Feuchtesensor 54.
Das System 30 soll beispielhaft eingesetzt werden zur Heizungssteuerung, nämlich zur Ansteuerung des Heizelements 48 in Abhängigkeit von der Bedienung des Schalters 50 sowie in Abhängigkeit von der durch die Sensoren 52, 54 erkannten Umgebungsbedingungen der Raumhelligkeit und Luftfeuchte.
Innerhalb des Systems 30 erfolgt die Kommunikation zwischen den Netzwerkknoten in Form der Übermittlung von Lua-Skripten, sei es als vollständige Funktionsskripte, Skript- Fragmente oder einzelne Skript-Funktionsaufrufe. Die Konfiguration des Systemverhaltens, d. h. hier speziell die Funktion, nach der die von dem Heizelement 48 abgegebene Heizleistung bzw. die resultierende Temperatur abhängig von den durch die Sensoren 50, 52, 54 gelieferten Werten gesteuert werden soll, wird von dem Smart Node Netzwerkknoten 32 in Form eines Skriptes 56 vorgegeben, dass in diesem Fall den Clever Node Netzwerkknoten 36 übermittelt wird. Der Clever Node Netzwerkknoten 36 fragt die Sensoren 52, 54 ab, und übermittelt in Abhängigkeit von den gelieferten Werten nach Vorgabe des Skriptes 56 einen Ansteuerwert. Dieser Ansteuerwert wird allerdings nicht als solcher, sondern in Form eines Skriptes 58 an den Clever Node Netzwerkknoten 34 übermittelt. Das Skript 58, bei dem es sich wie nachfolgend näher erläutert wird in diesem Beispiel um ein Skript-Fragment han- delt, wird innerhalb des Clever Node Netzwerkknotens 36 ausgehend von einer Skript- Vorlage generiert.
Der Clever Node Netzwerkknoten 34 führt ein Funktionsskript 60 aus, das die Stellung des Schalters 50 abfragt. Das Funktionsskript 60 wird zur Laufzeit durch das Skript-Fragment 58 ergänzt, wie unten näher erläutert wird. Durch das so ergänzte Skript wird bei weiterer Ausführung ein Ansteuerwert für das Heizelement 48 ermittelt.
Die Ansteuerung des Heizelements erfolgt durch den Primitive Node Netzwerkknoten 38. Allerdings wird auch hier der Ansteuerwert vom Clever Node Netzwerkknoten 34 an dem Primitive Node Netzwerkknoten 38 nicht als reiner Wert übermittelt, sondern wiederum in Skript-Form, in diesem Fall als einzelnen Skript-Funktionsaufruf 62. Der Skript- Funktionsaufruf 62 wird durch den Single Line Interpreter auf dem Primitive Node Netzwerkknoten 38 ausgeführt und so die Ansteuerung des Heizelements 48 vorgenommen. Zum besseren Verständnis der hierbei verwendeten Techniken werden nachfolgend die Skripte (beispielhaft in Lua-Code) sowie deren Generierung und Zusammenführung näher erläutert:
Das vom Smart Node Netzwerkknoten 32 an den Clever Node Netzwerkknoten 36 übermit- telte Skript 56 kann bspw. in Lua-Code wie folgt lauten: join.attach(
[[
function LightAndHumidtyToTemp(light,humidty) local t =
return t
Dabei entspricht der oben mit ... angedeutete Platzhalter einer Funktion bzw. Rechenvorschrift, mit der aus Werten für Licht und Feuchtigkeit ein Temperaturwert zurückgegeben wird.
Das vom Smart Node Netzwerkknoten 32 übermittelte Skript wird vom Clever Node Netzwerkknoten 36 nach Übermittlung ausgeführt. Bei dieser Ausführung wird allerdings die darin enthaltene aufrufbare Funktion LightAndHumidtyToTemp nicht direkt ausgeführt, sondern zunächst installiert. Im Kontext des auf dem Clever Node Netzwerkknoten 36 ausgeführten Funktionsskriptes ist diese Funktion anschließend aufrufbar.
Das vom Clever Node Netzwerkknoten 36 ausgeführte Funktionsskript könnte bspw. folgendermaßen definiert sein:
LightAndHumidtyToTemp(hal.getLight(),hal.getHumidty()) code = string.format(
[[
function GetTempO
return %f
end
]],
join.attach(code)
Dieses Skript weist zunächst der Variablen t den Wert zu, der sich durch Aufruf der installierten aufrufbaren Funktion LightAndHumidtyToTemp mit Übergabe der Sensorwerte der Sensoren 52, 54 als Parameter errechnet. Die Sensoren 52, 54 werden dabei durch die Hardware-Abstraktionsschicht HAL angesprochen (hal.getLight()).
Anschließend wird ausgehend von einer Skript-Vorlage in Form eines Strings mit einem Platzhalter ( f) das Skript-Fragment 58 zunächst in einer String-Variablen mit der Be- Zeichnung„code" gespeichert. Das Skript-Fragment 58 definiert dabei die aufrufbare Funktion GetTemp, wobei der Rückgabeparameter dieser aufrufbaren Funktion fest durch den vorher ausgerechneten Wert gebildet und in Textform in das Skript-Fragment 58 eingesetzt ist. Durch den Befehl join.attach(code) wird das so gebildete Skript-Fragment an den Clever Node Netzwerkknoten 34 übermittelt und dort installiert. Anschließend ist im Clever Node Netzwerkknoten 34 die Funktion GetTemp wie oben definiert installiert.
Das Funktionsskript 60 des Clever Node Netzwerkknotens 34 kann bspw. wie folgt ausse- hen: hal.setTemp = function (t)
local code = string.format(
Ttemp.set( f)T
t
)
join.send(code)
end
function onSwitchEvent(on)
if on then
hal.setTemp(GetTempO)
eise
hal.setTemp(o)
end
end
In dem Funktionsskript wird zunächst die Funktion hal.setTemp definiert, in der abhängig von dem übergebenen Parameter t ein einzelner Lua-Funktionsaufruf als String mit der Bezeichnung„code" erzeugt und mittels join.send an den Primitive Node Netzwerkknoten 38 zur Ausführung übergeben werden kann. Weiter wird die durch das Umschalten des Schalters 50 (Switch Event) getriggerte Funktion OnSwitchEvent() definiert, die bei ausgeschaltetem Schalter die Funktion hal.setTemp mit dem Parameter (o) aufruft, um das Heizelement auszuschalten oder im Fall des eingeschalteten Schalters die durch das Skript-Fragment 58 installierte Funktion GetTemp aufruft und die daraus erhaltenen Werte über hal.setTemp an den Primitive Node Netzwerkknoten 38 übermittelt.
Im Primitive Node Netzwerkknoten 38 wird der jeweils übermittelte Skript- Funktionsaufruf Temp.set() mit dem darin vorgegebenen Parameter ausgeführt und somit die Ansteue- rung des Heizelements 48 entsprechend vorgenommen.
Insgesamt führt das System 30 somit eine Steuerfunktion aus, bei der das Heizelement 48 in Abhängigkeit von den Sensoren 52, 54 und dem Schalter 50 (der ebenfalls ein Sensor ist) mit verschiedenen Ansteuerwerten (t) betrieben bzw. an- und ausgeschaltet wird. Wie beschrieben wird diese Funktionalität erreicht, indem zwischen den Netzwerkknoten stets Skripte übermittelt werden. Durch Änderung der Skripte ist das Steuerverhalten dynamisch anpassbar, auch während des Betriebes.
Das System erweist sich dabei als besonders robust, da keine zentrale Steuerung erfolgt, sondern die jeweiligen Funktionen dezentral auf die Knoten verteilt sind. Der Smart Node Netzwerkknoten 32 wird, nachdem er einmalig das Skript 56 mit Vorgabe der Funktion LightAndHumidtyToTemp konfiguriert hat, zunächst nicht mehr benötigt. Während der Laufzeit der Regelung muss der Smart Node Netzwerkknoten 32 nicht aktiv sein, er kann allerdings zur Umkonfiguration des System genutzt werden, bspw. indem eine geänderte Funktion LightAndHumidtyToTemp an dem Clever Node Netzwerkknoten 36 übermittelt wird, um das Systemverhalten zu ändern.
Das System 30 kann durch die dargestellte Verwendung von Skripten leicht dynamisch umkonfiguriert werden. Bspw. durch den Smart Node Netzwerkknoten 32 kann jedem der Netzwerkknoten ein geändertes Funktionsskript übermittelt werden. So ist das System sehr leicht an geänderte Anforderungen anpassbar.
Fig. 4 zeigt ein zweites Beispiel eines Systems 70 mit einer Anzahl von Netzwerkknoten. Im Beispiel von Fig. 4 sind ein Smart Node 72 als Konfigurationssystem und zwei Clever Nodes 74, 76 vorgesehen, von denen der erste Clever Node Netzwerkknoten 74 an einen Aktor (Treiberschaltung für das Heizelement 75) und der zweite Clever Node Netzwerkknoten 76 an einen Sensor (Schalter 78) angeschlossen ist. Im Beispiel von Fig. 4 wird der Smart Node Netzwerkknoten 72 nur in einer Konfigurationsphase benötigt. Der Smart Node Netzwerkknoten 72, der über eine grafische Benuteroberfläche GUI verfügt, kann von einem Benutzer dazu verwendet werden, das System 70 zu konfigurieren bzw. zu kommissionieren, d. h. das Verhalten der Netzwerkknoten 74, 76 entsprechend der gewünschten Automationsaufgabe vorzugeben.
Die Funktion der Netzwerkknoten 74, 76 in der späteren Betriebsphase wird wie zuvor beschrieben durch auf den Knoten ausgeführte Funktionsskripte vorgegeben. Es ist nun möglich, dass der Benutzer die jeweiligen Funktionsskripte einzeln erstellt bzw. auf dem Konfigurationssystem vorgegebene Skripte auswählt, ggf. anpasst und über die Netzwerk- Verbindung an die Netzwerkknoten zur dortigen Ausführung übermittelt. Hierfür würde der Benutzer aber vorab Informationen über die im System 70 zur Verfügung stehenden Netzwerkknoten 74, 76 benötigen und müsste zur anschließenden Programmierung von Skripten diese jeweils im Einzelfall manuell vornehmen bzw. anpassen. Vereinfacht wird die Kommissionierung des Systems 70 durch die Verwendung von speziellen Skripten, hier bezeichnet als Avatare. Ein Avatar-Skript repräsentiert ein Netzwerkobjekt, also bspw. einen einzelnen Netzwerkknoten oder eine Gruppe von Netzwerkknoten, und dokumentiert Fähigkeiten und/oder Eigenschaften des Netzwerkobjekts, insbesondere bevorzugt mögliche Verbindungen, d. h. mögliche Ausgaben oder Empfangsmöglichkeiten für Werte oder Signale. Die Avatar-Skripte werden von dem jeweiligen Netzwerkobjekt an das Konfigurationssystem 72 übermittelt und dort ausgeführt und ermöglichen dann die Kommissionierung, so dass anschließend vom Konfigurationssystem 72 Funktionsskripte an die jeweiligen Netzwerkobjekte zur Ausführung in der anschließenden Betriebsphase übermittelt werden. Im Beispiel des Systems 70 übermittelt der Clever Node Netzwerkknoten 74 ein Avatar- Skript 80 und der Clever Node Netzwerkknoten 76 übermittelt ein Avatar-Skript 82 an das Konfigurationssystem 72. Bei den Skripten handelt es sich in dem bevorzugten Beispiel wie- derum um Lua-Skripte, die auf dem Konfigurationssystem 72 ausgeführt werden. Jedes Avatar-Skript repräsentiert und beschreibt den jeweiligen Netzwerkknoten und seine Eigenschaften und Fähigkeiten, so dass bspw. das Avatar-Skript 80 die Fähigkeit des Clever Node Netzwerkknotens 74 zur Ansteuerung des Heizelements 75 dokumentiert und das Avatar- Skript 82 des Clever Node Netzwerkknotens 76 die Fähigkeit zur Abfrage des Sensors 78.
Die jeweiligen Netzwerkknoten des Systems 70 melden sich somit jeweils als einzelne Netzwerkobjekte beim Konfigurationssystem 72 unter Übermittlung ihrer Avatar-Skripte an, so dass im Konfigurationssystem 72 eine Datenbank aus den verfügbaren Netzwerkobjekten und ihren jeweiligen Eigenschaften, Anschlüssen etc. erstellt werden kann.
Die Kommissionierung im Konfigurationssystem 72 kann bspw. automatisch anhand der so erstellten Datenbank erfolgen, wenn der Regelungs- bzw. Automatisierungszweck dies ermöglicht. Ebenso kann die Datenbank aber auch zur Unterstützung eines Benutzers dienen, der anhand der jeweils gewünschten Automatisierungsaufgabe und des gewünschten Regel- Verhaltens die Kommissionierung auf dem Konfigurationssystem vornimmt.
Im dargestellten, bevorzugten Beispiel enthalten die Avatar-Skripte 80, 82 Befehle zur grafischen Darstellung der jeweiligen Netzwerkobjekte, d. h. hier der Knoten 74, 76 auf dem GUI des Konfigurationssystems 72. Eine mögliche Bildschirmausgabe ist beispielhaft in Fig. 5 dargestellt. Das Avatar-Skript 80 des Aktor-Netzwerkknotens 74 stellt diesen grafisch in Form einer Heizelement -Repräsentation dar mit einem Steuereingang 84. Das Avatar- Skript 82 des Schalter-Netzwerkknotens 76 stellt diesen mit einem Schaltersymbol und einem Ausgang 86 dar. Mit Hilfe des GUI des Konfigurationssystems 72 kann das (im dargestellten Beispiel sehr einfache) System 70 nun durch den Benutzer kommissioniert werden. Beispielsweise kann ein Benutzer den Ausgang 86 mit dem Eingang 84 verbinden, wie in Fig. 5 beispielhaft dargestellt, um so eine Funktion vorzugeben, bei der das Heizelement 75 abhängig von der Stellung des Schalters 78 in der späteren Betriebsphase geschaltet werden soll. Sobald der Benutzer die gewünschte Funktion des Systems 70 definiert hat, generiert ein Skript-Generator des Konfigurationssystems 72 automatisch Funktionsskripte für die jeweiligen Netzwerkknoten. Bevorzugt ist dabei eine unmittelbare Verarbeitung durch den Skript-Generator, so dass Benutzer-Eingaben direkt in eine Konfiguration des laufenden Systems umgesetzt werden (live coding).
Der Skript-Generator erzeugt automatisch für die jeweils vom Benutzer vorgegebene Funktionalität entsprechende Funktionsskripte für die beteiligten Netzwerkknoten. Hierfür in- terpretiert der Skript-Generator Benutzer- Eingaben, hier bspw. Eingaben auf der grafischen Oberfläche wie das Verbinden von Ein- und Ausgängen, oder sonstige Anforderungen, und wandelt diese in ein oder mehrere Funktions- oder Konfigurationsskripte um, hier bspw. in das Funktionsskript 88. Dem Sensor-Netzwerkknoten 76 wird ein solchermaßen erstelltes Funktionsskript 88 übermittelt, was eine Ansteuerung des Heizelements 75 über den Aktor-Netzwerkknoten 74 abhängig von der Stellung des Schalters 78 vorsieht. In gleicher Weise kann auch dem Aktor- Netzwerkknoten 74 ein Funktionsskript übermittelt werden, was aber bei der hier beispielhaft gezeigten sehr einfachen Funktionsweise nicht notwendig ist.
Im Fall der Erstellung eines Konfigurationsskripts wird dieses dem jeweiligen Netzwerkknoten übermittelt und dort ausgeführt, so dass dadurch das entsprechende Funktionsskript installiert wird. Zusätzlich werden die Vorgaben des Benutzers an die beteiligten Netzwerkknoten als sogenannte Retain-Werte zur dortigen Speicherung übermittelt. Diese Retain- Werte dienen bei einer künftigen Neu-Konfiguration bzw. Kommissionierung als Startwert. Denn während bei einer Ersteinrichtung des Systems 70 die Netzwerkknoten 74, 76 zunächst unkonfigu- riert sind, ist dies nach der ersten Konfiguration nicht mehr der Fall. Kommt es zu einer Anmeldung bereits konfigurierter Netzwerkknoten an einem Konfigurationssystem 72, so wäre es nachteilig, wenn bereits konfigurierte Netzwerkknoten dann stets in einen unkonfi- gurierten Zustand zurückgesetzt würden. Andererseits wird es regelmäßig nicht bzw. nur mit sehr hohem Aufwand möglich sein, die jeweilige Konfiguration der Netzwerkknoten 74, 76 (d.h. im vorliegenden Beispiel die Verbindung des Ausgangs 86 mit dem Eingang 84) aus den jeweils dort laufenden Funktionsskripten zu extrahieren.
Um die jeweils zuletzt eingerichtete Konfiguration eines einzelnen Netzwerkknotens 74, 76, aber auch eines Systems 70 mit mehreren Netzwerkobjekten so zu speichern, dass bei einer erneuten Konfiguration stets von den vorherigen Konfigurationsstand ausgegangen werden kann, werden die Benutzer- Vorgaben (hier: Verbindung des Ausgangs 86 mit dem Eingang 84) den beteiligten Netzwerkobjekten (hier: Netzwerkknoten 74, 76) zur dortigen Speicherung übermittelt. Dies kann bspw. in Skript-Form erfolgen, d.h. den beiden Netzwerkknoten 74, 76 wird jeweils ein Skript übermittelt, mit dem die Retain -Werte dort lokal abgespei- chert werden.
Bei einer erneuten Anmeldung an einem Konfigurationssystem 72 übersendet dann jedes Netzwerkobjekt, das bereits über eine vorherige Konfiguration verfügt, die als Retain- Werte dort lokal gespeichert ist, sein jeweiliges Avatar-Skript 80, 82. Die Retain-Werte können innerhalb des Avatar-Skripts 80, 82 enthalten oder zusätzlich zu diesem übermittelt werden. Bei Ausführung der Avatar-Skripte 80, 82 werden diese anhand der Retain-Werte in einen Zustand entsprechend der vorherigen Konfiguration versetzt (d.h. im folgenden Beispiel die Verknüpfung des Ausgangs 86 mit dem Eingang 84 hergestellt). In einer anschließenden Betriebsphase, die in Fig. 6 dargestellt ist, werden die jeweiligen Funktionsskripte auf den Netzwerkknoten ausgeführt, d. h. im gezeigten Beispiel das Funktionsskript 88 auf dem Sensor-Netzwerkknoten 76. Das Konfigurationssystem 72 wird in der Betriebsphase nicht benötigt, d. h. dort stattfindende Kommunikation kann ausschließlich zwischen den übrigen, in diesem Fall unmittelbar an der gewünschten Steuerfunktion beteiligten Netzwerkknoten 74, 76 erfolgen.
Im Fall der einfachen Aufgabe des Beispiels ist das Funktionsskript 88 so ausgebildet, dass der Sensor-Netzwerkknoten 76 im Fall einer Schalterbetätigung (Event) ein Skript 90 an den Aktor-Netzwerkknoten 74 übermittelt, mit dem je nach Schalt erstellung das Heizele- ment 75 ein- bzw. ausgeschaltet wird. Hierzu wird das übermittelte Skript 90 auf dem Aktor-Netzwerkknoten 74 ausgeführt, so dass die darin vorgegebene Steuerfunktion ebenfalls zur Ausführung kommt.
In der Fig. 7 ist ein weiteres Beispiel eines Systems 100 mit drei Netzwerkknoten 102, 104, 106 der Knotenklasse Clever Node dargestellt. Die Netzwerkknoten 102, 104, 106 sind allerdings in diesem Falle nicht alle untereinander mit derselben Kommunikationsverbindung verbunden, sondern es besteht eine erste Kommunikationsverbindung 108 mit einem ersten Kommunikationsprotokoll zwischen dem ersten Netzwerkknoten 102 und einem Mittler- Netzwerkknoten 104. Diese erste Kommunikationsverbindung 108 kann bspw. eine drahtgebundene digitale Datenübertragung über eine Ethernet-Verbindung sein.
Weiter besteht eine zweite Kommunikationsverbindung 110 nach anderem Protokoll zwischen dem Mittler-Netzwerkknoten 104 und einem weiteren (Ziel-)Netzwerkknoten 106. Hierbei kann es sich bspw. um eine drahtgebundene serielle Datenübertragung handeln, bspw. nach dem RS-485-Protokoll. Der erste Netzwerkknoten 102 ist direkt an einen Sensor 112 angekoppelt; der weitere Netzwerkknoten 106 ist an einen Aktor 114 angeschlossen.
Um eine Steuerung des Aktors 114 in Abhängigkeit von einem Sensorwert S des Sensors 112 zu erreichen, muss das System 100 multiprotokoll-fähig sein, da keine direkte Kommunikationsverbindung mit nur einem Kommunikationsprotokoll zwischen den beteiligten Netzwerkknoten 102, 106 besteht. Dies wird durch das Konzept eines eingebetteten Skripts gelöst, auch bezeichnet als Nesting. Der erste Netzwerkknoten 102 wird durch sein Funktionsskript so gesteuert, dass er den Sensorwert S abfragt und in Abhängigkeit von dem Sensorwert S ein spezielles Skript 116 zur Ansteuerung des Heizelements generiert. Dieses auch als„äußeres" bezeichnete Skript wird dem Mittler-Netzwerkknoten 104 zur Ausführung übermittelt und dort ausgeführt. In das äußere Skript 116 ist ein inneres Skript 118 eingebettet. Die Einbettung des inneren Skriptes 118 ist dabei derart gelöst, dass das äußere Skript 116 bei seiner Ausführung auf dem Mittler-Netzwerkknoten 104 das innere Skript 118 erzeugt und an den weiteren, Ziel- Netzwerkknoten 106 zur dortigen Ausführung übersendet.
Bei der Ausführung des inneren Skriptes 118 im Ziel-Netzwerkknoten 106 wird die vorgege- bene Steuerfunktion ausgeführt.
Beispielsweise könnte das äußere Skript 116 im JSON-Format lauten
["rs485.non(\"temp.set(i.o)\") "] Bei Ausführung des äußeren Skripts 116 wird ein inneres Skript 118 wie folgt dem Ziel- Netzwerkknoten 106 zur Ausführung übermittelt: ["temp.set(i.o)"]
Mit diesem einzelnen Lua-Funktionsaufruf wird die Ansteuerung des Heizelements mit den enthaltenen Werten vorgegeben. Zu den dargestellten Systemen, Netzwerkknoten und Verfahren sind eine Anzahl von Abweichungen, Alternativen und Änderungen möglich. Insbesondere sind beliebige Kombinationen verschiedener Merkmale und Aspekte möglich. Bspw. der Aspekt der grundsätzlichen Kommunikationsweise mittels Skripten, die nach Übermittlung auf einem Ziel- Netzwerkknoten ausgeführt werden, der Aspekt der Zusammenfügung von Skripten und Skript-Fragmenten, der Aspekt des Nesting, und der Aspekt der Kommissionierung mittels Avatar-Skripten können in beliebiger Weise kombiniert werden, d. h. ein System oder Verfahren kann einen, mehrere oder alle dieser Aspekte in sich vereinen.
Bspw. kann das oben beschriebene Steuerverhalten des Systems 30 aus Fig. 1 am GUI eines Konfigurationssystems anhand eines Avatar-Skripts vorgegeben und ein Funktionsskript des Smart Node Netzwerkknotens 32, ebenso wie optional die jeweiligen Funktionsskripte der Netzwerkknoten 34, 36, 38 als automatisch generierte Funktionsskripte erzeugt und zur späteren Ausführung an diese übermittelt werden. Fig. 8 zeigt hierzu beispielhaft einen zusätzlichen Smart Node Netzwerkknoten 33 als Konfigurationssystem zur Konfiguration des Smart Node Netzwerkknotens 32. Als GUI verfügt das Konfigurationssystem 33 über ein Touchscreen 35.
Der Netzwerkknoten 33 meldet sich am Konfigurationssystem unter Übermittlung eines Avatar-Skripts 83 an. Dieses stellt bei Ausführung auf dem Touchscreen des Konfigurationssystems 33 den Graphen der jeweils aktuell vorgegebenen Funktion LightAndHumidityTo- Temp dar und erlaubt dem Benutzer, die gezeigte Kurve durch Ziehen auf dem Touchscreen 35 zu ändern. Sobald der Benutzer eine Änderung der Kurve vorgenommen hat, wird diese ausgewertet und ein entsprechendes Konfigurationsskript 57 an den Smart Node Netzwerkknoten 32 übermittelt (live coding). Das Konfigurationsskript 57 installiert ein neues Funktionsskript 56 mit einer geänderten Funktion LightAndHumidityToTemp. Das Konfigurationsskript 57 kann dabei beispielsweise generiert werden aus den grafischen Benutzer- Vorgaben durch Approximation der vom Benutzer eingestellten Kurve mittels Splines.
Ein solches im Avatar-Skript 83 des Smart Node Netzwerkknotens 32 enthaltenes Skript, das seinerseits als Skript-Generator arbeitet, könnte in Grundzügen bspw. wie folgt aussehen:
function LightAndHumidityToTemp (light, humidity)
local t = ...
Spline2D (...)
return t
end
Die angegebenen Hardware-Leistungsmerkmale der Klassen von Smart Node, Clever Node und Primitive Node sind beispielhaft unter Berücksichtigung heute zur Verfügung stehender Hardware zu verstehen. Mit der zukünftig zu erwartenden Verfügbarkeit von Hardware mit höherer Rechenleistung, größerer Speicherausstattung etc. bei gleichem oder geringeren Anforderungen an Baugröße, Leistungsaufnahme und Kosten können die jeweiligen Funktionen der Knotenklassen künftig durch andere Hardware realisiert werden. Maßgeblich sind daher die funktionalen Merkmale der Knotenklassen.

Claims

Ansprüche
Verfahren zur Steuerung mindestens eines Netzwerkknotens (34), bei dem
mindestens ein erster und einer zweiter Netzwerkknoten (34, 36) über eine Kommunikationsverbindung verbunden sind,
wobei der erste Netzwerkknoten (34) mindestens ein Funktionsskript (60) ausführt,
und der zweite Netzwerkknoten (36) während der Ausführung des Funktionsskripts (60) ein Skript-Fragment (58) zur Modifikation des Funktionsskripts (60) an den ersten Netzwerkknoten (34) übermittelt,
und wobei das Funktionsskript (60) zu seiner Laufzeit durch das Skript- Fragment (58) modifiziert wird.
Verfahren nach Anspruch 1, bei dem
das Skript-Fragment (58) eine aufrufbare Funktion definiert, die durch das Funktionsskript (60) aufgerufen wird. 3. Verfahren nach einem der vorangehenden Ansprüche, bei dem
der zweite Netzwerkknoten (36) mit mindestens einem Sensor (52, 54) für eine physikalische Größe verbunden ist,
und der zweite Netzwerkknoten (36) das Skript-Fragment (58) abhängig mindestens von einem von dem Sensor gelieferten Wert generiert oder auswählt.
4· Verfahren nach einem der vorangehenden Ansprüche, bei dem
ein Aktor-Sensorknoten (38, 74) zu Ansteuerung mit mindestens einem Aktor
(48, 75) zur Vorgabe einer physikalischen Größe verbunden ist, und dem Aktor-Sensorknoten (38, 74) von einem anderen Sensorknoten (34,
76) ein Skript (62, 90) übermittelt wird, wobei bei Ausführung des Skriptes (62,
90) auf dem Aktor-Sensorknoten (38, 74) eine Ansteuerung des Aktors (48, 75) erfolgt.
Verfahren nach einem der vorangehenden Ansprüche, bei dem ein Netzwerkknoten (102) ein erstes Skript (116) an einen Mittler- Netzwerkknoten (104) übermittelt, wobei der Mittler-Netzwerkknoten (104) das erste Skript (116) ausführt und bei der Ausführung mindestens ein zweites Skript (118) an einem weiteren Netzwerkknoten (106) übermittelt wird.
6. Verfahren nach Anspruch 5, bei dem
das erste Skript (116) über eine Kommunikationsverbindung (108) nach einem ersten Kommunikationsprotokoll übermittelt wird,
und das zweite Skript (118) über eine Kommunikationsverbindung (110) nach einem zweiten Kommunikationsprotokoll übermittelt wird, das vom ersten Kommunikationsprotokoll verschieden ist.
7. System mit
mindestens einem ersten und einem zweiten Netzwerkknoten (34, 36), die über eine Kommunikationsverbindung miteinander verbunden sind, wobei mindestens der erste Netzwerkknoten (34) Mittel zur Ausführung eines Funktionsskripts (60) umfasst,
und wobei der erste Netzwerkknoten (34) dazu ausgebildet ist, während der Ausführung des Funktionsskripts (60) vom zweiten Netzwerkknoten (36) ein Skript-Fragment (58) zur Modifikation des Funktionsskriptes (60) zu empfangen, und das Funktionsskript (60) zur Laufzeit durch das Skript-Fragment (58) zu modifizieren.
8. System nach Anspruch 7, bei dem
ein oder mehrere Netzwerkknoten (32, 72) einer Klasse von Smart Nodes vorhanden sind, wobei Smart Nodes eine grafische Benutzeroberfläche und Mittel um Ausführen von komplexen Skripten umfassen,
und ein oder mehrere Netzwerkknoten (34, 36, 74, 76) einer Klasse von Clever Nodes vorhanden sind, wobei Clever Nodes Mittel um Ausführen von komplexen Skripten, aber keine grafische Benutzeroberfläche umfassen, und ein oder mehrere Netzwerkknoten (38) einer Klasse von Primitive Nodes vorhanden sind, wobei Primitive Nodes einen Einzelzeilen-Interpreter zur Ausführung von einzelnen Skript- Funktionsaufrufen aufweisen. System nach Anspruch 7 oder 8, bei dem der erste und der zweite Netzwerkknoten
(34, 36, 74, 76) mindestens aufweisen:
einen Speicher (12) zum Speichern von Programmen, Daten und/oder Skripten,
eine Zentraleinheit (14) zum Ausführen von Code,
sowie mindestens eine digitale Kommunikationsschnittstelle (16).
System nach Anspruch 9, bei dem der erste und/ oder der zweite Netzwerkknoten
(34, 36, 74, 76) mindestens
zur Ansteuerung mit mindestens einem Aktor (48, 75) zur Vorgabe einer physikalischen Größe verbunden ist, und/oder
zur Abfrage mit mindestens einem Sensor (52, 54, 50, 78) für eine physikalische Größe verbunden ist.
Netzwerkknoten zur Verwendung in einem System nach einem der Ansprüche 7 - 10,
mit Mitteln zur Ausführung eines Funktionsskripts (60),
wobei der Netzwerkknoten (34) dazu ausgebildet ist, während der Ausführung des Funktionsskriptes (60) ein Skript-Fragment (58) zur Modifikation des Funktionsskriptes (60) zu empfangen und das Funktionsskript (60) zur Laufzeit durch da Skript-Fragment (58) zu modifizieren.
Verfahren zur Steuerung mindestens eines Netzwerkknotens, bei dem
mindestens ein erster und ein zweiter Netzwerkknoten (34, 36, 38, 74, 76) über eine Kommunikationsverbindung verbunden sind, wobei der zweite Netzwerkknoten (34, 36, 76) mit mindestens einem Sensor (50, 52, 54, 78) für eine physikalische Größe verbunden ist,
wobei der zweite Netzwerkknoten (34, 36, 76) abhängig mindestens von einem von dem Sensor gelieferten Wert ein Skript (58, 62, 90) abruft, generiert oder auswählt,
und der zweite Netzwerkknoten das Skript an den ersten Netzwerkknoten (34, 38, 74) übermittelt,
und wobei der erste Netzwerkknoten das Skript ausführt.
PCT/EP2015/070878 2014-09-11 2015-09-11 Kommunikation zwischen netzwerkknoten mittels skripten WO2016038203A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102014113137.1 2014-09-11
DE102014113137.1A DE102014113137A1 (de) 2014-09-11 2014-09-11 Kommunikation zwischen Netzwerkknoten mittels Skripten

Publications (1)

Publication Number Publication Date
WO2016038203A1 true WO2016038203A1 (de) 2016-03-17

Family

ID=54256719

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2015/070878 WO2016038203A1 (de) 2014-09-11 2015-09-11 Kommunikation zwischen netzwerkknoten mittels skripten

Country Status (2)

Country Link
DE (1) DE102014113137A1 (de)
WO (1) WO2016038203A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220377065A1 (en) * 2021-05-19 2022-11-24 Prove Identity, Inc. Single-exchange authentication of a communications device

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060282498A1 (en) 2005-06-09 2006-12-14 Hitach, Ltd. Sensor network system, method for data processing of a sensor network system
US20070083813A1 (en) * 2005-10-11 2007-04-12 Knoa Software, Inc Generic, multi-instance method and GUI detection system for tracking and monitoring computer applications
US20100205596A1 (en) 2007-07-26 2010-08-12 Gangneung-Wonju Nationa University Industrial Academy Cooperation Group Method for updating firmware of sensor nodes on the wireless sensor network
US8204971B2 (en) 2007-05-02 2012-06-19 Synapse Wireless, Inc. Systems and methods for dynamically configuring node behavior in a sensor network
US8438250B2 (en) 2008-09-23 2013-05-07 Synapse Wireless, Inc. Systems and methods for updating script images in wireless networks
US20130123948A1 (en) 2011-11-11 2013-05-16 Rockwell Automation Technologies, Inc. Control environment change communication
US20130123946A1 (en) * 2011-11-11 2013-05-16 Rockwell Automation Technologies, Inc. Agile control model system and method
US20130124575A1 (en) * 2011-11-11 2013-05-16 Rockwell Automation Technologies, Inc. System and Method for Dynamic Meta-Data in Control and Visualization
US20140142963A1 (en) 2012-10-04 2014-05-22 Spacelabs Healthcare Llc System and Method for Providing Patient Care

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060282498A1 (en) 2005-06-09 2006-12-14 Hitach, Ltd. Sensor network system, method for data processing of a sensor network system
US20070083813A1 (en) * 2005-10-11 2007-04-12 Knoa Software, Inc Generic, multi-instance method and GUI detection system for tracking and monitoring computer applications
US8204971B2 (en) 2007-05-02 2012-06-19 Synapse Wireless, Inc. Systems and methods for dynamically configuring node behavior in a sensor network
US20100205596A1 (en) 2007-07-26 2010-08-12 Gangneung-Wonju Nationa University Industrial Academy Cooperation Group Method for updating firmware of sensor nodes on the wireless sensor network
US8438250B2 (en) 2008-09-23 2013-05-07 Synapse Wireless, Inc. Systems and methods for updating script images in wireless networks
US20130123948A1 (en) 2011-11-11 2013-05-16 Rockwell Automation Technologies, Inc. Control environment change communication
US20130123946A1 (en) * 2011-11-11 2013-05-16 Rockwell Automation Technologies, Inc. Agile control model system and method
US20130124575A1 (en) * 2011-11-11 2013-05-16 Rockwell Automation Technologies, Inc. System and Method for Dynamic Meta-Data in Control and Visualization
US20140142963A1 (en) 2012-10-04 2014-05-22 Spacelabs Healthcare Llc System and Method for Providing Patient Care

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
A. BOULIS; M. B. SRIVASTAVA: "Open Architectures and Network Programming Proceedings", 2002, IEEE, article "A Framework for Efficient and Programmable Sensor Networks", pages: 117 - 128

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220377065A1 (en) * 2021-05-19 2022-11-24 Prove Identity, Inc. Single-exchange authentication of a communications device

Also Published As

Publication number Publication date
DE102014113137A1 (de) 2016-03-17

Similar Documents

Publication Publication Date Title
DE102013113370B4 (de) Roboteraufgabensteuerungskomponente mit erweiterbarer programmierumgebung
DE102016113060A1 (de) Verfahren zum Steuern eines Objekts
DE112016007050T5 (de) Intelligente gateway-konfiguration für internet-der-dinge-netzwerke
EP3627800B1 (de) Publish-/subscribe-kommunikation von maschinensteuerungsdaten
DE112017006665T5 (de) System zur erstellung einer cloud-computing-basierten internet-of-things-plattform und verfahren dafür
DE112013004915T5 (de) Konfigurierbare User-Displays in einem Prozessleitsystem
EP2476032A2 (de) Verfahren zur konfiguration von soa-basierten automatisierungsgeräten und zur entwicklung einer orchestrierungs-maschine, fertigungsverfahren und fertigungssystem in service-orientierter architektur mit eingebetteter service-orchestrierungs-engine
DE102016124348A1 (de) System und Mikroservice zum Überwachen einer Anlage der Prozessautomatisierung
EP3230856A1 (de) Verfahren zum update von firmware von geräten
EP1137972B1 (de) Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu
EP1634130B1 (de) Vorrichtung und verfahren zur programmierung und/oder ausführung von programmen für industrielle automatisierungssysteme
DE10340234A1 (de) Fernbedienung in einer Textilmaschinenanlage
WO2016038203A1 (de) Kommunikation zwischen netzwerkknoten mittels skripten
EP3611587A1 (de) System zur steuerung und überwachung von adaptiven cyber-physikalischen systemen
EP2770382B1 (de) Verfahren zur Inbetriebnahme eines Automatisierungssystems
EP2324399A1 (de) Automatisierungssystem mit frameworkbasierter steuerung
DE102007040425B4 (de) Elektronisches Gerät, Umrichter, Verfahren zur Adressierung und Anlage
WO2019192844A1 (de) Verfahren und vorrichtung zur darstellung und anpassung von konfigurationen von anlagekomponenten
DE102015115402A1 (de) Konfiguration von Netzwerkknoten mittels Skripten
WO2021078765A1 (de) Optimierungsmodi für steuerprogramme eines robotermanipulators
EP3392725A1 (de) Vorschlagen und/oder erstellen von agenten in einem industriellen automatisierungssystem
EP3070558B1 (de) Verfahren zum konfigurieren eines embedded-geräts
EP3300038A1 (de) Zutrittskontrollsytem
WO2020187843A1 (de) Vorrichtung und verfahren zur fernprogrammierung
EP2926504B1 (de) Verfahren zum betreiben eines feldbusprotokoll-fähigen feldgerätes

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15775390

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15775390

Country of ref document: EP

Kind code of ref document: A1