Method and apparatus for distributing applications and configuring communication connections in distributed industrial automation devices

Abstract

The invention relates to a method and an apparatus for the allocation of application programs (F1,..., F5) and the configuration of communication connections (K1,..., K4) in a distributed industrial automation device, which automation device has a number of networked hardware resources for the application programs (F1,..., F5) and communication resources for the communication connections (K1,..., K4), wherein a total path is formed from a number of sub-paths, which sub-paths are composed of application programs (F1,..., F5) and communication connections (K1,..., K4), wherein the total path is passed through by data signals, and wherein a limit value of a characteristic parameter, in particular a maximum execution time or response time, is preset for the passage of the data signals through the total path. Here, a current value of the characteristic parameter is recorded for at least one passage of a data signal over the total path and over at least one of the sub-paths, a performance data of at least one part of the hardware resources and / or communication resources is subsequently determined, and a reconfiguration of the allocation of the application programs (F1,..., F5) to the hardware resources and / or of the allocation of the communication connections (K1,..., K4) to the communication resources is subsequently carried out at least in the case where at least one actual value does not reach the corresponding limit value. Deployment is thus supported and compliance with the characteristic parameter and the constraints is dynamically ensured by reconfiguration of the deployment.

Description

Technical Field

[0001] The present invention relates to a method and apparatus for distributing applications and configuring communication connections in a distributed industrial automation device. Background Technology

[0002] In the automation industry, key characteristics or criteria, such as the maximum permissible execution time (hereinafter referred to as the "deadline"), are used to design, configure, and operate real-time systems. In "hard" real-time systems, this value must always be adhered to to avoid damage to the machine and the products produced. In "soft" real-time systems, the value (quality, performance) of the results gradually decreases once the deadline is exceeded. Therefore, in real-time systems, the predictability of the application's execution time is crucial for the system's sizing design.

[0003] Application execution time can be estimated through theoretical analysis, but this is very labor-intensive and therefore uneconomical in most cases. Alternatively, the size design can be determined experimentally during the system deployment phase. This experimental approach requires knowledge of the application logic (e.g., parts of the application that are not always executed) and the system (e.g., other applications running on the same hardware and hardware characteristics).

[0004] The high workload (see key points above) stems from the fact that time must be invested in system analysis; otherwise, systems often need to be designed significantly larger than actually required (thus increasing the workload in hardware procurement, configuration, installation, and commissioning). When applications, hardware architecture, or other system components change, re-analysis is necessary. Changes to individual parameters (such as process / flow rate) also require full or partial analysis. Changes and / or "modifications" of existing hardware can also generate variations.

[0005] The document DE 600 15 032 T2 (Balasubramanian "Distributed Real-Time Operating System") discloses a distributed operating system deployed on multiple computing nodes, in which all hardware resources are allocated in advance based on the completion time of the application in order to obtain an acceptable response time.

[0006] Document US 6,487,455 B1 (Balasubramanian's "Distributed Real-Time Operating Systems") is a priori document related to the previously discussed documents and also deals with this type of distributed operating system.

[0007] Patent specification DE 10 2017 214 068 B4 (Ernst et al., “Method, Apparatus and Computer Program for Dynamic Resource Allocation in a Multiprocessor Computer System”) discloses a method for allocating resources in a multiprocessor system, wherein an application program allocates resources based on the current operating parameters of the resources.

[0008] Traditional automation systems often cannot reliably guarantee adherence to predetermined execution times (hard real-time). Control systems typically employ isolated systems to execute control programs. In such systems, users cannot run "third-party" software in parallel outside the automation solution. This allows for limiting fluctuations in execution time. However, if a portion of the program fails to complete within the predetermined maximum time (deadline), an error routine is invoked. This allows users to define appropriate responses to situations where deadlines are exceeded.

[0009] Therefore, existing technologies suffer from the problem that the allocation of applications (software and communication connection configurations) within the existing hardware architecture—the so-called deployment—must be properly designed to ensure that critical parameters or performance limits (constraints) are reliably met. Furthermore, existing technologies also suffer from the problem that once the hardware or software architecture changes, the satisfaction of critical parameters must be re-verified, and the deployment adjusted if necessary. This process is labor-intensive and error-prone in existing technologies; moreover, deployment adjustments typically require personnel with a high level of expertise. Summary of the Invention

[0010] The core idea of ​​this invention to solve this problem is to automate the process of partitioning and allocating application logic (hereinafter referred to as "application") and the communication channels or communication connections required for application networking on available hardware (hardware resources, communication resources), thereby reducing the user's time cost and risk, and monitoring pre-defined requirements (such as deadlines) so as to optimize deployment when necessary.

[0011] The aforementioned technical problem is solved in particular by the method described in the embodiments and the apparatus described in the embodiments.

[0012] This paper proposes a method for allocating applications and configuring communication connections in a distributed industrial automation device, which has a number of networked hardware resources for applications and communication resources for communication connections. The overall path between a first control element (especially a sensor) and a second control element (especially an actuator) is composed of applications on the hardware resources and communication connections on the communication resources. The overall path is formed by a number of sub-paths, each composed of applications and communication connections. Data signals pass through the overall path, and limits on characteristic parameters, particularly maximum execution time or response time, are predefined for the passage of data signals through the overall path. In a first step, the current value of the characteristic parameters is recorded for at least one passage of the data signal along the overall path and at least one of the sub-paths. In a second step, performance data of at least a portion of the hardware resources and / or communication resources is determined. In a third step, the allocation of applications to hardware resources and / or communication connections to communication resources is reorganized if at least one actual value exceeds its respective limit. This method supports deployment and dynamically ensures compliance with characteristic parameters and constraints through the reorganization of deployment.

[0013] The object of the present invention is also addressed by an apparatus for performing the method and a corresponding computer program / computer program product, which enables automatic deployment and redeployment during the execution of these programs. To this end, an apparatus for allocating applications and configuring communication connections in distributed industrial automation is proposed. This apparatus has a number of networked hardware resources for the applications and communication resources for the communication connections. The apparatus includes: a first computer program, particularly a first firmware or operating system routine, for timestamping data signals at a first component of the automation device; a second computer program, particularly a second firmware or operating system routine, for reading and evaluating the timestamps of the data signals at a second component of the automation device; and a third computer program, particularly a third firmware or operating system routine, configured to organize the allocation of applications and / or communication connections according to the method described above. With this apparatus, the various advantages discussed in conjunction with the method can be obtained.

[0014] Advantageous embodiments of the method of the invention are given in the examples, wherein the disclosed features and advantages are equally applicable to the apparatus of the invention. Advantageous variations may be implemented individually or in reasonable combinations.

[0015] According to the present invention, during the operation of the automated device, the degree of resource usage (load rate) by the corresponding application and / or the corresponding communication connection is determined, learned, or stored, which can be an absolute value or a relative value relative to performance data. Based on this data, on the one hand, the resource requirements of the corresponding application or communication connection can be estimated; on the other hand, it can be determined where there are idle or soon-to-be-released resources for process rearrangement or communication connection reconfiguration.

[0016] For different types of hardware and / or communication resources, the extent (absolute or relative) of their usage by the corresponding type of application or communication connection can be determined, learned, or stored separately. This allows for better analysis of the resource requirements of applications, communication connections, and their processes, and enables deployments and / or redeployments to better adapt to available resources.

[0017] In the third step, for the purpose of reorganization, in the event of a feasible or anticipated relocation of the application from the first hardware resource to the second hardware resource, or in the event of a feasible or anticipated relocation of the communication connection from the first communication resource to the second communication resource, the use of the first hardware resource or the first communication resource is considered for the feasible or anticipated relocation of the third application or the third communication connection.

[0018] In the third step, advantageously, based on predetermined reference values ​​or values ​​determined, learned, or stored from previous installation processes or reconfiguration time, the reconfiguration time is used to determine whether, taking into account the maximum predetermined delay during continuous operation, the reconfiguration can be performed during the operation of the automation unit or during its downtime. Based on this decision, the reconfiguration is performed immediately or only during subsequent downtime. This allows the deployment timing to be planned to avoid operational interruptions and to be implemented as much as possible during system operation.

[0019] In one implementation, prior to a new organization of application and / or communication connection allocations, new expected values ​​of characteristic parameters are simulated for the execution of applications and the operation of communication connections on separately planned hardware or communication resources. Reorganization only occurs if the simulation successfully adheres to one or more limits; otherwise, an alternative configuration is sought. Advantageously, measured performance metrics of already operational resources are used in deployment planning, as this automatically accounts for the resource requirements of communication connections for potential third-party software and other processes.

[0020] Therefore, it is advantageous to use the actual values ​​of the data signal passing through the total path and through multiple sub-paths during one or each operation of the communication device to train a machine learning system, particularly a neural network, with each actual value associated with the actual hardware or communication resources used, wherein the trained machine learning system is used to determine the optimal organization of the application and / or communication connection on the currently available hardware or communication resources.

[0021] In the absence of measured values ​​or performance metrics, these performance metrics can be used from libraries, catalogs, or similar sources, and adjusted by a safety factor according to the specific context, such as the security requirements or technical environment of the application involved (factory, simulation, system testing, demonstration, industry, etc.).

[0022] In a simple and easily measurable scenario, bandwidth, typical transmission duration, and / or jitter (fluctuations in transmission duration) can be used as characteristic parameters of communication resources; while computing performance, storage capacity, or specific features (such as the presence of additional cores) can be used as characteristic parameters of hardware resources. Attached Figure Description

[0023] An embodiment of the method according to the present invention will be described below with reference to the accompanying drawings. These drawings also serve to illustrate an apparatus according to the present invention.

[0024] The diagram shows: Figure 1 This illustrates the serial relationship between the application / function and the communication channel located between the data source and the data sink in the overall path through which the data signal travels.

[0025] Figure 2 The diagram schematically illustrates a message message as a data signal, which includes a deadline as a characteristic parameter.

[0026] Figure 3 A schematic diagram of the hardware resources with functions as an application is shown.

[0027] Figure 4 This example shows a simple event handler for processing message (data signal) payloads.

[0028] Figure 5 The diagram illustrates a procedure for monitoring a characteristic parameter (deadline). Detailed Implementation

[0029] In a distributed industrial automation device, the application program and its components should be automatically loaded onto interconnected hardware resources (computing units, computers, controllers, servers, edge devices, etc.) based on "constraints." Constraints are static and quantifiable characteristic parameters, such as the maximum permissible response time or runtime for a data signal (in this case, a message), i.e., the "target time" ("deadline"). The content of the data signal can also be changed during its transit; this application primarily focuses on the overall response time of the entire system (total path) to an event (generated by a data source, such as a sensor) and the resulting response at the data sink (such as an actuator). In other words, this involves, for example, changes in the output value (actuator) caused by a response triggered by a change in the input value (sensor).

[0030] After loading is complete (e.g., after the automation device or part thereof is put into operation / enabled), compliance with the above constraints will be continuously monitored. If the constraints are not met, the corresponding application or part thereof will be reallocated to available hardware resources. In addition to this allocation of the application to available hardware resources (i.e., "deployment"), deployment in this specification also involves the configuration of communication resources, namely, establishing and parameterizing communication connections (e.g., "channels") to enable networked operation of the application (functions, etc.) and connection to industrial hardware (sensors, actuators, and other data sources and data sinks).

[0031] The organization or allocation (i.e., deployment) is accomplished based on the characteristics or performance data (capacity, capabilities, characteristic parameters, or simply "capabilities") of existing hardware or resources. This data may include, for example, CPU characteristics, working memory, network connectivity quality, or current CPU load (caused by system processes or third-party software, such as other applications or third-party applications).

[0032] Resources are divided into three categories: 1. Resources specifically reserved for the automation solution in question: Only the software required for that automation solution runs on these resources. This makes it possible to guarantee maximum execution time within a certain range by leveraging process priorities.

[0033] 2. Open resources: Third-party software can also be executed on these resources. This significantly hinders or even makes the predictability of execution time impossible.

[0034] 3. Closed systems without schedulers / operating systems: On ultra-small devices such as microcontrollers, user programs typically run without an operating system. This significantly reduces (or even eliminates) the sources of program interruption, thereby significantly reducing jitter or achieving constant execution time.

[0035] In the first two categories, execution time must be continuously monitored throughout the entire runtime. In the third category, if the execution time can be considered constant, then monitoring of execution time can be omitted during runtime.

[0036] When the complete automation application (business logic and hardware connectivity) or any part thereof described below changes, users do not need to resize the system. Instead, they will continue to monitor constraints or their compliance, and reallocate or distribute the application or parts thereof across resources as necessary.

[0037] Allocating application or program components to available hardware resources (including operating system, firmware, and runtime environment) is an optimization problem. This involves mapping the requirements of the application, function, or communication connection to be executed onto the performance data of the available resources or reconfiguring them to satisfy as many constraints as possible. Other optimization objectives, such as cost optimization and optimizations involving the lowest possible probability of failure, can also be considered.

[0038] The implications of this optimization task are as follows: In many cases, it is not expected that a theoretically possible optimal partition (global optimum) can be found.

[0039] - There will be certain states in which a partition that guarantees compliance with the constraints is not found or cannot be found: In this case, the user must provide more hardware resources, or provide other network resources for the network connection (e.g., higher bandwidth via TSN (Time-Sensitive Networking)).

[0040] Furthermore, the automation solution eliminates the dependence on hardware. Users can choose the use and type of hardware or hardware resources (e.g., using freely available or releasable hardware in the same or different factory areas) while retaining the same software.

[0041] Figure 1 This diagram illustrates the cascading of an application or function (F1, ..., F5) with a communication channel along a single path traversed by data signals. The most important constraint for describing such a real-time system is the maximum permissible execution time, or message transmission time. In this system, this value can be fixed at the time of program writing for one or more (computational) functions (F1, ..., F5) (also called functions or applications) and the communication connections (e.g., communication channels) (K1, ..., K4) between them. Figure 1The hardware / software drivers on the left or right are not considered in this system because it is assumed that the latency in these nodes is relatively constant and known, and therefore typical latency can be used or ignored. This is also common practice in existing systems, as measurement and monitoring (e.g., with an oscilloscope) are expensive and mostly unnecessary.

[0042] In this figure, the characteristic parameter to be monitored is the transit time of the data signal from sensor S to actuator A. The maximum target time (deadlines 1, 2 and 3) is defined as the limit value of the signal transmission time for a certain number of sub-paths. In addition, a target time (deadline 4) is defined for the total path consisting of the functions F1, ..., F5 of the application program and the communication connections K1, ..., K4.

[0043] In the context of this example, the permissible transit times (i.e., the limits) are considered as characteristic parameters or constraints. By adding them to a certain start time, the permissible target time, i.e., the corresponding deadline, is obtained as the value to be observed. If the signal arrives at the next measurement point before the deadline, the considered sub-path or total path is considered to be normal; otherwise, it is considered to exceed the limit.

[0044] The constraints used to monitor the maximum permissible message transmission time across one or more different computing nodes or communication channels are based on the premise that the clock times of these nodes are synchronized (e.g., using NTP or PTP protocols).

[0045] Monitoring of the maximum allowed execution time consists of two (optionally three) components: 1. Determine the deadline (absolute time): The deadline is determined at the starting node of the sub-path to be monitored. Here, the current system time is measured at the beginning of the corresponding sub-path, and it is added to the characteristic parameter (constraint) of the maximum allowed execution time to obtain the deadline. Figure 1 An example illustration of deadlines for one or more functions or communication channels is shown. To apply this algorithm, the maximum allowed message transmission time must be known at the start of the sub-path, and the corresponding deadline must be propagated, i.e., forwarded, along with the corresponding payload throughout the sub-path.

[0046] 2. Monitoring deadline: The corresponding deadline is sent along with the message throughout the subpath. Each compute node, upon receiving a data packet carrying a data signal (e.g., a measurement) and before outputting a corresponding data packet with (if necessary changed) data signals, checks whether the current system time is less than the deadline (limit) calculated by the input node. To achieve this, the current time is measured at the first node of the subpath associated with the deadline and added to the deadline (the maximum allowed execution time of the examined path or subpath). This absolute time, as the deadline, is transmitted along with the actual load through the corresponding communication channel in messages sent from one function to the next (see...). Figure 2 Actual transmission time refers to the current value of the characteristic parameter (transmission time in this case) determined on the corresponding sub-path or total path, while the "deadline" is the limit that must be followed.

[0047] 3. Optional analysis: In addition, input or output timestamps can also be transmitted in messages. This can be used for analysis, for example, to determine message transmission time and jitter in the communication channel or front-end application / function (including the communication channel).

[0048] Monitoring should not be performed within user-written functions or application components, but rather at runtime—that is, within a runtime environment provided by the manufacturer invoking user-written functions. Alternatively, monitoring can also be integrated as an additional feature into the operating system.

[0049] The infrastructure consists of hardware (hardware resources), operating system, runtime environment, and functions (user logic, applications). Figure 3 As shown in the image.

[0050] This function only forwards the payload and metadata (such as variable names or information about messaging) to the runtime environment (hereinafter referred to as the runtime). The runtime then combines this information with... Figure 2 The information described in the document (deadline and possible timestamps) should be supplemented.

[0051] When the operating system receives a new message, the runtime invokes the event handler within the user logic. This event handler only has a payload.

[0052] Figure 4 An example of an event handler is shown, which receives the value "value", executes user-written business logic internally, and returns the value "newValue" to the runtime using the method "fireEvent". It can be seen that the data signal (in this case, the data item "value") may be modified (and then become the data item "newValue") during transmission via sub-paths or the main path.

[0053] During initial deployment, no existing algorithm can accurately predict, with reasonable overhead, whether a given time constraint (characteristic parameter), such as "worst-case execution time," can reliably meet the requirements of a given program.

[0054] In existing applications, try to ensure this through user experience and testing during debugging.

[0055] In the current system, the first step is to use hardware utilization data, such as idle CPU and RAM capacity, as the basis for performance data for planning deployment.

[0056] Data and performance information (e.g., clock speed, architecture, memory, operating system, bandwidth, etc.) essentially determine the availability of hardware resources, the runtime environment installed on them, or communication resources. Performance data can also be determined in other ways, such as by running test applications (test routines) or by the controlled transmission of test packets.

[0057] In microservice-based systems, another crucial factor is the message transmission time between services (functions or applications). Message transmission time can be significantly reduced if two services run on the same hardware node, for example, when the two services are highly cohesive / coupled. The more routers and switches a message passes through from sender to receiver, the longer the transmission time. To account for this network topology, techniques such as LLDP (Link Layer Discovery Protocol) can be used in the initial stages. In further development, the system in question can also employ techniques such as TSN (Time-Sensitive Networking) to reserve dedicated communication resources for communication connections and thus guarantee bandwidth.

[0058] However, in the described system, it is still possible to expect a debugging phase after deployment, during which the risk of deadline violations increases because not all interactions between services and hardware are known. Nevertheless, for programmers of distributed computing systems, the deployment algorithm represents a significant simplification, as users do not need to explicitly assign services to hardware, nor do they need detailed knowledge of hardware component usage or network topology.

[0059] An error system event is sent once an application or underlying runtime environment determines that a service has failed to meet a deadline, resulting in the actual value of a certain characteristic parameter failing to reach its assigned limit.

[0060] exist Figure 5The diagram illustrates a possible sequence of procedures for checking deadlines in a runtime environment. In this case, the application (referred to here as the user function) monitors against the limits (deadlines), and in the event of an error, generates an error system event that initiates a deployment reorganization.

[0061] Users should be able to define the system's response to such an error system event. Possible responses for exceeding deadlines include: - Perform a user-defined function; - To shut down the entire system or put it into a safe state; - Notify users of any issues that have exceeded the deadline, while the system continues to operate; - Calculate and execute software functions and redistribute (redeploy) compute nodes.

[0062] In the latter case, it is necessary to distinguish the following types of redeployment: O Immediate / Mild → Blue-Green Deployment (e.g., using event sourcing and Apache Kafka for stateful services, and directly deploying for stateless services); O Immediate / Forced: Stop the service and redeploy immediately; Plan O: Continue collecting data for optimization and subsequent redeployment while the equipment can be switched to maintenance mode or during downtime; that is, it can tolerate interruptions in program execution in this state. This can be predefined by the user or production system.

[0063] To influence deployment strategies, the execution time of services / applications / functions and the message transmission time of communication channels are particularly important.

[0064] The analysis can be performed as follows: - Execution time within services: If each service stores input timestamps when an event is received and output timestamps when an event is sent, the execution time of the service (e.g., minimum, maximum, histogram, etc.) can be calculated from this. This information can then be used to optimize scheduling (i.e., redeployment). This information can be transmitted to the central component that influences deployment strategies via channels that do not necessarily require real-time capabilities.

[0065] - Message Transmission Time: If an output timestamp is additionally transmitted in the header of an event or data packet, the corresponding message transmission time can be calculated upon receiving the event / data packet / data message. This can also be used for subsequent optimizations.

[0066] Unlike what was described previously, statistics on system execution and communication latency, as well as other parameters, become available after initial deployment. This data can then be used to optimize the system when appropriate. Possible optimization vectors are as follows: - By utilizing resources evenly, we avoid overloading individual hardware nodes, thereby reducing the risk of latency thresholds being occasionally exceeded.

[0067] - Optimize communication relationships by redeploying services with direct communication connections that have high latency, jitter, or other adverse characteristics.

[0068] Existing automation solutions are typically created using a bottom-up approach. This means that the hardware to be used is determined at the outset, and then the software is customized for that specific hardware. If the hardware configuration is later changed, adjusting the software to accommodate the new hardware usually requires a considerable amount of effort.

[0069] With this approach, users or developers of real-time-critical applications must understand or measure the software and available resources and their utilization, including third-party software usage. This can be very time-consuming, therefore costly, and error-prone. The result is often a significant increase in resources invested to meet given constraints even during peak usage periods. Furthermore, if parts of the overall system change, new assessments must be performed. Dynamically configurable automation further amplifies this uncertainty and the resulting costs. This impact is exacerbated when system and / or application changes occur simultaneously with personnel changes. In some cases, this may require (time-consuming) acquisition of new knowledge.

[0070] The solution is based on the concept of automated deployment, thereby reducing the user's time and risk, and adjusting the allocation of software and hardware and communication configurations to meet specifications again in the event of exceeding latency thresholds or similar limitations.

Claims

1. A method for allocating applications (F1, ..., F5) and configuring communication connections (K1, ..., K4) in a distributed industrial automation device, said automation device having a number of networked hardware resources for the applications (F1, ..., F5) and communication resources for the communication connections (K1, ..., K4), in, The total path between the first control element and the second control element is formed by the application programs (F1, ..., F5) on a certain number of hardware resources and the communication connections (K1, ..., K4) on the communication resources. The overall path is formed by a certain number of sub-paths, and each sub-path is composed of the application (F1, ..., F5) and the communication connection (K1, ..., K4). Wherein, the data signal passes through the total path, and wherein, for the data signal traversing the total path, a limit is set for the passage of a preset characteristic parameter. Its features are, In the first step, the current value of the feature parameter is recorded for at least one passage of the data signal on the total path and at least one of the sub-paths. In the second step, performance data of at least a portion of the hardware resources and / or the communication resources is determined, wherein, during the operation of the automation device, the absolute degree or relative degree of use of at least one of the resources by the corresponding application and / or the corresponding communication connection is determined, and In the third step, if at least one actual value fails to reach the corresponding limit, the allocation of the application (F1, ..., F5) to the hardware resources and / or the allocation of the communication connection (K1, ..., K4) to the communication resources is dynamically reorganized.

2. The method according to claim 1, wherein, The first control element is a sensor (S).

3. The method according to claim 1, wherein, The second control element is an actuator (A).

4. The method according to claim 1, wherein, The limit of the characteristic parameter is the maximum execution time or response time.

5. The method according to any one of claims 1 to 4, characterized in that, For different types of hardware resources and / or communication resources, determine, learn, or store the absolute or relative extent of use by the corresponding type of application or communication connection.

6. The method according to any one of claims 1 to 4, characterized in that, In the third step, for the purpose of the reorganization, in the case of a feasible or anticipated relocation of the application from the first hardware resource to the second hardware resource, or in the case of a feasible or anticipated relocation of the communication connection from the first communication resource to the second communication resource, the use of the first hardware resource or the first communication resource is considered for the feasible or anticipated relocation of the third application or the third communication connection.

7. The method according to any one of claims 1 to 4, characterized in that, In the third step, the time required for reconfiguration is used to determine, based on a predetermined reference value or a value determined, learned, or stored from previous installation processes or reconfiguration time, whether the reconfiguration can be performed during the operation of the automation device or during the downtime of the automation device, taking into account a predetermined maximum delay during continuous operation. Based on the determination, the reconfiguration is performed immediately or only during subsequent downtime.

8. The method according to any one of claims 1 to 4, characterized in that, Before the new organization of the allocation of the application (F1, ..., F5) and / or the communication connection (K1, ..., K4), the execution of the application (F1, ..., F5) and the operation of the communication connection (K1, ..., K4) on the hardware resources or communication resources respectively planned for the application are simulated to simulate new expected values ​​of the characteristic parameters, and the reorganization is only performed if the simulation is successful in complying with one or more limits.

9. The method according to any one of claims 1 to 4, characterized in that, During one or each operation of the communication device, actual values ​​for the data signal passing through the total path and through multiple sub-paths are used to train a machine learning system, each actual value being associated with the actual hardware resources or communication resources used, wherein the trained machine learning system is used to determine the optimal organization of the application (F1, ..., F5) and / or the communication connection (K1, ..., K4) on the currently available hardware resources or communication resources.

10. The method according to claim 9, wherein, The machine learning system is a neural network.

11. The method according to any one of claims 1 to 4, characterized in that, Use bandwidth, transmission duration, or jitter as characteristic parameters of communication resources, and / or use computing performance, storage capacity, or specific functions as characteristic parameters of hardware resources.

12. An apparatus for distributing applications (F1, ..., F5) and configuring communication connections (K1, ..., K4) in a distributed industrial automation device, the apparatus having a number of networked hardware resources for the applications (F1, ..., F5) and communication resources for the communication connections (K1, ..., K4), Its features are, The device includes a first computer program for timestamping data signals at a first component of the automated device. The device includes a second computer program for reading and evaluating the timestamps of the data signals at a second component of the automated device. The apparatus includes a third computer program designed to organize the allocation of the application programs (F1, ..., F5) and / or the communication connections (K1, ..., K4) according to the method of any one of claims 1 to 7.

13. The apparatus according to claim 12, wherein, The first computer program is the first firmware or operating system routine.

14. The apparatus according to claim 12, wherein, The second computer program is a second firmware or operating system routine.

15. The apparatus according to claim 12, wherein, The third computer program is a third firmware or operating system routine.

Images