Method for configuring an automation system

Abstract

The invention relates to a method for computer-generated configuration of an automation system with the aid of a processing unit, the automation system having a plurality of computing nodes (ECU1, ECU2, FCCS). The method comprises the following steps: a) receiving (S1) a computer-generated sequencing constraint data set (SQ1, SQ2) at the processing unit, the sequencing constraint data set (SQ1, SQ2) describing a software system to be executed on the automation system and comprising software components (SW1-SW3) and executable functional entities (P211-P213) distributed over the plurality of computing nodes and timing, sequencing and concurrency information of the executable functional entities (P211-P213); b) generating (S2) a transition matrix (P1, P2) by the processing unit from the sequencing constraint data set (SQ1, SQ2), the transition matrix (P1, P2) having a plurality of matrix elements, each of the matrix elements describing a transition from one executable functional entity to another executable functional entity by a transition value. transfer of functional entities; c) receiving (S3) a computer-generated communication matrix at the processing unit, the computer-generated communication matrix describing the communication links between computing nodes in the automation system; d) generating (S4) a Markov chain (MC1, MC2, MC) by the processing unit from the sorting constraint data set (SQ1, SQ2) and the communication matrix; e) generating (S5) a distribution function from the Markov chain, the distribution function describing the resources of the computing nodes used by the software components (SW1-SW3) and the runnable functional entities for a specific timing distribution of the software components (SW1-SW3) and the runnable functional entities (P211-P213); f) optimizing (S6) the resource allocation by the processing unit by formulating and solving a constrained optimization problem.

Description

[0001] The invention relates to a method and a system for configuring an automation system having a plurality of computing nodes.

[0002] The design of embedded software systems for use in automation systems includes several interrelated steps, which involve experts from different fields. It starts with the conceptual design of algorithms for signal processing, estimation and control. In the conceptual stage, the principles of information are derived, such as the list of required signals, the types in the structure of the processing algorithm and its parameterization, so as to operate appropriately with the physical system at hand. This stage is often carried out in model-based design tools, such as Matlab / Simulink from Mathworks or the Scade suite from Ansys Esterel.

[0003] After the conceptual design, the algorithms are handed over to software engineers, who split them into software components and executable functions (so-called: runnables), distribute them on embedded computing nodes (electronic control units ECU), combine the runnables, i.e., executable functional entities, with the tasks of the operating system, design scheduling, and design communication between computing nodes.

[0004] At the most advanced level, the design of schedules within a compute node is supported by schedule optimization tools such as the TA suite of Timing Architect. Similar tools, such as Mentor Graphics VSA COM Designer, optimize the communication design of bus systems.

[0005] The interaction between subject matter experts in the conceptual phase and the software engineering phase is problematic. These groups use different languages, different models, and different tools. However, proper communication between the algorithm designers (signal processing and control engineers) and the software engineers is crucial to ensure that the executables of the algorithm are executed in the proper order and at the proper timing when deployed. Negligence in this regard leads to inappropriate deployment defects, which need to be detected and debugged during the verification action.

[0006] In the conceptual phase of embedded software design, many concurrent software components must be scheduled to run partially in parallel and partially sequentially to meet time constraints. Discovering from the architectural structure how each of the software elements can affect each other and the entire project can reduce costs and problems later on.

[0007] Software architecture can be defined in a variety of languages ​​such as UML, SysML, EAST-ADL, AADL, etc. Regarding timing, ARINC, Amalthea, and EAST-ADL define timing constraints for embedded preemptive target environments. However, from a software architecture perspective, timing analysis of software execution in a preemptive operating system is critical to the correct design of embedded software.

[0008] It is therefore an object of the present invention to provide a method and system for configuration of embedded software for use in an automated system that enables automated and easy timing analysis of software execution.

[0009] This object is solved by a method according to claim 1, a computer program product according to the features of claim 12 and a system according to the features of claim 13. Further embodiments are set forth in the dependent claims.

[0010] According to a first aspect of the present invention, a method for computer-implemented configuration of an automation system having a plurality of computing nodes by means of a processing unit is provided. The method comprises a step a), receiving a computer-generated sequencing constraint data set at a processing unit, the sequencing constraint data set describing a software system to be executed on the automation system and comprising software components and executable functional entities distributed on a plurality of computing nodes and timing, sequencing and concurrency information of the executable functional entities. The method comprises a step b), generating a transfer matrix from the sequencing constraint data set by the processing unit, the transfer matrix having a plurality of matrix elements, each matrix element describing a transfer from one executable functional entity to another executable functional entity by a transfer value. The method comprises a step c), receiving a computer-generated communication matrix at the processing unit, the computer-generated communication matrix describing a communication link between computing nodes in the automation system. In addition, the method comprises a step d), generating a Markov chain from the sequencing constraint data set and the communication matrix by the processing unit. The method comprises a step e), generating a distribution function of the Markov chain by the processing unit, the distribution function describing the computing node resources used by the software components and the executable functional entities for a specific timing distribution of the software components and the executable functional entities. Finally, the method comprises a step f) of optimizing the allocation of resources by the processing unit by formulating and solving a constrained optimization problem.

[0011] According to a second aspect, a system for configuring an automation system having multiple computing nodes is proposed, the system comprising a processing unit configured to a) receive a computer-generated sorting constraint data set, the sorting constraint data set describing a software system to be executed on the automation system and including software components and executable functional entities distributed on multiple computing nodes and timing, sorting and concurrency information of the executable functional entities; b) generate a transfer matrix from the sorting constraint data set, the transfer matrix having multiple matrix elements, each matrix element describing a transfer from one executable functional entity to another executable functional entity through a transfer value; c) receive a computer-generated communication matrix, the computer-generated communication matrix describing communication links between computer nodes in the automation system; d) generate a Markov chain from the sorting constraint data set and the communication matrix; e) generate a distribution function from the Markov chain, the distribution function describing the computing node resources used by the software components and the executable functional entities for a specific timing distribution of the software components and the executable functional entities; f) optimize the allocation of resources by formulating and solving a constraint optimization problem.

[0012] The method allows timing analysis of software in preemptive operating systems from a software architecture perspective. Markov chains are used to model software executables based on an architectural approach and as a way to sample execution traces in an automation system with several computing nodes. With this method, it is possible to determine the behavior from a specific executable to the overall overall behavior of a software project. The method can be extended to consider additional modules, such as hardware, communication buses, and automation system behavior, to sample traces and test architectural designs in the early stages of embedded software design.

[0013] With the proposed method, it is possible to approximate the execution time of software components as a probability distribution. It is possible to consider estimating the time repercussions of software components of a software project. In particular, communication bottlenecks with respect to timing can be identified. Concurrent tasks, runnables, communications, computing node topology and software component architecture can be considered by taking into account order and timing requirements to create a stochastic model of the software.

[0014] The method may be performed in the order from steps a) to f) as outlined above. Alternatively, steps a) and c) may be processed in parallel, followed by step b) following step a).

[0015] A data set of sorting constraints is generated from a factor graph, which represents an automation system as a unified graphical symbol. The factor graph supports the design of algorithmic concepts and captures the basic constraints for scheduling algorithmic parts on multiple computing nodes. The factor graph representing the automation system can be annotated with further details to ensure consistency in the design and software engineering fields. As a result of manual work, a factor graph representing the automation system and used to generate sorting constraints can be provided. A possible way to provide a factor graph in a computer-implemented manner is described in the parallel patent application EP18164183.8.

[0016] The computer-generated ordering constraint data set includes a description of each pair of edges that can run functional entities.

[0017] In addition, for each pair of executable functional entities, the computer-generated sequencing constraint data set may include a communication direction, an identifier of an executable functional entity from which the communication is initiated and an identifier of an executable functional entity as a communication recipient, an identifier of the communication signal, and one or more computing nodes involved in the communication. Optionally, additional information may be provided and used to define and describe sequencing constraints describing the software system.

[0018] The communication matrix describes the message exchanges between computing nodes together with the signals contained in the messages and their timing requirements.Using such a communication matrix allows identifying those computing nodes that are part of the software system when running on the automation system and its computing nodes.

[0019] From the communication matrix, each of the runnable functional entities can be assigned to a specific computing node (represented by the modeled scheduler) of the automation system. Thus, a transition graph can be generated that illustrates the relationships between the different entities and their assignment to the different computing nodes (and, accordingly, the schedulers).

[0020] The transfer matrix can be generated from the ordering constraint dataset, where the communication matrix can add the information of which matrix elements belong to which computation nodes.

[0021] According to another preferred embodiment, each executable functional entity has a timing distribution associated with it indicating its execution time, wherein the distribution function obtained in step e) is generated in an iterative manner by changing the execution time by means of Monte Carlo simulation to predict the timing characteristics of the software system. Other probability distribution annotations can describe more complex behaviors, which can affect the scheduling and preemptive response of the system. Other probability distribution annotations can come from the actual execution trajectory or actual goals, prior knowledge or guesses of the executable parts. By assigning a timing distribution to each executable functional entity, an approximation of the execution time of the software component as a probability distribution can be provided. In addition, it is possible to find an optimal solution by changing the execution time by means of Monte Carlo simulation.

[0022] According to another preferred embodiment, the matrix elements of the transfer matrix include execution timing information representing the timing behavior of each executable functional entity. Thus, the timing sequence diagram of each computing node can be obtained from the transfer matrix.

[0023] According to a third aspect, there is provided a computer program product directly loadable into the internal memory of a digital computing unit, comprising software code portions for executing the steps of the method described herein and hereinafter when the product is run on the computing unit. The computer program product may be in the form of a storage medium such as a DVD, CD-ROM, USB memory stick, etc. Furthermore, the computer program product may be in the form of a signal loadable via a wireless or wired communication link.

[0024] Additional embodiments, features and advantages of the present invention will become apparent from the following description considered in conjunction with the accompanying drawings, which show:

[0025] Figure 1 A schematic diagram depicting software systems and computing nodes described as a factor graph.

[0026] Figure 2 Is a description Figure 1 The first part of the software system sorts a part of the constrained data set.

[0027] Figure 3 It is based on Figure 2 The transition matrix generated by the sorting constraint dataset.

[0028] Figure 4 is from Figure 3 The Markov chain generated by the transfer matrix.

[0029] Figure 5 Is a description Figure 1 The second part of the software system sorts a part of the constrained data set.

[0030] Figure 6 It is based on Figure 5 The transition matrix generated by the sorting constraint dataset.

[0031] Figure 7 is from Figure 6 The Markov chain generated by the transfer matrix.

[0032] Figure 8 is based on Figure 1 A Markov chain of executable parts of a software system.

[0033] Fig. 9 is the distribution function obtained after Monte Carlo simulation.

[0034] Fig.10 is a generated execution schedule that is used to feed the optimizer with the resulting setup outlining the timing of some runnables for one compute node and the timing of some runnables for another compute node for further analysis and optimization.

[0035] Fig.11 is the communication matrix.

[0036] The software architecture of a technical system, such as an embedded device of an automation system, is understood at the beginning of its design as the process of defining software components with ports, interfaces, connections and their interactions. At this early stage, some preliminary design estimates are made regarding the concurrency, sequencing and timing of software components based on the available knowledge of the algorithms of the software architecture and the functionality behind them.

[0037] Describing execution timing from a software project architecture view helps predict possible program execution bottlenecks in the later stages of software design. In order to be able to identify execution bottlenecks and approximate the execution time of software components, the method according to the invention uses a known factor graph that describes software architecture algorithms.

[0038] A factor graph is a unified graphical notation for a wide variety of signal processing, estimation, stochastic inference, machine learning, and control algorithms. Factor graphs support the design of algorithmic concepts and capture the essential constraints for scheduling parts of an algorithm across multiple computational nodes. Thus, a factor graph is a graphical representation of a factorized function, as described in detail in [1].

[0039] Figure 1 An exemplary factor graph of a simple software system is illustrated which calculates values ​​from two independent measurements provided by different computing nodes ECU1 , ECU2 by means of known sensor fusion. Figure 1 The factor graph outlined in describes the sensor fusion algorithm. The software system comprises three different software components SW1, SW2 and SW3 running on the computing node FCCS. The software component SW2 receives sensor values ​​from the aforementioned two computing nodes ECU1, ECU2 representing embedded control units.

[0040] In this factor graph, the edges between two software components SW1, SW2, SW3 and between software components SW1, SW2, SW3 and embedded computing units ECU1, ECU2, respectively, describe results whose values ​​are represented by capital letters. Messages from one software component to another software component SW1, SW2, SW3 and embedded computing units ECU1, ECU2, respectively, are represented by messages μ, while the direction of the messages is indicated by thick arrows located adjacent to the corresponding edges.

[0041] Three exemplary software components SW1, SW2, SW3 are associated with corresponding executables P211, P212, P213 (i.e. executable functional entities). Embedded control units ECU1, ECU2 are associated with corresponding schedulers. These executables together with the allocated resources and read or write messages and their execution by the corresponding schedulers will be used to determine an approximation of the execution time of the software system. The process will be described below. For the understanding of the present invention, the detailed interaction between the software components and the embedded control units is not relevant. With respect to the present invention, the factor graph of the software system to be evaluated is considered as given. As Figure 1 The factor graph outlined in can be provided automatically, as described in the applicant's patent application EP18164183.8. Alternatively, such a factor graph can be provided as a result of manual work by a software engineer.

[0042] From the description of the factor graph, one or more runnable ordering constraints can be derived. In addition, a communication matrix describing the communication links between the computing nodes can be generated. The process of automatically generating runnable ordering constraints and communication matrices is not part of the present invention. The generation of their computer implementation using factor graphs as input is described in the applicant's parallel patent application EP18164183.8.

[0043] The runnable sequencing constraints and the communication matrix will be used as input to automatically determine the execution time behavior of the software system. An example of a corresponding sequencing constraint data set received by a processing unit executing the present invention is shown in Figure 2 and Figure 5 Given in.

[0044] For example, the executable ordering constraint is, for example, an XML file that describes, for example, an Amalthea model, including, for each pair of interacting executable functional entities, a communication direction, an identifier of the executable functional entity from which the communication is initiated and an identifier of the executable functional entity that is the recipient of the communication, an identifier of the communication signal, and one or more computing nodes involved in the communication.

[0045] In accordance with Figure 2In the sequencing constraint data set SQ1, four "communications" between pairs of interacting executable functional entities are outlined, by way of example only, starting with the phrase "operable component sequencing constraint" RSC. The starting phrase RSC is followed by the executable component from which the communication is initiated, the arrow, and the executable component that is the recipient of the communication. The executable component sequencing constraint of each "communication" includes information about the order type (here: successor), the pair of executable components from which the communication is initiated and to which the communication goes (here: "COM_R-->RTE2_R" represents the first communication 3a, "RTE2_R-->P212" represents the second communication 3b, etc.), and whether the executable component sequencing constraint is defined by the user (here: false). Information about the direction of communication is indicated by the arrow connecting two executable components. Information about the identifier of the communication signal (such as Figure 1 μ) outlined in and in this example one or more of the computational nodes involved in the communication are missing, although they may be part of the sorting constraint dataset SQ1.

[0046] Assume that the executable of SQ1 is executed by the scheduler corresponding to the computing node ECU2.

[0047] It will be noted that the sorting constraint data set SQ1 is generated from a factor graph, wherein the generation may be made computer generated.The sorting constraint data set is used as a first input to the method according to the invention.

[0048] The transfer matrix P can be constructed from the sorting constraint data set SQ1. The form of the transfer matrix P is

[0049]

[0050] The transfer matrix P has multiple matrix elements P i，j , each matrix element describes a transition from one runnable to another by a transition value. Figure 3 In the figure, Figure 2 Communications 3a and 3b are highlighted with circles. Figure 3 The diagram shows Figure 2 The transfer matrix P1 created by the sorting constraint data set SQ1. The transfer matrix P includes multiple columns i, and the columns i correspond to the number of executables defined and identified in the sorting constraint data set. The number of rows j of the transfer matrix corresponds to the number of columns, i.e. i=j. The number of rows and their order follow the sequence of the executable ordering constraints in the sorting constraint data set. In other words, the columns specify the receiving executables, and the rows specify the initiating executables.

[0051] exist Figure 3 In this example, seven executable components are identified. R 、RTE2 R 、P211、P212、P213、RTE2W ,COM W It will be noted that the index "R" (corresponding to "_R") in the name of the executable refers to a read operation and the index "W" (corresponding to "_W") refers to a write operation of the executable.

[0052] If there is communication between the initiating and receiving executables, the transfer value P i，j will be put into the transfer matrix. The transfer value represents the execution priority and / or information about the amount of resources that can be allocated to a specific executable by the computing node executing the executable. If the transfer value is "1", all resources can be allocated to the executable being executed. If resources must be shared, the transfer value is less than "1". In the case of shared resources, the sum of the transfer values ​​of a row should be equal to "1". If there is no communication between the starting executable and different executables, the transfer matrix P i，j The transfer value in is set to "0".

[0053] According to the example of SQ1 selected, the communication sequence is sequential due to the fact that there is no parallel execution of tasks. As a result, the transfer value is set to "1" if it is set. This is exemplified by the runnable ordering constraint COM_R->RTE2_R, where the transfer value P i，j = 1 is placed in the transfer matrix P (3a). The transfer value "1" is placed in the first row of the transfer matrix and RTE2 R In the column, RTE2 R The next communication is from the executable RTE2 R Initiated and received by executable P211. Therefore, in column P211 of the subsequent row, the transfer value P i，j = 1 is put into the transfer matrix (3b), and so on.

[0054] from Figure 3 The transfer matrix P1 in can be determined as Figure 4 The Markov chain MC1 is shown in Figure 1. The Markov chain includes a number of nodes corresponding to the runnables in the sorting constraint dataset SQ1. Based on the selected example, it can be seen that Figure 4 The Markov chain in the R 、RTE2 R 、P211、P212、P213、RTE2 W and COM W As can be seen from the Markov chain, the sequence of tasks is in a step-by-step order, i.e. sequential.

[0055] Depend on Figure 1 Another software part of the software system defined by the factor graph is composed according to Figure 5 It will be noted that the method can be implemented with a plurality of different sorting constraint data sets, each of which describes a portion of the software system to be evaluated. However, the information about the sorting constraints can also be part of a single sorting constraint data set.

[0056] In accordance with Figure 5 In the sorting constraint data set SQ2, just as an example, note that seven executable components COM R 、RTE1 R 、P11、P12、P13、RTEl W and COM W As will be appreciated, some of the executables in the ordering constraint data set SQ2 (ie, COM W and COM R ) corresponds to Figure 2 The structure of the sorting constraint dataset SQ2 corresponds to the sorting constraint dataset SQ1 as described above.

[0057] Figure 6 The diagram shows Figure 5 The structure of the transfer matrix P2 corresponds to the transfer matrix P2 described above. Figure 5 It can be seen (with the rectangles denoted by 6b) that there are three parallel processes, which are initiated from different executables P11, P12 and P13, but are executed from the same executable RTE1_W (corresponding to the label RTEl). W ) is received. In other words, there are three processes that must be executed in parallel. Assuming that they are implemented by the same scheduler (assumption: computing node ECU1), resources must be allocated to the three runnables P11, P12, P13 simultaneously. As a result, each transfer value is set equally to 1 / 3. Although the starting value of the transfer value can be set arbitrarily, it is a good starting point to distribute the resources of the computing nodes in an equal manner. Later, the adaptation of the transfer value can be performed according to the satisfiability of the timing constraints.

[0058] Figure 7 The diagram shows the Figure 6 The transfer matrix generates the Markov chain MC2. As can be easily seen, the runnable RTEI R The messages are transmitted in parallel to the runnables P11, P12, P13, where they are executed in parallel. The results of the runnables P11, P12, P13 are forwarded to the runnable RTE W Another communication is carried out step by step.

[0059] As in Figure 4 and Figure 7 The Markov chains MC1, MC2 shown in the figure constitute part of the software system as already explained. Figure 8 In this case, the two parts are put together in a joint Markov chain MC, which can be unified according to Figure 3 and Figure 6 The joint Markov chain MC can be derived from the joint transfer matrix (not shown), which is generated by combining the transfer matrices P1 and P2. Figure 8 Obviously, both parts of the software system require executable COM W and COM R . For example, they can be Figure 1 The computing nodes in FCCS are executed.

[0060] Due to different allocations of resources and / or execution times of runnables, the resulting distribution of required resources after Monte Carlo simulation is based on Fig. 9 The counting state diagram is shown in Figure 1. Fig. 9 In FIG. 1 , the state STS of each runnable P211 , P212 , P213 , RTE2_R , RTE2_W , P11 , P12 , P13 , RTE1_R , RTE1_W , COM_R and COM_W and the required resources CTS according to the amount of execution are shown. The runnable is associated with scheduler 1 or 2 , depending on which of them is executing the runnable. It can be seen that scheduler 1 passes runnables COM_R and COM_W less frequently than scheduler 2 . This can be important information about possible resource allocation. Information about resource allocation can be obtained from the fact that, for example, scheduler 1 passes runnable P13 more frequently than other runnables (see Fig. 9 This may indicate an internal resource problem in the compute node.

[0061] The association between runnables and schedulers can be obtained from Fig.11 The communication matrix is ​​obtained from the communication matrix shown in . The communication matrix includes information about the message msg, the signal Sig and the embedded control units ECU1, ECU2 involved, where the things involved include read (R) or write (W) operations. The generation of the communication matrix is ​​described in the parallel patent application EP18164183.8. The communication matrix allows the generation of the necessary amount of schedulers and associated interfaces. As a result, sub-matrices of the transfer matrix are determined, where each sub-matrix is ​​associated with a scheduler. It will be noted that if different parts of the software system require executable parts (in the example: COM W and COM R ), the sub-matrices can be determined so that they overlap.

[0062] The estimation of the execution timing transfer matrix shows the timing behavior of the software components, such that Fig.10 The sequence diagram shown in can be obtained and used for further analysis. Using the ordering constraints from the latter process, a sequence diagram can be obtained. In addition, annotating additional information such as data aging constraints can more accurately define the timing constraints and derive minimum / maximum timing constraints. The allocation of runnables to a given embedded compute node and the final Fig.11 The communication matrix of ,shows the allocation of a specific scheduler.

[0063] exist Fig.10 In FIG. 1 , a timing diagram for the execution of some of the executable parts is shown. As an example only, the aforementioned embedded control units ECU1, ECU2 are configured in different ways. The timing diagram of ECU2 is shown in FIG. Fig.10 In the upper part of Fig.10 The upper part of ECU1 has several software components, but no description is made about the timing and sequencing. ECU1 on the other hand is parameterized so that the software components must follow a specific sequence pattern and must complete the calculation within a specified time lapse. The timing sequence of ECU1 is shown in Fig.10 This parameterization can be put into the corresponding transfer values ​​of the transfer matrices P1 and P2.

[0064] exist Fig.10 In, p j Describes the estimated processing time (execution time) of task j. j represents the release time (start time) of task j that becomes available for processing. The due date (required end time) of task j is denoted by d j express.

[0065] For the executables P11, P12 and P13 executed by ECU2, the release time r 11 、r 12 、r 13 The estimated processing time of tasks P11, P12, and P13 is different (indicated by the width of p11, p12, and p13). Fig.10 As can be seen, the actual release time of the three processes P11, P12, and P13 is at different times. For example, the expiration date d of the three processes P11, P12, and P13 executed by ECU2 is 11 d 12 d 13 are simultaneous. Since each of the processes P11, P12, and P13 is due on the corresponding due date d 11 d 12 d 13The time period indicated by COM R / W after the completed processes P11, P12, P13 indicates the time required for a communication purpose, such as reading or writing information to a communication line.

[0066] The processes P211, P213 and P212 executed by ECU1 are parameterized so that the software components must follow a specific sequence pattern. In particular, as the first process, process P211 starts at a release time r211. As soon as process P211 ends, process P212 starts. Furthermore, as soon as process P212 ends, process P213 starts. After process P213 ends, the communication process COM_W follows. Each of the processes has a different release time r211, r212 and r213, as well as a different expiration date d 211 d 212 d 213 .

[0067] Each executable P11, P12, P13 and P211, P212, P213 has a timing distribution associated with it. The timing distribution indicates its execution time, where Fig. 9 The distribution function shown in is generated in an iterative manner by varying the execution time with the aid of Monte Carlo simulation to predict the timing characteristics of a software system. The timing function can be as follows Fig.10 Alternatively, the time series distribution may be a beta distribution or a uniform distribution.

[0068] By changing the timing distribution, it is checked whether the timing constraints are satisfied or can be satisfied. In particular, with respect to ECU2, it is checked whether each of the processes P11, P12, P13 can meet the due date d even if the estimated processing time of these tasks P11, P12, P13 is changed according to the timing distribution as shown in the figure. 11 d 12 d 13 The same thing is done for the processes P211, P212, and P213 executed by ECU1.

[0069] like Fig.10 The layout of the execution schedule shown in can be described as an optimization problem, or as a SAT (satisfiability problem). Such a representation allows to find precisely the timing requirements that may not be met. In case of infeasible solutions, the root cause will be discovered by so-called helper variables.

[0070] In this context, the SAT description of the problem proves whether a given timing constraint can be preserved for a set of samples from a Monte Carlo simulation of the software setup, i.e., if a solution to the problem exists within a feasible set of constraints, it can be preserved in terms of timing at the current stage. Specifically, for example, the execution sample of P212 must be produced within the constraint r212<= p212<= d212 to satisfy the setup requirements.

[0071] Such timing constraints are Fig.10 is automatically generated as seen in , and can be solved by pinpointing the bottleneck within the setting. The generation consists of obtaining Fig.10 , placing them so that the sequence is preserved, and permuting the upper bounds so that the corresponding sequence is also preserved.

[0072] To summarize the method described above, by generating a Markov chain (describing a software system to be executed on an automated system and including software components and runnables distributed over multiple computing nodes) from a sorted constraint dataset and performing a Monte Carlo simulation, it is possible to apply optimization to describe possible time execution scenarios in a software project based on the architectural description of the software project and its component layout. The method starts with deriving a Markov chain model from a factor graph of the software system. Thus, manual modeling can be avoided, allowing a quick and direct application of the method explained above.

[0073] Markov chains and Monte Carlo optimization are a group of methods from the field of stochastic analysis for sampling data from unknown or partially known random processes and efficiently estimating the underlying model. These models can be used for later inference or simulation purposes. For this model identification, measured data or data generated from a Markov process model can be used to fit an assumed model.

[0074] The Markov chain is generated from the ordering constraint dataset and a communication matrix derived from a factor graph. The transition matrix generated from these two inputs has certain properties and is used to model aspects of sequencing, runnable priorities, and communication timing. For each compute node, the scheduler is modeled with a constrained range of stages. This means that all other states cannot be reached by the submatrix of that region.

[0075] In the case of relative positioning constraints, the estimated temporal layout of the problem can be described by annotating the runnables with estimates of transition probabilities. The resulting graph can be transferred to several Markov chains running in parallel (see Figure 4 and Figure 7 ). Monte Carlo simulation helps predict integration timing characteristics and allows identification of infeasibility issues such as worst-case scenarios, scheduling bottlenecks, resource starvation, resource leakage, etc.

[0076] Using probability distribution annotations for different runnables allows for describing complex behaviors that can affect the scheduling and preemption response of the system. The probability distribution can be, for example, a truncated normal distribution, a gamma distribution, a beta distribution, or a uniform distribution. By assigning a gamma distribution to a runnable, it can be stated that the execution time is typically at a certain peak, but due to, for example, convergence criteria, the execution time may take longer or shorter than expected depending on the situation. By using a beta distribution, it can be described that a software component has a predictable distributed time that is typically at a certain peak. The uniform distribution is a bounded description of a random process (such as the execution of a software component) that can be applied where the number of operations is predictable and finite, but there may be some variation in the operation times.

[0077] The characterization of each of the software components can be expanded with the aid of other deterministic descriptions of the process or time behavior, for example by means of a state-space system model, a Gaussian random walk, a nonlinear system description or other representations.

[0078] The totality of each software component determines how the system as a whole behaves. Based on this representation, the model can be set up and then solved in a Monte Carlo simulation, showing the resulting transfer histogram, as in Fig. 9 Seen in.

[0079] To identify bottlenecks in the architecture execution with respect to timing issues, a Markov Chain Monte Carlo simulation is set up using timing, sequencing, and concurrency constraints.

[0080] References

[0081] [1] "The Factor Graph Approach to Model- Based SignalProcessing" by Loelinger et al., Vol. 95, No. 6, June 2007, Proceedings of the IEEE.

Claims

1. A method for computer-implemented configuration of an automation system by means of a processing unit, the automation system having a plurality of computing nodes (ECU1, ECU2, FCCS) suitable for allocating resources to a software system, the method comprising the following steps: a) receiving, at a processing unit, a computer-generated sequencing constraint data set (SQ1, SQ2), the sequencing constraint data set (SQ1, SQ2) describing a software system to be executed on an automation system and comprising software components (SW1-SW3) and runnable functional entities (P211-P213) distributed over a plurality of computing nodes (ECU1, ECU2, FCCS) and timing, sequencing and concurrency information of the runnable functional entities (P211-P213); b) generating, by a processing unit, a transition matrix (P1, P2) from the ordering constraint data set (SQ1, SQ2), the transition matrix (P1, P2) having a plurality of matrix elements, each of which describes a transition from one executable functional entity to another executable functional entity by a transition value; c) receiving at a processing unit a computer-generated communication matrix describing communication links between computing nodes (ECU1, ECU2, FCCS) in the automation system; d) generating, by a processing unit, a Markov chain (MC1, MC2, MC) from a sorting constraint data set (SQ1, SQ2) and a communication matrix, the Markov chain (MC1, MC2, MC) describing a software system to be executed on the automation system and comprising software components and runnables distributed over a plurality of computing nodes; e) generating, by the processing unit, a distribution function from the Markov chain (MC1, MC2, MC), the distribution function describing, for a specific timing distribution of the software components (SW1-SW3) and the runnable functional entities (P211-P213), resources of the computing nodes (ECU1, ECU2, FCCS) to be allocated to the software components (SW1-SW3) and the runnable functional entities (P211-P213); and f) The processing unit performs a Monte Carlo simulation on different resources used by the executable functional entities (P211-P213) and different execution times of the executable functional entities (P211-P213), outputs a graph of resources required by the executable functional entities (P211-P213), and determines the optimal resource allocation of the executable functional entities (P211-P213).

2. The method according to claim 1, wherein steps a) and c) are processed in parallel, followed by step b) following step a).

3. The method according to claim 1 or 2, wherein the computer-generated sequencing constraint data set (SQ1, SQ2) is generated from a factor graph representing the automation system as a unified graphical notation.

4. The method according to claim 1 or 2, wherein the computer-generated ordering constraint data set (SQ1, SQ2) comprises a description of the edges of each pair of executable functional entities (P211-P213).

5. The method according to claim 1 or 2, wherein the computer-generated sorting constraint data set (SQ1, SQ2) comprises, for each pair of executable functional entities (P211-P213): - direction of communication, - the identifiers of the executable functional entity from which the communication originates and the executable functional entity that is the recipient of the communication, - an identifier of the communication signal, - One or more computing nodes involved in the communication (ECU1, ECU2, FCCS). 6 . The method according to claim 1 , wherein the communication matrix describes the message exchanges between the computing nodes (ECU1 , ECU2 , FCCS) together with the signals contained in the messages.

7. The method according to claim 1 or 2, wherein each of the executable functional entities is assigned to a specific computing node of the automation system according to a communication matrix.

8. The method according to claim 1 or 2, wherein a transfer matrix (P1, P2) is generated from a sorting constraint data set (SQ1, SQ2), wherein a communication matrix adds information about which of the matrix elements belongs to one of the computing nodes (ECU1, ECU2, FCCS).

9. A method according to claim 1 or 2, wherein each executable functional entity has a timing distribution associated with it indicating its execution time, wherein the distribution function obtained in step e) is generated in an iterative manner by changing the execution time with the help of Monte Carlo simulation to predict the timing characteristics of the software system.

10. The method according to claim 1 or 2, wherein the matrix elements of the transfer matrix (P1, P2) include execution timing information representing the timing behavior of each executable functional entity. The method according to claim 10 , wherein a timing sequence diagram of each computing node is obtained from the transfer matrix.

12. A computer program product directly loadable into the internal memory of a digital computing unit, comprising software code portions for performing the steps of any one of claims 1 to 10 when said product is run on a computing unit.

13. A system for computer-implemented configuration of an automation system having a plurality of computing nodes (ECU1, ECU2, FCCS) adapted to allocate resources to a software system, the system comprising a processing unit configured to: a) receiving a computer generated sequencing constraint data set (SQ1, SQ2), the sequencing constraint data set (SQ1, SQ2) describing a software system to be executed on an automation system and comprising software components (SW1-SW3) and runnable functional entities (P211-P213) distributed on a plurality of computing nodes (ECU1, ECU2, FCCS) and timing, sequencing and concurrency information of the runnable functional entities (P211-P213); b) generating a transition matrix (P1, P2) from the sorting constraint data set (SQ1, SQ2), wherein the transition matrix (P1, P2) has a plurality of matrix elements, each of the matrix elements describing a transition from one executable functional entity to another executable functional entity by a transition value; c) receiving a computer generated communication matrix describing communication links between computing nodes (ECU1, ECU2, FCCS) in the automation system; d) generating a Markov chain (MC1, MC2, MC) from the ordering constraint data set (SQ1, SQ2) and the communication matrix, the Markov chain (MC1, MC2, MC) describing a software system to be executed on the automation system and comprising software components and runnables distributed over a plurality of computing nodes; e) generating a distribution function from the Markov chain (MC1, MC2, MC), the distribution function describing the resources of the computing nodes (ECU1, ECU2, FCCS) to be allocated to the software components (SW1-SW3) and the runnable functional entities (P211-P213) for a specific timing distribution of the software components (SW1-SW3) and the runnable functional entities (P211-P213); f) The processing unit performs a Monte Carlo simulation on different resources used by the executable functional entities (P211-P213) and different execution times of the executable functional entities (P211-P213), outputs a graph of resources required by the executable functional entities (P211-P213), and determines the optimal resource allocation of the executable functional entities (P211-P213).

Images