Method and automation system for controlling and / or monitoring machines and / or plants

Abstract

The invention relates to a method for controlling and / or monitoring a machine or a plant by means of an automation system, the functioning of which is controlled by means of a computer. The control is carried out by means of a program running on the computer, which has a real-time operating system, in particular a real-time Linux operating system. The program comprises real-time programs and non-real-time programs running in a runtime environment above the operating system.

Description

Technical Field

[0001] The present invention relates to a method for controlling and / or monitoring machines or equipment using an automated system, and an automated system for controlling and / or monitoring machines and / or equipment. Background Technology

[0002] As technological processes become increasingly automated, the complexity of control and / or monitoring tasks that must be performed as independently as possible of human intervention in a predetermined manner is constantly growing. DIN IV 19233 defines automation as the assembly of a device that enables it to function fully or partially in a predetermined manner without human intervention.

[0003] Computers offer enormous potential, particularly in complex automation tasks. This potential is largely based on the relatively free programming capabilities of computers. In this context, the operating system typically forms the interface between computer hardware and computer programs. These programs generally do not directly access the computer hardware but instead access the functionalities provided by the operating system. This achieves separation between programs and computer hardware, meaning that software developers do not need to conduct in-depth research into the characteristics of the hardware but only need to design software compatible with the corresponding operating system. This allows for a large amount of compatible software—programs that can run on the corresponding operating system—to be used with commercially available or popular, free operating systems.

[0004] However, operating systems commonly used in computers such as servers, clients, desktops, and laptops typically lack real-time capabilities. Real-time capability is also not essential for most applications used on such computers. One component of the operating system is responsible for resource allocation. This component is usually called the "scheduler." In this case, the operating system may have multiple such schedulers managing different computer resources. The scheduler manages processes and their execution. For example, time-slice-driven and / or priority-driven scheduling methods may be used. Specifically, the scheduler determines the order in which various programs can access the corresponding hardware resources. These hardware resources may include processors, processor cores, memory, hard disks, network interface card (NIC) input / output buffers, etc.

[0005] However, computers with traditional operating systems can only be used for automation tasks to a limited extent because common operating systems outside of automation technology often cannot meet the real-time requirements of programs running on an operating system in conjunction with an automation system. Programs in the field of automation technology often have real-time requirements, for example, because a particular program controls a specific actuator for control purposes. If the actuator receives control commands too late and responds accordingly too late, this can have a fatal impact on the continuous operation of the machine or equipment.

[0006] Therefore, technical solutions have been developed in the field of automation technology. These solutions typically involve real-time operating systems running on embedded computers within programmable logic controllers (PLCs). However, these real-time operating systems are usually highly specialized and primarily proprietary systems, with virtually no software available other than programs for automation functions. This is particularly relevant to the typical standard software used in standard operating systems such as Windows or Linux. This standard software typically cannot run on these proprietary systems. Furthermore, these proprietary systems use corresponding proprietary libraries, and the operating system's calls to these libraries are also proprietary, thus leading to incompatibility. The cost of providing corresponding "standard software" for each specific type of such proprietary system is simply too high; therefore, only a very limited amount of software is actually available for these systems.

[0007] These real-time systems are optimized for the execution of corresponding real-time programs in terms of their software architecture. Programs written for non-cyclic, event-oriented operations cannot or are difficult to run on these systems. This is especially relevant when real-time and non-real-time programs share resources.

[0008] To combine the capabilities of conventional (non-real-time) computers with the schemes of real-time systems in automation technology, several measures have been taken. One such measure is using a hypervisor as an intermediate layer between the computer hardware and the operating system. With this architecture, real-time and non-real-time operating systems can run in parallel. In this case, the hypervisor ensures the allocation of hardware resources among these operating systems through continuous "switching back and forth."

[0009] However, a drawback of using such a management program is its high hardware specificity. If, for example, such a management program is used with a specific programmable logic controller, the program must always be compatible with the corresponding hardware. This creates an undesirable hardware-software dependency between the hardware and the management program.

[0010] Furthermore, the management system strictly separates the real-time operating system (RTOS) from the non-RTOS. This makes communication between programs running on the ROS and programs running on the non-RTOS much more difficult.

[0011] Therefore, the resulting systems are typically highly specialized and can only be used with or are compatible with certain hardware. The aforementioned advantages of computer technology—the "openness" of systems that can be extended through new programs and the resulting independence from the hardware used—can, in turn, sacrifice or interfere with real-time capabilities.

[0012] To address the aforementioned issues, a conventional "open" operating system is typically used, possessing either real-time capabilities or the ability to acquire them through appropriate extensions. This operating system could be, for example, Linux. In this case, to establish the system's "openness"—that is, to allow users to match the system's functionality to their needs—users usually have the opportunity to access the system with so-called "root privileges," meaning they can make extensive modifications to the system.

[0013] Using root privileges has serious drawbacks. Firstly, it presents significant security vulnerabilities because it grants a vast amount of access. Secondly, real-time behavior can be unstable as individual packages uncontrollably consume resources such as storage and computation time. Furthermore, the knowledge required for such kernel-related interventions in the operating system is not widely disseminated; therefore, users can only undertake these interventions at a high cost and with corresponding risks of errors during the process. Such interventions also make software lifecycle management (updates, security patches, etc.) more difficult or virtually impossible. Ultimately, however, such a system merely embodies the coexistence of real-time and non-real-time programs. It does not coordinate real-time and non-real-time components, particularly for achieving stable real-time operation while simultaneously employing non-real-time programs. Summary of the Invention

[0014] Therefore, the object of the present invention is to provide a method and an automated system in which the above-mentioned disadvantages are not present or at least to a lesser extent.

[0015] The solution of the present invention to achieve the above-mentioned objectives lies in the method and automated system having the features of the independent claims. The features of the dependent claims relate to advantageous implementations.

[0016] The method is configured to control the functions of the automated system using a computer. In this case, control is achieved through programs running on the computer. For this purpose, the computer has a real-time operating system. This real-time operating system can, in particular, be a real-time Linux operating system. This operating system, specifically Linux with corresponding real-time capability extensions (preemptive RT patches or PREEMPT_RT patches), is particularly known as "Linux RT". The method is configured to run these programs, including real-time and non-real-time programs, in a runtime environment above the operating system. It has been shown that by using this runtime environment, particularly as a layer between the programs and the operating system in the software architecture upon which the method is based, both real-time and non-real-time programs can run simultaneously, which on the one hand ensures high stability and security of the method. Furthermore, a high degree of modularity can be implemented at the software level to adapt and / or extend the software used to implement the method.

[0017] In particular, the allocation of computer resources ensures that real-time programs have sufficient resources to meet their corresponding real-time requirements. Specifically, the runtime environment determines the execution priority of programs. In this case, the runtime environment allocates real-time programs to real-time execution time slices. Furthermore, the runtime environment determines the appropriate time points when non-real-time applications can run without impairing the real-time execution of real-time programs. Through the runtime environment, and especially with the aid of instructions related to execution priority, these programs are transmitted to the operating system for execution. In this case, the runtime environment ensures that the execution of real-time programs to meet their corresponding real-time requirements is not affected by non-real-time programs.

[0018] Specifically, programs run in sandboxes. Preferably, each program runs in its own sandbox. Running in a sandbox means isolating each program from the rest of the system. This prevents errors occurring during the execution of a single program from negatively impacting the entire system or other programs; these errors include illegal operations (such as division by zero), unauthorized memory access, stack errors, etc. This is particularly important given the real-time requirements that must be met.

[0019] Each program can run in its own sandbox. Alternatively and / or as a supplement, multiple programs can run in a shared sandbox. In this case, programs can be assigned to sandboxes based on defined conditions by the runtime environment. These conditions may specifically be storage requirements, computing power requirements, and / or real-time behavior.

[0020] Running in a sandbox specifically means that programs do not use shared or global variables. This prevents incorrect handling of variables by one program from negatively impacting the operation of another program.

[0021] Furthermore, running in a sandbox specifically means that no program accesses shared memory areas. This is particularly relevant to the use of main memory.

[0022] Furthermore, the method can be configured such that these programs do not use shared program components. These shared program components can, in particular, be software libraries, also known as "libraries." Such shared program components create dependencies between these programs. While using such shared program components has the advantage that the component only needs to be stored once on the respective computer, and then all programs using the shared component can call it from there, the disadvantage is that a version change in one program may cause a version change in the shared component, which in turn may lead to incompatibility with other programs using the same shared component. By avoiding shared program components, modularity is ensured, allowing individual programs to be replaced without affecting other programs. In principle, different programs can use the same program components. However, these program components are then stored separately on non-volatile data carriers, specifically for each program using the respective program component. In other words, this means that program components used by multiple programs are stored in multiple copies on non-volatile memory. In this case, each copy of a program component can only be accessed by a specific program. In this case, each program using a program component only accesses its "respective copy" of the corresponding program component. In other words, programs will not, in particular, share access to the same area of ​​non-volatile memory so that multiple programs can use these shared program components.

[0023] In particular, the runtime environment can prevent root access through these programs. This enhances system security. Furthermore, the runtime environment can monitor, block, and / or restrict all access by these programs to the functions of the real-time operating system beneath the runtime environment. In addition, the runtime environment can control, monitor, block, and / or restrict communication between programs and / or between programs and remote stations (e.g., peripheral devices) outside the runtime environment. This further enhances system security. Specifically, it can make attacks through malware introduced into the system in a manner "hidden" within individual programs more difficult or even preventable.

[0024] Specifically, the runtime environment controls communication between programs. This communication is particularly achieved through message passing systems. In this case, the runtime environment acts as message-oriented intermediary software or provides such intermediary software to the programs. Controlled communication between programs ensures, through the runtime environment, that individual programs, especially those running in their respective sandboxes, do not adversely affect each other. This also ensures a high degree of system security and modularity. Communication between programs via message passing allows each program to run as independently as possible. Furthermore, programs can be extended, updated, added to, and / or deleted independently. This improves the modularity of automated systems, especially at the software level. For example, message passing allows for a time delay between sending and receiving messages. If, for example, one program calls a function of another program, that program can "wait" for a relatively long period of time for the other program's response. This increases the flexibility in allocating resources to programs running in their respective sandboxes. Furthermore, the receiver only needs to understand the content of the "message." In particular, individual programs running in the runtime environment do not directly call any functions of other programs running in the runtime environment and / or access the memory occupied by other programs. This increases the independence of these programs from one another, thereby improving the modularity of the software in the automation system.

[0025] Programs can communicate with each other, especially using the publish-subscribe messaging pattern. The biggest advantage of this pattern is that the sender doesn't need to know who the message recipients should be. Furthermore, compared to broadcast or messaging systems where messages are ultimately forwarded to all eligible recipients, the publish-subscribe messaging pattern reduces system load because only the recipients receive each "message," and corresponding "messages" are sent to these recipients (subscribers).

[0026] As an alternative and / or supplementary solution, another communication structure (such as OPC UA) can also be used for communication between programs.

[0027] Advantageously, nanomessaging systems such as NanoMSG NNG can be used for inter-program communication. These systems are particularly advantageous in terms of their relatively low system resource requirements. The advantage of OPC UA lies in its being a unified and cross-manufacturer open standard.

[0028] Furthermore, the method can configure communication between the program and peripheral devices (e.g., actuators or sensors). For example, communication can be achieved through a service-oriented communication architecture, such as OPC UA. Specifically, a real-time version of OPC UA, such as OPC UA-TSN, can be used. In particular, the communication between the program and peripheral devices is controlled through the runtime environment. Specifically, the runtime environment mediates the communication between each program and the operating system. The operating system is responsible for mediating the communication between the runtime environment and the hardware.

[0029] Programs that can run in a runtime environment can be provided by a computer system via a data link. This allows new programs to be transferred to the computer used to implement the methods in a simple manner, such as via the Internet, and their potential uses to be expanded. For example, programs can be provided by a computer system in the form of a software store.

[0030] The method can be configured to provide an integrated development environment that supports the creation of programs that can run in a runtime environment.

[0031] The method can be configured, particularly through a runtime environment, to manage programs. This is especially applicable to programs provided by a computer system via a data link. Specifically, the runtime environment can provide a package manager to manage software packages containing the corresponding programs. In this case, programs and / or software packages are received from the computer system via a data link and / or from the development environment, particularly through the runtime environment and, in particular, the package manager. Specifically, sandboxes are allocated to programs through the runtime environment and, in particular, the package manager. Specifically, the runtime environment and, in particular, the package manager can also initiate the execution of programs. In this case, the package manager receives these programs, particularly in a runnable state, particularly as packages containing runnable program code and configuration data and / or libraries. In this case, these programs are stored, in particular, on a computer data carrier, such that the program code and the program's configuration data are stored separately from other software on the data carrier.

[0032] Real-time programs are particularly suitable for controlling electric drive systems and / or multiple electric drive systems. Electric drive systems are a typical component of machines and / or equipment, and their control has relatively high real-time requirements due to the high operating speeds of modern machines and / or equipment. On the other hand, highly automated machines and / or equipment often require precise coordination of the movements of multiple (or even a large number) driven axes.

[0033] Accordingly, when implementing the method, at least one of the real-time programs can control the motion, speed, and / or position of the electric drive system. In particular, this control can be performed using a computer-controlled frequency converter of the drive system. The speed can specifically be the rotational speed and / or angular velocity of the driven shaft of the drive system. The position can specifically be the angular position occupied by the shaft of the driven system, and / or the motion can specifically be the angular range to be covered by the rotation of the shaft of the drive system.

[0034] As an alternative and / or supplementary option, when implementing the method, at least one of the real-time programs can coordinate the position, movement, and / or speed of multiple axes driven by the electric drive system. In this case, these axes can be axes of the same machine and / or equipment.

[0035] However, as an alternative and / or supplementary approach, when implementing the method, at least one of the real-time programs can also coordinate the position, movement, and / or speed of the driven axes of different machines and / or devices. For example, a scenario can be envisioned where a robot removes a workpiece from a conveyor belt and places it in a specific location. In this case, the program can coordinate the movement of the driven axes of the conveyor belt and the movement of the robot's driven axes.

[0036] Of course, as an alternative and / or supplementary solution, when implementing the method, at least one of the real-time programs can, in principle, control the position, motion and / or speed of at least one axis driven by an electric drive system, taking into account at least any one peripheral device. In particular, the control of position, motion and / or speed can be coordinated with the action of the actuator and / or the position, motion and / or speed can be controlled based on the signals from the sensors.

[0037] An automation system for machines or equipment has multiple peripheral devices connected to a computer via data links, and the automation system is particularly suitable for implementing the methods described above. The peripheral devices can be all types of field devices, particularly sensors and / or actuators. These peripheral devices are used to perform automation functions, such as the driving function of electric motors, particularly acceleration and deceleration. In this case, the peripheral device can be a motor controller, for example, using a frequency converter. However, these peripheral devices can also be any other sensors and / or actuators used to achieve the positioning contours of a pick-and-place robot (e.g., a robot with triangular kinematics). The automation function can also be a tracking management function, such as visual tracking of a workpiece. In this regard, the peripheral device can be, for example, a camera. The computer has a real-time operating system, particularly a real-time Linux operating system. Furthermore, the automation system has programs for controlling the operation of the automation functions implemented through the peripheral devices, and these programs can run in a runtime environment above the operating system. In this case, these programs include real-time programs and non-real-time programs.

[0038] The automation system may include an identification module that connects to a computer via a data link and identifies the programs required by a specific machine, device, and / or peripheral device. These identification modules may, for example, have a memory module storing instructions that first retrieve the specific program from the computer system via the data link and then run it in the runtime environment. This enables a "plug-and-play" function, where only the required software needs to be identified by the identification module. These identification modules are assigned to machines, devices, and / or peripheral devices. These identification modules are specifically components of the machines, devices, and / or peripheral devices. If the devices, machines, and / or peripheral devices are integrated into the automation system via data cables, the corresponding identification modules are also integrated into the automation system. Communication between the runtime environment and the identification modules is particularly possible through integration via data cables.

[0039] As an alternative and / or supplementary solution, programs and / or configuration files specific to the corresponding machine, device, and / or peripheral can also be integrated into the memory module of the identification module. In this variant, when the machine, device, and / or peripheral are integrated into the automation system, the software required to operate the machine, device, and / or peripheral is directly provided to the runtime environment. Of course, a hybrid approach can also be adopted for the design of the identification module described above. For example, a "base version" of the software can be provided, and a data link can be used to obtain updates and / or extensions that will be provided at a later time from the computer system, for example, via the data link.

[0040] The automation system can include peripherals for multiple machines. In this regard, a particular advantage of the automation system is its scalability. Theoretically, provided the computer has sufficient resources to ensure the smooth operation of programs, especially real-time programs, the computer can control and / or monitor any number of peripherals for any number of machines and / or devices. The allocation between the computer and the machines, devices, and / or peripherals is also flexible; that is, the allocation can be changed effortlessly. For example, other machines, devices, and / or peripherals can be subsequently allocated to the computer at any time, and then controlled and / or monitored by the same computer. Similarly, machines, devices, and / or peripherals controlled and / or monitored by the first computer can subsequently be allocated to another computer instead of the first computer, and then controlled and / or monitored by that other computer. This approach represents a significant advancement compared to existing technologies to date, where the corresponding control and / or monitoring units (e.g., programmable logic controllers) are permanently allocated to machines, devices, and / or peripherals, and this allocation is subsequently difficult to change or requires considerable effort to change.

[0041] Because the computer only needs to be compatible with the operating system under its runtime environment, relatively low-cost standard hardware (such as industrial PCs or even regular PCs) can be used. A large number of peripheral devices can be automated, and large, complex production equipment can be controlled and / or monitored through a single central computer. If the resources of one computer are insufficient, multiple computers can be used to control complex production processes, such as an entire factory. In this case, individual devices and / or machines, along with their peripherals to be connected to the computers, can be allocated to these computers, thus making rational use of the required resources. This eliminates the need for the large number of distributed control units commonly used to date, resulting in cost savings, particularly through simplified maintenance of the entire system, and consequently reducing costs over the entire lifecycle. Attached Figure Description

[0042] Other practical embodiments and advantages of the present invention will be described below with reference to the accompanying drawings. Wherein:

[0043] Figure 1 is a schematic diagram of the computer software architecture of an automation system based on existing technology.

[0044] Figure 2 This is a schematic diagram of the computer software architecture of an exemplary automation system according to the present invention.

[0045] Figure 3 This is a schematic diagram illustrating the working principle of an exemplary automated system according to the present invention.

[0046] Figure 4 The present invention describes the working principle of an exemplary automated system for controlling and / or monitoring the operation of multiple machines and / or devices. Detailed Implementation

[0047] Figure 1 illustrates, exemplarily, the software architecture of a computer 10 in an automation system according to the prior art. A hypervisor 18 serves as another layer of the software architecture, situated between the hardware layer 12 and the layer consisting of a real-time operating system 14 and a non-real-time operating system 16. The hypervisor 18 ensures the allocation of resources for the hardware 12 between the real-time operating system 14 and the non-real-time operating system 16 by continuously switching back and forth.

[0048] With this software architecture, a commercially available operating system such as Windows or Linux can be used as the non-real-time operating system 16. The real-time operating system 14 is typically a dedicated operating system that allows the real-time program 20 to run in an application layer overlaid on the real-time operating system 14. Correspondingly, the non-real-time operating system 16 allows the non-real-time program 22 to run, thus enabling it to run alongside the real-time program 20 on the same computer 10.

[0049] Although the hypervisor 18 provides the hardware 12 of the computer 10 to one of these systems as needed, from the user's perspective, there is at least a clearly simultaneous availability of the computer 10 for real-time programs 20 and non-real-time programs 22. The real-time programs can be used, in particular, for controlling and / or monitoring machines and / or equipment, while the non-real-time programs can be, for example, CAD applications, programs for generating documents (such as PDF generators), or programs for document generation (such as electronic logs of machines or equipment). The non-real-time applications 22 are typically available on commercially available non-real-time operating systems, such as Windows. Therefore, the use of the hypervisor 18 allows such software to be easily integrated into the highly specialized infrastructure of conventional programmable logic controllers according to existing technology. However, a high degree of relevance remains regarding the compatibility of the hardware 12 with the hypervisor 18. Furthermore, there are the disadvantages described above, which arise from the relatively strict separation between the real-time operating system 14 and the non-real-time operating system 16.

[0050] Figure 2This is a schematic diagram of an exemplary software architecture of a computer 10 for an exemplary automation system according to the present invention. In this architecture, the hardware 12 of the computer 10 also forms the bottom layer. Overlaid on this bottom layer is a real-time operating system 14. The real-time operating system 14 may in particular be a Linux operating system, which has the necessary real-time capabilities, for example with the help of appropriate extensions 24 (such as the so-called "PREEMPT_RT patch"). Overlaid on the layer of the real-time operating system 14 is a runtime environment 26. The runtime environment represents the link between the application layer with real-time programs 20 and non-real-time programs 22 and the real-time operating system 14. The real-time programs 20 and non-real-time programs 22 run in the runtime environment 26.

[0051] In implementing a method for controlling and / or monitoring an automated system of machines and / or equipment, computer 10 operates the functions of the automated system through programs 20, 22, particularly through real-time program 20.

[0052] Within this framework, resources of computer 10, particularly hardware 12, are allocated to ensure that real-time program 20 has sufficient resources to meet the corresponding real-time requirements. Specifically, the execution priority of programs 20 and 22 is determined by runtime environment 26.

[0053] Specifically, real-time program 20 and non-real-time program 22 run in sandbox 28. In this case, each program 20 or 22 can run in its own sandbox 28. However, multiple programs 20 and 22 can also run in a shared sandbox 28.

[0054] Figure 3 An exemplary automation system for machine and / or device 30 is shown. The automation system includes a computer 10 having a real-time operating system 14, on which a runtime environment 26 is superimposed.

[0055] Peripheral device 32 is connected to computer 10 via data link 34. These data lines enable communication between programs 20 and 22, and between peripheral device 32. Peripheral devices are, in particular, field devices such as actuators and / or sensors. Peripheral devices may be, for example, power drives that are powered and controlled, particularly by means of frequency converters. Communication can be achieved via data link according to the OPC UA specification. In this case, communication between programs 20 and 22, and between peripheral device 32, is controlled, particularly through runtime environment 26.

[0056] The system can communicate with user 36 through user interface 38. User interface 38 may in particular include data input and / or data output devices, such as a display screen, printer, keyboard and / or pointing devices (such as a mouse) and / or touchscreen. In this case, user interface 38 is specifically a component of hardware 12. In this way, user 36 can actively influence the automation system, particularly directly influencing the methods by which the automation system is controlled and / or monitored using computer 10.

[0057] Programs 20 and 22 can be provided by computer system 40 via data link 42. Specifically, programs 20 and 22 can be provided in the form of a software store, and the runtime environment 26 can retrieve or call programs 20 and 22 from the software store via data link 42. In this regard, the runtime environment 26 can particularly have a suitable package manager, by which the installation of programs on computer 10 is controlled by the runtime environment 26.

[0058] As an alternative and / or supplementary solution, an integrated development environment 44 may be provided, which allows user 36 to create and / or modify programs 20, 22 through user interface 38. Specifically, the integrated development environment 44 may be provided spatially separate from computer 10 and / or computer system 40. Therefore, the user environment 44 may be software running on any other computer. This facilitates providing new programs 20, 22 for operating the automated system to user 36, for example, from the development engineer's office. A data link 42 may connect the integrated development environment to computer 10 and / or computer system 40, for example, via the Internet and / or via an intranet.

[0059] Furthermore, the machine and / or device 30 may have an identification module 46. This identification module is also connected to the computer 10 via a data link 34. In this case, the data link 34 between the computer 10 and the identification module 46 is also controlled by the runtime environment 26. The identification module 46 may contain a suitable data carrier with stored real-time programs 20, non-real-time programs 22, and / or data 48 related to the device and / or machine. This allows the computer 10 to identify the machine and / or device 30. In this case, for example, the programs 20, 22 required for the method of controlling and / or monitoring the automated system of the machine and / or device 30 can be obtained independently of the computer system 40 via the data link 42. However, as an alternative and / or supplementary solution, these programs can also be provided to the machine and / or device 30 by means of the identification module 46. This allows the operation of the automated system to be realized according to the "plug and play" principle after the data link 34 between the components of the automated system assigned to the machine and / or device 30 and the computer 10 is established.

[0060] This type of automated system is highly variable. Therefore, it can be like... Figure 4 An automated system, as exemplified, comprises peripheral devices 32 of multiple machines and / or devices 30. All of these peripheral devices 32 can be connected to a single computer 10. This method of automation allows for advantageous adaptation to changing requirements, particularly by the ease with which individual programs 20, 22 can be supplemented, replaced, and / or updated. Replacing the hardware 12 of the computer 10 is also relatively simple, as the runtime environment 26 allows for the use of common real-time operating systems, such as Linux. This provides greater flexibility in selecting the hardware 12 of the computer 10. Subsequently, integrating the peripheral devices 32, along with other machines and / or devices 30, into or removing them from the automation system and / or replacing them is also relatively straightforward. Through the modularity of the system implemented in this way, the lifecycle cost of such an automated system can be reduced compared to traditional solutions that are relatively difficult to adapt accordingly.

[0061] The features of the invention disclosed in this specification, drawings, and claims (as individual features or combinations thereof) are particularly important for implementing the invention in its various embodiments. The invention is not limited to the described embodiments. Modifications may be made to the invention within the scope of the claims and taking into account the knowledge of those skilled in the art.

[0062] Appendix Label Table

[0063] 10 Computers

[0064] 12 Hardware

[0065] 14 Real-time Operating Systems

[0066] 16. Non-real-time operating systems

[0067] 18 Management Procedures

[0068] 20 Real-time Programs

[0069] 22 Non-real-time programs

[0070] 24. Extension

[0071] 26 Runtime Environment

[0072] 28 Sandbox

[0073] 30 Equipment / Machines

[0074] 32 Peripheral Equipment

[0075] 34 Data Link

[0076] 36 users

[0077] 38 User Interface

[0078] 40 Computer Systems

[0079] 42 Data Link

[0080] 44 Development Environment

[0081] 46. ​​Identification Module

[0082] 48 data

Claims

1. A method for controlling and / or monitoring a machine or equipment (30), wherein the functions of an automated system are controlled by means of a computer (10). The control is performed by programs (20, 22) running on the computer (10). The computer (10) described therein has a real-time operating system (14), The program includes a real-time program (20) and a non-real-time program (22) running in a runtime environment (26) on top of the real-time operating system (14), wherein the runtime environment (26) is used as a layer between the program and the real-time operating system in the software architecture on which the method is based. In implementing the method, at least one of the real-time programs (20) controls the motion, speed, and / or position of the electric drive system. The resources of the computer (10) are allocated to ensure that the real-time program (20) has sufficient resources to meet the corresponding real-time requirements. The runtime environment (26) allocates the real-time program (20) to the real-time running loop time slice. This involves determining the appropriate point in time, through the runtime environment, when non-real-time applications can run without compromising the real-time operation of real-time programs.

2. The method according to claim 1, characterized in that, The program runs in a sandbox (28).

3. The method according to claim 1, characterized in that, Each program (20, 22) runs in its own sandbox (28).

4. The method according to any one of claims 1-3, characterized in that, The programs (20, 22) communicate with each other through a message passing system.

5. The method according to any one of claims 1-3, characterized in that, The procedures (20, 22) utilize the release They communicate with each other by subscribing to messaging systems that follow a messaging pattern.

6. The method according to claim 1, characterized in that, The program (20, 22) communicates with the peripheral device (32) used to perform control functions.

7. The method according to claim 1, characterized in that, The program (20, 22) communicates with the peripheral device (32) used to perform control functions, wherein the communication is carried out through a service-oriented communication architecture.

8. The method according to claim 1, characterized in that, The program (20, 22) communicates with the peripheral device (32) for performing control functions, wherein the communication is conducted through a service-oriented communication architecture in accordance with the OPC UA specification.

9. The method according to claim 1, characterized in that, The computer system (40) provides programs (20, 22) that can run in the runtime environment (26) via a data link (42).

10. The method according to claim 1, characterized in that, An integrated development environment (44) is provided, which supports the creation of programs (20, 22) that can run in the runtime environment (26).

11. The method according to claim 1, characterized in that, The program components used by multiple programs (20, 22) are stored in multiple copies on non-volatile memory.

12. The method according to claim 1, characterized in that, The program components used by multiple programs (20, 22) are stored in multiple copies on non-volatile memory, each copy of which is accessed only by a specific program (20, 22).

13. The method according to claim 1, characterized in that, When implementing the method, at least one of the real-time programs (20) coordinates the position, movement and / or speed of the multiple axes driven by the electric drive system with each other.

14. An automation system for controlling and / or monitoring a machine or equipment (30), comprising the method according to any one of the preceding claims, The automation system has multiple peripheral devices (32) connected to a computer (10) via data links (34) for performing automation functions, wherein the computer (10) has a real-time operating system (14). The automation system described herein has programs (20, 22) for controlling the operation of automation functions implemented through the peripheral device (32), the programs being able to run in a runtime environment (26) on top of the real-time operating system (14). The program includes a real-time program (20) and a non-real-time program (22).

15. The automation system according to claim 14, characterized in that, The automated system includes an identification module (46) connected to the computer (10) via a data link (34) to identify and / or provide the required programs (20, 22).

16. The automation system according to claim 14 or 15, characterized in that, The automation system includes peripheral devices (32) for multiple machines (30).

Images