Method and arrangement for distributing applications and for configuring communication connections in a distributed industrial automation arrangement

Abstract

The invention relates to a method and an arrangement for distributing applications (F1, …, F5) and for configuring communication connections (K1, …, K4) in a distributed industrial automation arrangement having a number of networked hardware resources for the applications (F1, …, F5) and communication resources for the communication connections (K1, …, K4), wherein an entire route is formed from a number of partial routes composed of the applications (F1, …, F5) and communication connections (K1, …, K4), wherein a data signal passes through the entire route, and wherein a limit value of a parameter, in particular a maximum execution time or response time, is specified for a passage of the data signal through the entire route. The current values of the parameter for at least one passage of the data signal on the entire route and on at least one of the partial routes are registered, whereupon the performance data of at least some of the hardware resources and / or the communication resources is determined, and whereupon, at least in the case in which at least one actual value violates the associated limit value, the distribution of the applications (F1, …, F5) among the hardware resources and / or the distribution of the communication connections (K1, …, K4) among the communication resources is reorganized. As a result, the deployment is supported and the adherence to parameters and constraints is dynamically ensured by reorganization of the deployment.

Description

[0001] Description

[0002] Method and arrangement for distributing applications and configuring communication links in a distributed industrial automation arrangement

[0003] In the automation industry, key parameters or criteria are used for the design, configuration, and operation of the real-time systems used there, for example the maximum permitted execution time (hereinafter also referred to as the "deadline"). This must always be adhered to in "hard" real-time systems in order to avoid damage to machines and the goods produced. In "soft" real-time systems, the value of the result (quality, performance) decreases successively after the deadline is exceeded. Therefore, in real-time systems, the predictability of an application's execution time is essential for dimensioning the system.

[0004] The execution time of an application can be estimated through a theoretical analysis, which is very complex and therefore uneconomical in most cases. On the other hand, the dimensioning can also be determined experimentally during system commissioning. This experimental method requires knowledge of the application logic (e.g., application components that are not always executed) and knowledge of the system (e.g., the execution of other applications on a given hardware and hardware properties).

[0005] The reasons for the high level of effort (see points mentioned above) are that time must be invested in the system analysis, or otherwise the systems often have to be designed to be significantly larger than necessary (increased effort for hardware procurement, configuration, installation, commissioning, etc.). If the application or the hardware structure or other system components are changed, a new analysis is necessary. If individual parameters are changed (e.g. process speed), a complete or partial analysis must also be carried out. Changes can also occur if the existing hardware is modified and / or refitted.

[0006] The publication DE 600 15 032 T2 - Balasubramanian "Distributed real-time operating system" discloses a distributed operating system on different computing nodes, whereby acceptable response times are sought by prior allocation of all hardware resources on the basis of termination times for the application programs.

[0007] Existing automation systems generally offer no guarantee that defined execution times will be reliably met (hard real time). Control systems often use a separate system to execute control programs. In this system, the user has no option to run "third-party" software alongside the automation solution. This allows fluctuations in execution times to be limited. If parts of the program cannot be executed within the previously specified maximum time (deadline), error routines are called. This allows the user to define a response to deadlines being exceeded.

[0008] The prior art therefore presents the problem that the distribution of applications (software and the configuration of communication links) in an existing hardware architecture, i.e. the deployment, has to be designed in such a way that parameters or performance limits, so-called constraints, are reliably adhered to. The prior art also presents the problem that if the hardware or software architecture changes, compliance with the parameters has to be checked again and the deployment has to be adapted if necessary. These processes are complex and error-prone in the prior art. In addition, adapting the deployment generally requires a high level of expertise from the specialists entrusted with it. The core idea of ​​the inventive solution to this problem is to divide and / orTo automate the distribution of application logic (in short: applications) and the communication channels or connections required to network the applications to the available hardware (hardware resources, communication resources), thereby reducing time and risk for the user and monitoring a previously specified requirement (deadline or similar) in order to optimize the deployment if necessary.

[0009] The object is achieved in particular by a method according to patent claim 1 and by an arrangement according to patent claim 9.

[0010] A method is proposed for distributing applications and for configuring communication connections in a distributed industrial automation arrangement with a number of networked hardware resources for the applications and communication resources for the communication connections, wherein an overall path between a first control element, in particular a sensor, and a second control element, in particular an actuator, is formed from a number of applications on the hardware resources and the communication connections on the communication resources, wherein the overall path is formed from a number of partial paths from the applications and communication connections, wherein a data signal travels through the overall path, and wherein a limit value of a parameter, in particular a maximum execution or response time, is predetermined for a path of the data signal through the overall path.In a first step, the current values ​​of the characteristic for at least one pass of the data signal on the entire route and at least one of the partial routes are recorded, in a second step the performance data of at least some of the hardware resources and / or the communication resources are determined, and in a third step, at least in the case in which at least one actual value exceeds the respective limit value, the distribution of the applications to the hardware resources and / or the communication connections to the communication resources is reorganized. This process supports deployment and dynamically ensures compliance with characteristics and constraints by reorganizing the deployment.

[0011] The object is also achieved by an arrangement for carrying out the method and corresponding computer programs or computer program products, during the execution of which the deployment or re-deployment is carried out automatically. In this case, an arrangement for distributing applications and for configuring communication connections in a distributed industrial automation system with a number of networked hardware resources for the applications and communication resources for the communication connections is proposed, wherein the arrangement comprises a first computer program, in particular a first firmware or operating system routine, for time-stamping a data signal at a first component of the automation system, wherein the arrangement comprises a second computer program, in particular a second firmware or operating system routine,for reading and evaluating the time stamp of the data signal at a second component of the automation arrangement, and wherein the arrangement comprises a third computer program, in particular a third firmware or operating system routine, for organizing the distribution of applications and / or communication connections according to the method described above. With this arrangement, the advantages already discussed with reference to the method can be achieved.

[0012] Advantageous embodiments of the method according to the invention are specified in the dependent patent claims. The features disclosed therein and their advantages also apply mutatis mutandis to the arrangement according to the invention. Advantageous variants can be implemented both individually and in appropriate combinations. Advantageously, during operation of the automation arrangement, an absolute or, with regard to the performance data, relative degree of occupancy (utilization) of at least one of the resources by the respective application and / or the respective communication connection is determined, learned, or stored. Based on this data, on the one hand, the resource requirements of the respective application or communication connection can be estimated, and on the other hand, it can be determined at which point free resources or resources to become free exist for shifting processes or reconfiguring communication connections.

[0013] For different types of hardware resources and / or communication resources, the absolute or relative degree of utilization by the respective type of application or communication connection can be determined, learned, or stored separately. This allows for better analysis of the resource requirements of the applications and communication connections and processes, and allows for better adaptation of deployment or redeployment to the available resources.

[0014] In the third step, in the event of a possible or intended relocation of an application from a first hardware resource to a second hardware resource or in the event of a possible or intended relocation of a communication connection from a first communication resource to a second communication resource, the occupancy of the first hardware resource or the first communication resource that becomes available in the process for a possible or intended relocation of a third application or a third communication connection can be advantageously taken into account for the reorganization.

[0015] In the third step, the time required for the reorganization is advantageously determined based on predefined benchmark values ​​or on determined, learned, or stored values ​​for the time required from previous installation processes or reorganizations to decide whether the reorganization can take place during operation of the automation system or during a break in operation of the automation system, in light of a predefined maximum delay during ongoing operation, after which the reorganization takes place either immediately or during a subsequent break in operation. This allows the time for deployment to be planned so that it does not cause any disruption to operations and, if possible, is carried out during ongoing operation.

[0016] In one embodiment, before applying the new organization of the distribution of the applications and / or the communication links, the new expected value for the parameter is simulated by simulating the applications and the communication links in relation to the execution of the applications or the communication links on the hardware resources or communication resources planned for them, so that the reorganization only takes place if the simulation is successful in terms of compliance with the limit value or limits, and otherwise an alternative configuration is sought. When planning the deployment, it is advantageous to use measured performance indicators of the resources already in operation because this automatically takes into account the resource requirements of any third-party software or the communication links of other processes.

[0017] For this purpose, during one or each operation of the communication arrangement, the actual values ​​for the passes of the data signal through the entire route and through a plurality of partial routes, each related to the hardware resources or communication resources actually used, can be trained by means of a machine learning system, in particular by means of a neural network, wherein the trained machine learning system is used to determine an optimized organization of the applications or communication connections on the currently available hardware resources or communication resources.

[0018] If no measured values ​​or key performance indicators are available, these key performance indicators can be used from a library, catalog or the like, which are scaled down with a safety factor depending on the situation, for example depending on the safety requirements of the applications in question or depending on the technical environment (factory, simulation, system test, demo, industry, etc.).

[0019] In a simple, easily measurable case, a bandwidth, a typical transmission time and / or a jitter (fluctuation in the transmission time) is used as a parameter for a communication resource, and the computing power, a memory space or a specific functionality (e.g. the presence of additional cores) can be used as a parameter for the hardware resources.

[0020] An exemplary embodiment of the method according to the invention is explained below with reference to the drawings. It also serves to explain an arrangement according to the invention.

[0021] Showing:

[0022] Figure 1 : a chain of applications or functions and communication channels in a total path traversed by a data signal between a data source and a data sink,

[0023] Figure 2 : schematic representation of a message telegram as a data signal including a deadline as a parameter,

[0024] Figure 3 : a schematic representation of the structure of a

[0025] Hardware resources with a function as an application, Figure 4 : a simple example of an event handler for processing the payload data (pilot) of a message telegram (data signal), and

[0026] Figure 5: a diagram illustrating the program flow for monitoring the parameter (deadline).

[0027] In a distributed industrial automation system, applications and their components are to be loaded automatically and based on constraints onto networked hardware resources (processing units, computers, controllers, servers, edge devices, etc.). The constraints are static, quantifiable parameters, such as a maximum permitted response time or processing time or "deadline" of a data signal (here: message telegram). During its transmission, the data signal's content can also be changed; the present discussion primarily concerns the overall response time of the entire system (entire path) to an event (generated by a data source, e.g., sensor) and a reaction to a data sink (e.g., actuator). This therefore concerns, for example, changes in output values ​​(actuators) based on a reaction triggered by a change in input value (sensors).

[0028] After loading, for example, after commissioning the automation system or a part of it, compliance with the constraints is continuously monitored. If constraints are not met, the corresponding applications or application components are reallocated among the available hardware resources. In addition to this aspect of deployment, i.e., the distribution of applications among the available hardware resources, the deployment considered here considers the configuration of communication resources, i.e., the establishment and parameterization of communication connections (e.g., "channels") for the networked operation of the applications (functions, etc.) and for connection to the industrial hardware (sensors, actuators, and other data sources and sinks).

[0029] The organization or distribution, i.e., the deployment, is based on the properties or performance data (capacities, capabilities, parameters, or "capabilities" for short) of the available hardware or resources. These can be, for example, characteristics of the CPU, RAM, quality of network connections, or current CPU utilization (by system processes or third-party software - such as other applications or 3rd-party applications).

[0030] Resources are divided into three categories:

[0031] 1. Resources reserved exclusively for the automation solution in question: These resources run only the software required for the automation solution. This includes the ability to guarantee maximum execution times within certain limits using process priorities.

[0032] 2. Open resources: Third-party software can also be executed on these resources. This makes predicting execution time (significantly) difficult or even impossible.

[0033] 3. Closed systems without a scheduler / operating system: On small devices, such as microcontrollers, the user program often runs without an operating system. Sources of program interrupts can be significantly reduced, or in extreme cases even eliminated, which can lead to a significant reduction in jitter or consistent execution time.

[0034] In the first two categories, continuous monitoring of the execution time must occur throughout the entire runtime. In the third category, monitoring of the execution time during runtime is not necessary if the respective execution time can be assumed to be constant.

[0035] If the entire automation application (business logic & hardware connection) or parts of it are subsequently changed, the user does not need to redimension the system. Instead, the constraints and their compliance are further monitored, and if necessary, applications or application components are reallocated or distributed to the resources.

[0036] The allocation of applications or program components to the available hardware resources (including operating systems, firmware, runtime environments) is an optimization problem in which the requirements of the applications, functions, or communication links to be executed must be mapped or reconfigured to the performance data of the available resources so that all constraints are met as far as possible. Other optimization goals can also be considered, such as cost optimization, optimization with a view to minimizing the probability of failure, or similar.

[0037] For the optimization task this means:

[0038] It is to be expected that in many cases the theoretically possible optimal distribution (global optimum) will not be found.

[0039] There are situations in which no distribution is found or can be found that guarantees compliance with the constraints: In this case, the user must provide more hardware resources or, for example, provide other network resources for network connections (e.g. more bandwidth via TSN - Time Sensitive Networks).

[0040] Furthermore, the automation solution's dependence on hardware is eliminated. While retaining the same software, the user can choose the use and type of hardware or hardware resources (e.g., the use of free or releasable hardware in the same or other parts of the system).

[0041] Figure 1 shows a chain of applications or functions (Fl, F5) and communication channels in a total path traversed by a data signal. The most important constraint for describing such a real-time system is the maximum permissible execution time or message propagation time. In the described system, this can be defined for one or more (computational) functions (Fl, ..., F5) (also called functions or applications) and the communication connections (e.g. communication channels) (Kl, ..., K4) in between during program creation. The HW and SW drivers on the left and right in Figure 1 are not taken into account in this system because it is assumed that the latency in these nodes is comparatively constant and known and that a typical latency can therefore be assumed or neglected.This is also common in previous systems, since measurement monitoring, for example using an oscilloscope, is very complex and usually unnecessary.

[0042] In the figure, the transit times of a data signal from sensor S to actuator A are considered as parameters to be monitored, whereby for some partial routes, maximum target times Deadline 1, 2 and 3 are defined as limit values ​​for the value of the signal transit time and, in addition, the target time Deadline 4 for the entire route, which is formed from the functions Fl, ..., F5 as applications and from the communication connections Kl, ..., K4.

[0043] In the context of this example, the permitted processing times, i.e., the limit values, are considered as a parameter or constraint by adding them to a start time, resulting in a permitted target time, namely the respective deadline, as the value to be met. If the signal arrives at the next measuring point before this deadline, everything is OK with regard to the section or entire route under consideration; otherwise, the limit value is considered to have been missed.

[0044] The prerequisite for monitoring the constraint of the maximum allowed message runtime across one or more different computing nodes or communication channels is that the time of all these nodes is synchronized (e.g. using an NTP or PTP protocol).

[0045] Monitoring the maximum allowed execution time consists of two or optionally three components:

[0046] 1. Determination of a deadline (absolute time):

[0047] The deadline is determined at the initial node of the monitored segment. Here, the current system time is measured at the beginning of each segment and added to the constraint of the maximum allowed execution time. This results in the deadline. Examples of deadline specifications for one or more functions or communication channels are shown in Figure 1. To apply this algorithm, the maximum allowed message runtime must be known at the beginning of the segment, and the respective deadline must be propagated, i.e., reported, across the entire segment with the respective payload.

[0048] 2. Monitoring the deadline:

[0049] The respective deadline is sent over the entire section in the message telegram. Each computing node checks both after the data packet has arrived with the data signal, e.g. a measured value, and before the respective packet has left the system with the possibly modified data signal, whether the current system time is less than the deadline (limit value) calculated by the input node. To enable this functionality, the current time is measured in the first node of the section relevant for the deadline and added to the deadline (maximum permissible execution time for the section or section in question). This absolute time is sent as a deadline alongside the actual payload in the message from one function to the next over the respective communication channel (see Figure 2).The determined actual running time is the current value of the parameter (here: throughput time) on the respective partial or total route under consideration, and the "deadline" is the limit value to be observed.

[0050] 3 . Optional analysis :

[0051] Additionally, the input or output timestamp can also be sent in a message. This can then be used for analysis, for example, to determine the message runtime and the jitter of the communication channel or the previous application / function including the communication channel.

[0052] The monitoring should not take place in the part of the function or application that was programmed by the user, but in the "runtime", i.e. the runtime environment provided by the manufacturer in which the function programmed by the user is called. Alternatively, the monitoring can also be integrated as an additional function in an operating system.

[0053] The underlying architecture with hardware (hardware resource), operating system, runtime environment and function (user logic, application) is shown in Figure 3.

[0054] The function only passes the payload and metadata (such as variable names or message delivery information) to the runtime environment (hereinafter referred to as the runtime). The runtime then enriches this information with the information described in Figure 2 (deadline, timestamp, if applicable).

[0055] When the runtime receives a new message from the operating system, it calls an event handler in the user logic. This event handler only receives the payload.

[0056] Figure 4 shows an example event handler that receives the value "value," internally executes the business logic programmed by the user, and returns the value "newValue" to the runtime using the "fireEvent" method. It can be seen that the data signal, in this case the datum "value," can be changed during the run through the partial or complete path (here then as the datum "newValue").

[0057] During initial deployment, there are no algorithms in the state of the art that can accurately predict, with reasonable effort, whether given temporal constraints (parameters), e.g., "worst case execution time", can be reliably met for a given program.

[0058] In existing applications, attempts are made to ensure this through user experience and tests during commissioning.

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

[0060] In principle, utilization data and performance information (e.g., clock speed, architecture, memory, operating system, bandwidth, etc.) determine the available performance data of a hardware resource or a runtime environment installed on it or a communication resource. Performance data can also be determined in other ways, for example, by running test applications (test routines) or by the controlled transmission of test data packets.

[0061] Another significant factor in a microservice-based system is the message propagation times between the individual services (here: functions or applications). These can be massively reduced if two services are run on a common hardware node, for example if the cohesion / coupling of two services is high. The more routers and switches a message has to pass through to get from the sender to the receiver, the longer the message propagation time becomes. To incorporate this network topology, technologies such as LLDP (Link Layer Discovery Protocol) can be used in a first step. In a further evolutionary stage, the system in question can also use technologies such as TSN (Time Sensitive Networking) to reserve and thus guarantee bandwidth on dedicated communication resources for communication connections.

[0062] Nevertheless, it is still to be expected that in the described system, deployment will be followed by a commissioning phase in which the risk of deadlines being missed is increased, since not all interactions between the services or hardware are known. Nevertheless, the deployment algorithm represents a significant simplification for a programmer of a distributed computing system, since the user does not have to explicitly assign the services to a piece of hardware and does not need to know the utilization of the hardware components or the network topology in detail.

[0063] As soon as it is determined in one of the applications or the underlying runtime environment that a service has not met a deadline and thus an actual value of a parameter misses the assigned limit, an error system event is sent.

[0064] A possible program flow for checking deadlines in the runtime environment is shown in Figure 5. There, an application (called a user function) is monitored with respect to a threshold value (deadline). In the event of an error, an error system event is generated, which initiates the reorganization of the deployment.

[0065] The user should be able to define the system response to such an error system event. Possible responses to a missed deadline include:

[0066] A function defined by the user is executed.

[0067] The entire system is stopped or brought into a safe state.

[0068] The user is informed when a deadline is exceeded and the system continues to run.

[0069] A new assignment of software functions and computing nodes is calculated and carried out (re-deployment).

[0070] In the latter case, a distinction is made between the following types of re-deployment: o Immediate / Soft Blue-green deployment (e.g. with event sourcing and Apache Kafka for stateful services, direct for stateless services) o Immediate / hard: stopping services and immediate redeployment o Planned: continuing to collect data for optimization and later redeployment when the system can be switched to maintenance mode or operational pause, i.e. a state in which interruptions in program execution are tolerated. This can be specified by the user or by the production system. The execution times of the services / applications / functions and the message runtimes of the communication channels are particularly relevant for influencing the deployment strategy.

[0071] These can be analyzed as follows:

[0072] Service execution times: If the input timestamp upon receipt of an event and the output timestamp upon transmission of an event are stored in each service, the execution time of a service can be calculated from this (min, max, histogram, etc.). This can then be used to optimize scheduling (= redeployment). This information can then be transmitted via a channel that is not necessarily real-time capable to a central component that influences the deployment strategy.

[0073] Message runtime: If the output timestamp is also sent in the header of an event or data packet, the respective message runtime can be calculated upon receipt of an event / data packet / data telegram. This can also be used for subsequent optimization.

[0074] Unlike previously described, statistical data for execution and communication latencies and other system metrics can be available after the initial deployment. These can then be used later to optimize the system. The following optimization vectors are possible:

[0075] Avoid overload situations on individual hardware nodes by balancing load. This reduces the risk of sporadic exceedance of latency limits.

[0076] Optimization of communication relationships through re-

[0077] Deployment of services that have a direct communication connection with high latency, jitter or other adverse characteristics.

[0078] Previous automation solutions were generally developed using a bottom-up approach. This means: First, the hardware to be used is determined. The software is then tailored to this specific hardware. A later change in the hardware configuration often requires (significant) effort to adapt the software to the new hardware.

[0079] For this approach, users or developers of real-time critical applications must know the software as well as the available resources and their utilization, including the system utilization by third-party software, or determine this through measurements. This can be very complex and therefore costly and prone to errors. The frequent result is that (far) more resources are used than actually necessary in order to be able to comply with the given constraints during peak loads. In addition, a new assessment must be carried out if parts of the overall system are changed. Dynamically configurable automation programs increase this uncertainty and the resulting costs. This effect is further increased if changes to the system and / or applications are accompanied by personnel changes. This may require (time-consuming) know-how to be built up first.

[0080] The idea of ​​the solution outlined is to automate the deployment and thereby reduce time and risk for the user and, if latency limits or similar are exceeded, to adapt the distribution of software and hardware and the configuration of the communication in such a way that the specifications are met again.

Claims

Patent claims 1. A method for distributing applications (F1, F5) and for configuring communication connections (K1, ..., K4) in a distributed industrial automation arrangement with a number of networked hardware resources for the applications (F1, ..., F5) and communication resources for the communication connections (K1, ..., K4), wherein an overall path between a first control element, in particular a sensor (S), and a second control element, in particular an actuator (A), is formed from a number of applications (F1, ..., F5) on the hardware resources and the communication connections (K1, ..., K4) on the communication resources, wherein the overall path consists of a number of partial paths from the applications (F1, ..., F5) and communication connections (K1, ..., K4 ), the entire route being traversed by a data signal, and a limit value of a parameter, in particular a maximum execution or reaction time, being predetermined for one pass of the data signal through the entire route, characterized in that in a first step the current values of the parameter are registered for at least one pass of the data signal on the entire route and at least one of the partial routes, that in a second step the performance data of at least some of the hardware resources and / or the communication resources are determined, and that in a third step at least in the case in which at least one actual value fails to meet the respective limit value, the distribution of the applications (F1, ..., F5) to the hardware resources and / or the communication connections (K1, ..., K4) to the communication resources is reorganized.

2. Method according to claim 1, characterized in that during operation of the automation arrangement, an absolute or a relative degree of occupancy with respect to the performance data of at least one of the resources by the respective application and / or the respective communication connection is determined, learned or stored.

3. Method according to one of the preceding claims, characterized in that for different types of hardware resources and / or communication resources, the absolute or relative degree of occupancy by the respective type of application or communication connection is determined, learned or stored separately. 4 . Method according to one of the preceding claims, characterized in that in the third step for the reorganization, in the case of a possible or intended shift of an application from a first hardware resource to a second hardware resource or in the case of a possible or intended shift of a communication connection from a first communication resource to a second communication resource, the occupancy of the first hardware resource or of the first communication resource which becomes available in each case for a possible or intended shift of a third application or a third communication connection is taken into account.

5. Method according to one of the preceding claims, characterized in that in the third step a time required for the reorganization is used on the basis of predetermined guide values or on the basis of determined, learned or stored values for the time required from previous installation processes or reorganizations to decide whether the reorganization can take place during operation of the automation arrangement or during an operational break of the automation arrangement in the light of a predetermined maximum delay during ongoing operation, after which the reorganization takes place either immediately or only during a subsequent operational break.

6. Method according to one of the preceding claims, characterized in that before application of the new organization of the distribution of the applications (F1, ..., F5) and / or the communication links (K1, ..., K4), the new expected value for the parameter is simulated by means of simulation of the applications (F1, ..., F5) and the communication links (K1, ..., K4) in relation to a sequence of the applications (F1, ..., F5) or the communication links (K1, ..., K4) on the hardware resources or communication resources respectively planned for this purpose, and the reorganization only takes place if the simulation is successful in relation to compliance with the limit value or the limit values.

7. Method according to one of the preceding claims, characterized in that during one or each operation of the communication arrangement, the actual values for the passes of the data signal through the entire route and through a plurality of partial routes, each related to the hardware resources or communication resources actually used, are trained by means of a machine learning system, in particular by means of a neural network, the trained machine learning system being used to determine an optimized organization of the applications (F1, ..., F5) or communication connections (K1, ..., K4) on the currently available hardware resources or communication resources.

8. Method according to one of the preceding claims, characterized in that a bandwidth, a transmission time or a jitter is used as a characteristic for a communication resource, and / or that a computing power, a storage space or a specific functionality is used as a characteristic for a hardware resource.

9. Arrangement for distributing applications (F1, F5) and for configuring communication connections (K1, ..., K4) in a distributed industrial automation system with a number of networked hardware resources for the applications (F1, ..., F5) and communication resources for the communication connections (K1, ..., K4), characterized in that the arrangement comprises a first computer program, in particular a first firmware or operating system routine, for time-stamping a data signal at a first component of the automation system, that the arrangement comprises a second computer program, in particular a second firmware or operating system routine, for reading out and evaluating the time stamp of the data signal at a second component of the automation system, and that the arrangement comprises a third computer program, in particular a third firmware or operating system routine, for organizing the distribution of applications (F1, ..., F5 ) and / or communication connections (Kl , ..., K4 ) is set up according to a method according to one of the patent claims 1-8.

Images