Superordinate behavior descriptions for generating control programs and configurations for automation devices

Abstract

The invention relates to a method, a device and a computer program for configuring a programmable automation device. The method includes receiving a user-defined behavior description defining runtime behavior of the automation device and automatically generating a control program and configuration for the automation device based on the behavior description. The control programs and configurations may then be used for resource-saving operation of the automation device.

Description

Technical Field

[0001] The present invention generally relates to the technical field of automation technology, in particular to the technical field of building automation, and in particular to an automation device that determines output signals based on specific input signals and, for example, a control program, and outputs or provides these output signals. Background Art

[0002] In the technical field described, control systems are often used. Such systems can include automation devices, for example, for controlling specific components. Automation devices are usually designed to already provide basic functionality with the help of so-called firmware. However, before they can be used in a specific and suitable manner ("in the field"), these devices often first have to be programmed. The required programming varies depending on certain factors (only the important ones are mentioned here as examples: the task of the device, the device's position within the framework of the entire system). Therefore, in many cases, the user or programmer has to program each device. The programming required in this way is usually complex, error-prone, and inflexible. Therefore, even simple changes or the elimination of individual errors can result in significant additional costs.

[0003] In one example, consider the classical programming of a device. For this purpose, for example, a high-level language (a more advanced programming language with a high level of abstraction, such as C, C++) can be used. Such high-level languages ​​have the advantage that programming at a high level of abstraction is possible, i.e., the possibility of high-level language instructions in the program code (compared to programming at the machine code level or the process that occurs when executing at the CPU level) reduces complexity. A compiler can be used to convert the program code from such a high-level language into a machine language, which can then be accessed for immediate execution. Alternatively, a runtime environment (e.g., a runtime interpreter) can be used. These methods are expensive and require a large amount of resources. A negative impact on runtime performance can often be observed.

[0004] In another example, a programmable logic controller (PLC) is used. The controller development system (Codesys) offers a variant for programming PLCs. Programmable logic controllers can be programmed using an integrated development environment (IDE). This, too, requires complex compilation and / or computationally more complex execution, such as runtime interpretation, resulting in high resource requirements.

[0005] Furthermore, scripting languages ​​are known that can be used for programming automation controllers. For example, a programmer can use a corresponding scripting language to design a program for a programmable memory controller. In certain cases, the program instructions can be converted into an intermediate code and / or bytecode before being executed on the CPU of the automation component, using firmware.

[0006] A disadvantage of known solutions is their very high resource requirements. After all, they must be compiled and / or interpreted at runtime. In addition to these high resource requirements, their complexity also leads to a high susceptibility to errors. Consequently, errors are often difficult to identify and / or locate. For example, errors can be caused by actual program and / or compilation errors, but are often caused by errors in the runtime environment (such as programming errors or other forms of execution errors). Consequently, error tracking is difficult, and many errors go undetected for long periods of time. In particular, these rarely occurring errors can manifest themselves in automation products. Errors are not eliminated, but rather accepted with a certain probability. Consequently, these systems cannot truly operate stably over the long term, but rather can only operate for extended periods until an error-induced anomaly occurs, requiring a system restart, for example. This is particularly problematic for such applications, as the limited power available on site and the fact that restarts or troubleshooting are only possible under difficult conditions.

[0007] In order to make runtime environments executable for small microcontrollers, these runtime environments are usually further restricted not only in their functional scope but also in their performance properties. This makes efficient debugging of user programs for automation components more difficult.

[0008] The use of compilers and IDEs also requires the regular and costly use of other external computer resources, particularly if, for resource reasons, powerful microcontrollers must be omitted when using automation components “on site”.

[0009] With regard to flexibly usable and resource-saving programmable and operable solutions, all of the solutions mentioned are unsatisfactory. In this regard, it is also extremely desirable to have significantly simpler and more autonomous debugging by the user. Summary of the Invention

[0010] The aforementioned disadvantages are overcome by the present invention, which provides a solution for the configuration and operation of an automation system that is more resource- and energy-saving and at the same time more efficient and more suitable for the purpose than the solutions in the prior art.

[0011] This object is achieved by a method according to claim 1 and by the subject matter of the dependent claims. Preferred developments of the invention are specified in the dependent claims.

[0012] The present invention, in its most general form, provides methods, devices, systems and computer programs for configuring and continuously successfully operating programmable automation equipment.The described methods may be computer-implemented.

[0013] According to one aspect of the present invention, a method for configuring a programmable automation device may be provided. The method may include receiving a user-defined behavior description defining the runtime behavior of the automation device. The method may include automatically generating a control program and configuration for the automation device based on the behavior description. The method may also include providing the control program and / or configuration. The method may also provide for the operation of one or more correspondingly programmed automation devices.

[0014] The control program and the configuration of the building automation device can jointly define the functions provided by the automation device. The two can work together, but they should be distinguished.

[0015] For example, a behavioral description (which is higher than both a configuration and a control program) describes what one or more automated devices should do when a specific event occurs, such as in the field. For example, a certain input signal (such as the operation of a light switch) may cause a certain output signal (such as the operation of a lighting device) to be activated within a certain time.

[0016] The superordinate behavior description may be in a format that is specific to a tool for inputting and editing behavior descriptions (e.g., a PC tool, see also Figure 6 ) for use in automation devices or systems consisting of multiple automation devices. In this case, this format may not be suitable for direct execution by a microcontroller or interpreter.

[0017] For example, a current superordinate behavior description can be converted into a control program and configuration for a building automation device via a converter. The converted control program can then exist, for example, as bytecode that can be processed by an interpreter. The converter can be executed on the automation device, on another device, or in the cloud. The location of the conversion may depend, among other things, on the workload (and therefore on the resources). Before both the control program and configuration are used to generate the desired runtime behavior of the automation device, they can be checked for validity by the automation device, as we will explain in more detail later. The control program and configuration can be stored in the automation device to ensure immediate recovery after a power supply interruption. In larger automation systems, a master station can be used that can assume the superordinate role for various other automation components. In this case, additional copies of the component's control program and / or configuration can be stored in the master station. These copies can then be used, for example, in the event of a local component failure—not only if the local copy alone fails, but also if, for example, a local component needs to be replaced with an equivalent model due to damage.

[0018] For example, a control program for a building automation device may relate inputs and / or outputs to each other and / or to functions permanently stored in the device firmware. For example, a control program may include instructions in the following format:

[0019] “If the condition is true, then do the action, then the action, then the action, and so on…”

[0020] This can be clearly illustrated with the help of an example:

[0021] "If Light Button == Pressed, then Light_OnOff:=NOT Light_OnOff"

[0022] When expressing conditions and actions, simple logical operations such as NOT, AND, OR, etc. can be supported. In addition, different comparison operators such as ==, !=, >, and < can also be supported in conditions.

[0023] In the context of this patent application, the use of written form to represent these logical operations is of course purely symbolic and not restrictive. The present invention relates only to the technical teaching itself, and not to the symbolic conventions used to represent the technical teaching.

[0024] Here, an action may include assigning a value to a variable. This value may include a constant or may be formed from one or more variables by a logical operation.

[0025] The advantages of the resulting solution include, in particular, its low complexity, its low resource requirements during use (especially on automation components, especially when used in the field; this allows the use of smaller, less powerful, and more economical microcontrollers), its low resource requirements during switchover, and the ability to check the control program for validity or errors during the preparation phase (in particular, errors that could lead to undefined behavior and / or crashes of automation components can thus already be eliminated during the preparation phase). Energy requirements are low, especially when used in the field. The event-based control concept saves even more resources, especially energy, transmission capacity, and computing capacity. The "modular principle" provides users with greater flexibility, clarity, and control. In particular, the need for "programming" in the traditional sense is reduced on the user's side, as more "configuration activities" are involved than traditional "programming activities."

[0026] Further advantages of the invention result, for example, from the simplicity / ease of the control program. The control program can include if-then instructions. In one embodiment, it can consist solely of if-then instructions. For example, a condition can also affect only the action in the corresponding instruction (no "if-block instruction"). For example, no jump command can be provided. For example, no function and / or function call can be provided. In an extension, simplicity is additionally increased by allowing only one action instruction per if-then instruction. However, in general, multiple actions can be listed consecutively for execution.

[0027] For example, an instruction's condition can be evaluated if at least one variable referenced by the condition has changed at least once since the last time the condition was evaluated. Therefore, rather than executing sequentially, only those instructions whose input variables have changed are executed. This saves computing resources. If multiple instructions must be evaluated, the order may be undefined. This again provides further flexibility during execution and allows for the parallel and simultaneous execution of different components of the control program, particularly in automation systems equipped with multiple MCUs.

[0028] It should be noted that for the sake of simplicity, the functionality of the control program may be limited. Instead, complex functions can be provided by the device's firmware. For example, the selection of multiple functions can be linked to each other via the control program.

[0029] The simplicity of the control program allows the automation component to be fully tested for validity before use. The manufacturer can also ensure the quality and error-free nature of the complex functions provided by the device's firmware, for example through audits and unit tests.

[0030] For example, variables referenced by a control program (e.g., "light_button" and "light_OnOff" in one instance, see the example above) can be inputs or outputs of an automation device, or input parameters and / or output parameters of a complex function that is fixedly stored in firmware.

[0031] For example, instead of implementing a timer (timer and / or timer) for the stairway light function, as is possible with conventional devices in IEC languages, the user can store one or more such timers in the device's firmware. For example, such timers can be started and evaluated via variables that can be referenced and linked to each other by the control program. This will be explained in more detail within the context of a very simple example in the accompanying drawings.

[0032] For example, the configuration of building automation equipment can be considered as traditional parameterization. The control program and the configuration can together determine the behavior of the equipment.

[0033] Furthermore, the configuration can include settings that determine which functions hard-coded in the firmware are actually available to the control program, and in what quantities. For example, the firmware can contain a series of classes (templates / samples) for functions, but only provide the set of functions actually required for the application via the configuration. This approach takes advantage of the fact that MCUs typically have relatively large flash memories (for templates / classes) but less RAM (for instantiating the templates / classes that are actually used). Consequently, low-cost MCUs with less RAM can be used while still offering a large selection of hard-coded building automation functions, since the actual control program typically selects and uses only a few functions at a time.

[0034] In complex systems where control programs and configurations for multiple system components (and, moreover, automation devices) are generated from a behavior description, the templates or local functions provided for specific components can also be determined by a (superordinate) task allocation strategy, which can form part of the system behavior description. This allows, for example, simple and system-wide optimization based on the computing and storage capacities of the specific hardware components used. This will be described in more detail later.

[0035] In a simple example, the configuration can define the duration of a timer. For example, it can also configure special timer behaviors: for example, a device to be controlled (e.g., a lighting fixture) can be briefly disconnected and then connected again at a certain (e.g., predefined) time before the timer expires, thereby providing advance notice of the final disconnection of the lighting. This is merely a specific, but by no means limiting, application example.

[0036] For example, the higher-level behavior description can also be applied to multiple automation devices, in particular, an automation system comprising multiple automation devices. This higher-level behavior description, which includes the behavior of multiple components of a system, can be converted into a control program and a configuration. For example, when converting this cross-device and / or cross-system higher-level behavior description, a configuration and a control program are generated and provided for each component. In particular, such a system can be a master station and I / O modules of a modular I / O system. Such a system can also include expanders and other I / O modules. In addition to the advantages already mentioned, the consistency of the individual system components and the desired harmonious interaction are maintained by this cross-device and / or cross-system higher-level behavior description.

[0037] In this regard, a hard-coded function is also conceivable, which provides a set of variables for association and mirrors these variables to one or more other automation devices connected to the current automation device via a bus. This combination can particularly involve a master and / or expander and / or I / O modules of a modular I / O system. For example, this mirroring can be based on a subscription principle. For example, outbound data values ​​(e.g., via a local and / or fieldbus) are added from a first automation device to the data input of a second automation device.

[0038] After the switchover, the individual system components can act with a high degree of autonomy (especially independent of the superordinate behavior description), so that even if a component fails, the majority of the system functionality remains available.

[0039] In a non-limiting example with a master station and I / O modules connected thereto via a bus, the master station can, for example, take over the local functions of the master station as well as other functions across multiple I / O modules by providing corresponding conversion of the superior behavior description. Functions that only relate locally to the individual I / O modules can be taken over autonomously by the respective individual I / O modules. Therefore, these functions can be taken over when converting to the control program and configuration of the respective I / O module. This has many structural advantages in terms of its simplicity, structuring, energy requirements and the autonomy of the subsystems involved. For example, in the event of a bus connection failure, the IOM local functions can continue to be available. The low energy requirement is due to the fact that a large part of the events can be processed locally by the IOM and there is little need for interaction with other components.

[0040] The control program can be provided in bytecode, which provides a good compromise between flexibility and abstraction for the application. However, this should not limit the present invention in any way. As an alternative to converting the control program into bytecode, the control program can also be converted into machine code that can be directly executed by the CPU. Another alternative is to convert the bytecode into machine code as well (two consecutive conversions).

[0041] Further details of these embodiments of the invention can be understood in greater detail with the aid of the description of the figures.

[0042] In another aspect of the present invention, a device for data processing is provided. The device includes components for performing the method according to any aspect disclosed herein. The device can be designed as a data processing device associated with a user in the sense of a client (as described above) and configured to perform the corresponding steps. The device can also be designed as a data processing device associated with a cloud computing environment in the sense of a server (as described above) and configured to perform the corresponding steps.

[0043] In another aspect of the present invention, a computer program is provided, comprising instructions which, when executed by a computer, arrange the computer to perform a method according to any aspect disclosed herein.

[0044] Although some aspects are described in the context of an apparatus, it is clear that these aspects also represent a description of a corresponding method, where a block or a device corresponds to a method step or a function of a method step. Similarly, aspects described in the context of a method step also represent a description of the characteristics of the corresponding block or element or corresponding device.

[0045] Embodiments of the present invention may be implemented in a computer system. The computer system may be a local computer device (e.g., a personal computer, laptop, tablet, or mobile phone) having one or more processors and one or more storage devices; or it may be a distributed computer system (e.g., a cloud computing system having one or more processors or one or more storage devices distributed at different locations, such as at a local client and / or at one or more remote server farms and / or data centers). The computer system may include any circuit or combination of circuits. In one embodiment, the computer system may include one or more processors, which may be of any type. Depending on the local usage, a processor may refer to any type of computing circuit, such as, but not limited to, a microprocessor, a microcontroller, a microprocessor with a complex instruction set (CISC), a microprocessor with a reduced instruction set (RISC), a microprocessor with a very long instruction word (VLIW), a graphics processor, a digital signal processor (DSP), a multi-core processor, a field programmable gate array (FPGA), or any other type of processor or processing circuit. Other types of circuits that may be included in a computer system may be custom circuits, application specific integrated circuits (ASICs), or similar circuits, such as one or more circuits (e.g., communication circuits) used in wireless devices such as mobile phones, tablets, laptops, walkie-talkies, and similar electronic systems. A computer system may include one or more storage devices, which may include one or more memory elements suitable for the respective application, such as main memory in the form of random access memory (RAM), one or more hard disks, and / or one or more drives for handling removable media such as CDs, flash memory cards, DVDs, etc. A computer system may also include a display device, one or more speakers, and a keyboard and / or a controller, which may include a mouse, trackball, touch screen, voice recognition device, or any other device that allows a system user to input information into the computer system and receive information from it.

[0046] Some or all of the method steps may be performed by (or using) a hardware device, such as a processor, a microprocessor, a programmable computer or an electronic circuit. In some embodiments, one or more main method steps may be performed by such a device.

[0047] Depending on the specific implementation requirements, embodiments of the present invention may be implemented in hardware or software. This implementation may be performed using a non-volatile storage medium, such as a digital storage medium, such as a floppy disk, DVD, Blu-ray, CD, ROM, PROM, EPROM, EEPROM, or flash memory, on which electronically readable control signals are stored, which control signals cooperate (or can cooperate) with a programmable computer system to implement the corresponding method. Thus, the digital storage medium may be computer-readable.

[0048] Some exemplary embodiments according to the invention comprise a data medium having electronically readable control signals, which can interact with a programmable computer system in such a way that one of the methods described herein is carried out.

[0049] Generally speaking, the embodiments of the present invention can be implemented as a computer program product having a program code, wherein when the computer program product is run on a computer, the program code effectively performs one of the methods. The program code can be stored on a machine-readable carrier, for example.

[0050] Other exemplary embodiments comprise the computer program for performing one of the methods described herein, stored on a machine-readable carrier.

[0051] In other words, one exemplary embodiment of the present invention is, therefore, a computer program having a program code for performing one of the methods described herein, when the computer program runs on a computer.

[0052] Therefore, another embodiment of the present invention is a storage medium (or data carrier or computer-readable medium) comprising a computer program stored thereon for performing one of the methods described herein when executed by a processor. The data carrier, digital storage medium or recorded medium is typically tangible and / or non-transitory. Another embodiment of the present invention is a device comprising a processor and a storage medium as described herein.

[0053] Therefore, another embodiment of the present invention is a data stream or a signal sequence, which represents a computer program for executing one of the methods described herein. For example, the data stream or the signal sequence can be configured such that it is transmitted via a data communication connection (e.g., via the Internet).

[0054] A further embodiment comprises a processing means, for example a computer or a programmable logic device, configured or adapted to perform one of the methods described herein.

[0055] A further exemplary embodiment comprises a computer on which the computer program for performing one of the methods described herein is installed.

[0056] Another embodiment according to the present invention includes a device or system configured to transmit (e.g., electronically or optically) to a receiver a computer program for performing one of the methods described herein. The receiver may be, for example, a computer, a mobile device, a storage device, etc. The device or system may include, for example, a file server for transmitting the computer program to the receiver.

[0057] In some embodiments, a programmable logic device (e.g., a field programmable gate array (FPGA)) can be used to perform some or all of the functions of the methods described herein. In some embodiments, a field programmable gate array can be used in conjunction with a microprocessor to perform one of the methods described herein. Typically, these methods are preferably performed by any hardware device. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The preferred embodiments of the present disclosure are described below with reference to the accompanying drawings:

[0059] Figure 1 An exemplary system, in particular for building automation, is shown, in which the present invention can be used according to one exemplary embodiment;

[0060] Figure 2-Figure 6 A schematic diagram showing an exemplary implementation of a method according to an embodiment of the present invention is shown in detail here:

[0061] Figure 2 A schematic diagram showing the generation of a control program and a configuration for a single automation device, both based on a superordinate behavior description created by a user;

[0062] Figure 3 An exemplary implementation of a timer by a control program and configuration is shown within the context of functional interconnection via variables and if-then instructions;

[0063] Figure 4 An exemplary schematic diagram illustrating the generation of control programs and configurations for multiple components of an overall system;

[0064] Figure 5 A schematic diagram illustrating an example of the interactive interaction of different components of a system, including the distribution of local functions to I / O modules and masters and the allocation of cross-module functions to masters, in order to form a complete system overall function;

[0065] Figure 6 An exemplary user interface (GUI) is shown for setting a high-level behavior description by a user through a "Configure" GUI. DETAILED DESCRIPTION

[0066] Figure 1An exemplary system is shown in which the present invention may be used according to one embodiment.

[0067] An exemplary infrastructure is shown, which implements automation and / or remote control of elements such as rooms, floors and / or buildings. The system includes one or more master stations 1001 and input / output modules (IOMs) 1010a-c, which are, for example, arranged in sequence on a support rail provided for this purpose. Communication between these elements can be carried out by a suitable communication bus 1031. In addition, an expander 1011 is provided in the system. This expander can also group multiple IOMs 1020a-c. At this, the expander 1011 (together with its associated IOMs) can be located in a physically separated position, particularly relative to the master station 1001, and they can communicate with the master station via a communication bus, particularly a wired communication bus 1030.

[0068] Push buttons, switches, sensors, sockets, lighting devices 1100 and / or actuators 1100 can be connected to the IOMs 1010a-c, 1020a-c (the number of three IOMs shown is merely exemplary and not limiting) and thus controlled by the system. The IOMs thus form an interface to the field.

[0069] IOMs 1010a-c, 1020a-c may be equipped with local control capabilities. For example, these local control capabilities enable switching operations and functions involving only sensors and actuators connected to IOMs 1010a-c, 1020a-c to be controlled autonomously by IOMs 1010a-c, 1020a-c, without requiring interaction with the rest of the system. This reduces the energy requirements of the system itself and improves availability, as the functions implemented by IOMs 1010a-c, 1020a-c remain autonomously and reliably available even if other system components fail (e.g., a master failure).

[0070] Functions that cannot be implemented locally by individual IOMs 1010a-c, 1020a-c are handled by the master station 1001 (or partially by the local extender 1011). Unlike conventional systems, there is no periodic or recurring communication between the master station 1001 (or local extender 1011) and the IOMs 1010a-c, 1020a-c. Instead, communication occurs only when an event occurs that requires processing by the master station 1001 / extender 1011. During periods when no events occur and there is no communication in the system, all components are in energy-saving mode.

[0071] This energy-saving mode can achieve almost complete shutdown of components, especially in the case of IOMs 1010a-c, 1020a-c, which helps to significantly reduce energy requirements in many applications.

[0072] Further optimizations can be set to reduce energy consumption.

[0073] For example, the master station 1001 (or expander 1011) can be designed to distinguish in which communication bus segment a change occurs and only wake up and query those IOMs 1010a-c, 1020a-c from power saving mode. The IOMs 1010a-c, 1020a-c in the segments not affected by the event remain undisturbed in power saving mode.

[0074] Furthermore, provision can be made for only those IOMs 1010a-c, 1020a-c which actually need to update their outputs to wake up from the energy-saving mode when the modified output data are written back to the IOMs 1010a-c, 1020a-c.

[0075] The user does not program the system, but rather configures it. This is done with the help of a graphical user interface.

[0076] Preferably, simple control programs are used, for example as the final result of a correspondingly configured executable, which contain instructions of the "if X then do Y" type (or consist entirely of such instructions). Independence / interchangeability between the individual instructions of the control program can also be ensured. For example, the program can thus be executed with a deterministic result, wherein the execution order of the individual instructions is irrelevant (or alternatively only partially restricted or necessarily partially restricted). This allows for flexibility in execution and parallelization.

[0077] These and other optimizations contribute to the system's low energy requirements and consumption.

[0078] In addition to implementing cross-IOM functions, the master station 1001 can also be designed as a gateway to the "outside world".

[0079] The master station 1001 may connect to a cloud service and thereby obtain a configuration for the system and distribute the configuration to itself and the IOMs 1010a - c , 1020a - c .

[0080] Additionally, the master stations 1010a-c, 1020a-c retain their complete configuration in the master station so that a failed IOM can be replaced even without a connection to the cloud.

[0081] Furthermore, IOMs 1010a-c, 1020a-c retain their configuration so that even after a power outage (power failure), the functionality implemented locally by the IOMs can be provided even in the event of a failure (e.g., a failure of master station 1001). Master station 1001 can be connected to a server (e.g., WAGO) (which can also be part of the cloud) and, from there, regularly receive firmware updates for itself and system components. Conversely, master station 1001 can be designed to upload a log (report / fault log) with fault and crash reports in the event of a fault.

[0082] The master station 1001 preferably provides a connection to an MQTT server for exchange and interaction with third-party services, systems and devices.

[0083] It is also possible to connect the master station 1001 to proprietary and / or open standards (eg MATTER).

[0084] The system is highly energy-efficient, decentralized, autonomous and self-sufficiently organized and the results are most robust.

[0085] The communication bus can be a wired communication bus, in particular a backplane bus on a mounting rail. It can be a serial connection with a transmission rate of, for example, 250 kBit / s.

[0086] Alternatively or additionally, the communication bus may be a wireless communication bus, in particular provided by an RS-485 connection (e.g. with 250 kBit / s). Electromagnetic compatibility is ideal for the desired robustness of the system. In addition to the data connection, a supply voltage may optionally be transmitted for the remote device.

[0087] Just as four-core cables are used, for example, in the KNX fieldbus, they have proven to be particularly suitable for wired communication buses.

[0088] Figure 2 A schematic diagram shows the generation of a control program 200 and a configuration 300 for a single automation device 10 , both based on a superordinate behavior description 100 created by a user.

[0089] The superordinate behavior description 100 may be generated directly or indirectly by the user. For example, this may be done by Figure 6The behavior description 100 cannot be executed directly by the automation device 10. For execution at runtime on the automation device 10, the higher-level behavior description 100 is converted into a control program 200 and a configuration 300. For example, the control program 200 consists only of single-line, interchangeable, simple if-then instructions. The conversion of the higher-level behavior description 100 into the generated control program 200 and the configuration 300 can be performed, for example, on a computer, in the cloud or on a microprocessor of the automation device 10. The three non-limiting examples mentioned here each have their own advantages. In this case, for example, a preferred choice can be made depending on the given performance properties of the respective hardware used. For example, the conversion can also be performed on a master station, wherein the control program 200 and the configuration 300 are generated for the I / O modules connected to the master station.

[0090] Automation device 10 can be designed to receive input signals 500 and provide output signals 600 during operation. It utilizes its configuration 300 and its control program 200. These thus have a feedback effect on the output signals 600 provided in the specific case. The input and / or output signals can be, for example, electrical, optical, and / or electromagnetic signals.

[0091] This solution provides a simple and resource-saving automation solution that has the desired flexible properties. The behavior defined by the user within the framework of the behavior description 100 is provided by the automation device 100 during its runtime.

[0092] Figure 3 An exemplary implementation of a timer by a control program 200 and a configuration 300 is shown within the context of functional interconnection via variables and if-then instructions.

[0093] The control program 200 illustratively includes simple if-then instructions shown here. For example, certain hard-coded functions 400a-c may be provided by the device firmware of the automation device 10. For example, these functions include retrieving a specific value for "Input #1" 400a, which is applied to the automation device via an incoming signal 500 and / or provided in other ways herein. For example, these functions include setting a specific value for "Output #1" 400c, which is provided by an outgoing signal 600 from the automation device 10.

[0094] A timer (timer / time limiter) 400b can be provided by the instructions of the control program shown. The desired holding time 301 of the timer 400b is obtained, for example, from the configuration 300 of the automation device 10. The abstract timer function 400b is provided, for example, by the device firmware of the automation device 10.

[0095] As should be emphasized, the example described is only a very simple one. More complex interactions (including timer structures) can be created using these means. In particular, a simple control program 200 having only simple, single-line if-then instructions is required for execution by the automation device 10.

[0096] The control program 200 can be checked particularly easily, and in particular in preparation for the first actual execution, for the effects of errors, crashes and / or uncontrolled behavior of the automation system.

[0097] Figure 4 An exemplary schematic diagram is shown for generating control programs and configurations for multiple components of an overall system.

[0098] The exemplary overall system consists of a master station 1001 and two exemplary I / O modules 1010a and 1010b, which can be connected to each other via a bus. Thus, a single, consistent behavior description 100 generates multiple, consistent configurations 300a, 300b, and 300c, as well as control programs 200a, 200b, and 200c. Within the method, the individual configurations 300a-c and control programs 200a-c must be coordinated with one another. The resulting runtime behavior of the overall system is therefore less prone to errors in terms of component interactions and, therefore, extremely stable, predictable, and reliable in a system-internal manner. Furthermore, any errors that may occur can be more easily "tracked," i.e., traced back to their cause.

[0099] Figure 5 An exemplary schematic diagram shows the interaction of different components of a system, including the distribution of local functions to I / O modules and masters and the assignment of cross-module functions to masters, in order to form a complete system functionality.

[0100] In the illustrated system, a preferred task distribution is exemplarily designed as follows: local functions of master station 1001 itself and cross-module or cross-system functions 701 are either taken over by master station 1001 or, when the behavior description is converted, allocated to master station 1001 during the generation of control programs 200a-c and configurations 300a-c. This can conserve resources, allowing I / O modules to typically be equipped with less powerful, more energy-efficient processors. In the illustrated example, only I / O module-local functions 710 are assigned to I / O modules 1010a and 1010b or taken over by these modules during system runtime. In another example, the desired distribution of different task types to system components can be determined within the framework of a higher-level behavior description (in a simple and / or system-wide manner). Through the conversion, these inputs can be incorporated into control programs 200a-c and configurations 300a-c, thereby saving resources (e.g., unnecessary functions are not provided locally or even loaded into memory). Correct system functionality is ensured because the precise coordination of the individual control programs 200a-c and configurations 300a-c is already predetermined in a system- and method-integrated manner. Therefore, even after the actual "configuration" of the system functionality, resources and hardware can be further optimized without the user having to manually make larger, more complex changes.

[0101] Reference Signs List

[0102] 10 Automation Equipment

[0103] 100 (Superior) Behavior Description

[0104] 200, 200a-c Control Program

[0105] 300, 300a-c configuration

[0106] 301 Configuration parameters (here: timer duration)

[0107] 400a-c Hard-coded functions (implemented in firmware): input, timer, output (instance)

[0108] 500 signal (inbound)

[0109] 600 signal (outbound / generated)

[0110] 700 interactive full system functionality

[0111] 701 Local functions (with respect to the master) and I / O cross-module functions

[0112] 710 I / O module local functions

[0113] 1001 Main Station

[0114] 1010a-c I / O Module (IOM)

[0115] 1020a-c I / O Module (IOM)

[0116] 1011 Expander

[0117] 1030 Communication bus (wired)

[0118] 1031 Communication Bus

[0119] 1100 Practical Equipment / Lighting Devices (Examples) / Actuators (Examples)

Claims

1. A method for configuring a programmable automation device (10), wherein: The method comprises: receiving a user-defined behavior description (100) for defining a runtime behavior of an automation device (10); Automatically generating a control program (200) and a configuration (300) for an automation device (10) based on a behavior description (100); and A control program (200) and configuration (300) are provided.

2. The method according to claim 1, wherein The behavioral description (100) is received in a form that is not directly usable for execution by a microcontroller and / or interpreter.

3. The method according to claim 1, wherein: The control program (200) can be executed on the firmware of the automation device (10).

4. The method according to claim 1, wherein: The generated control program (200) includes at least one instruction.

5. The method according to claim 4, wherein The at least one instruction relates one or more inputs (400a, 500) of the automation device (10) and / or one or more outputs (400c, 600) of the automation device (10) and / or one or more functions (400b) provided by the automation device (10) to one another.

6. The method according to claim 4 or 5, wherein: The at least one instruction is an if-then instruction, and the if-then instruction defines at least one condition and at least one action.

7. The method according to claim 6, wherein: The control program (200) only includes if-then instructions.

8. The method according to any one of claims 4 to 7, wherein: The at least one instruction, preferably the entire control program (200), does not contain if instructions, jump commands and / or function definitions.

9. The method according to any one of claims 4 to 8, wherein: The at least one instruction is executed based on an event.

10. The method according to any one of the preceding claims, further comprising: The control program (200) and / or configuration (300) is checked, particularly before executing the control program.

11. The method according to any one of the preceding claims, wherein: The configuration (300) defines at least one value of a variable (301) that can be used by the control program (200).

12. The method according to any one of the preceding claims, wherein: The automation device (10) provides a plurality of callable functions, in particular via the firmware of the automation device (10), and wherein the configuration (300) indicates a subset, in particular a proper subset, of the plurality of callable functions provided to the control program (200).

13. The method according to any one of the preceding claims, wherein: The control program (200) is generated in bytecode, which can be executed by an interpreter that can be run on the automation device (10); or wherein the control program (200) is generated in machine code, and the machine code can be executed by a processor of the automation device (10); or Therein, the control program (200) is first generated in bytecode and the bytecode is subsequently converted into machine code that can be executed by a processor of the automation device (10).

14. The method according to any one of the preceding claims, wherein: The behavior description (100) is a behavior description (100) for defining the runtime behavior of a plurality of (1001, 1010a-c, 1011, 1020a-c) automation devices (10); and In the automatic generation step, a control program (200) and a configuration (300) are provided for each of a plurality of automation devices (10).

15. The method according to one of the preceding claims, which is performed by the automation device (10); in, The steps of providing the control program (200) and the configuration (300) include storage in a memory of the automation device (10).

16. The method according to any one of the preceding claims, which is performed by a data processing device; in, The steps of providing the control program (200) and the configuration (300) include transmitting data to the automation device (10).

17. Method for operating a programmable automation device (10), wherein: The method comprises: providing a control program (200) and a configuration (300), said control program and configuration being generated by a method according to any one of claims 1 to 16; and The control program (200) is executed using the configuration (300).

18. Automation device (10) configured to carry out the method according to one of claims 1 to 15 and / or 17.

19. A data processing device configured to carry out the method according to one of claims 1 to 14 and / or 16 to 17.

20. Automation system, in particular a non-time-critical automation system, such as a building automation system, comprising at least one automation device (10) according to claim 18.

21. A computer program or a computer-readable medium storing said computer program, wherein: The computer program comprises commands which cause the automation device (10) according to claim 18 to execute the method according to one of claims 1 to 15 and / or 17 and / or the data processing device according to claim 19 to execute the method according to one of claims 1 to 14 and / or 16 to 17.

Images