Industrial controller, system and analysis method

Abstract

The invention relates to an industrial controller (100) having a computing unit (1), an operating system (2) and an application program (AW) which is run in the computing unit (1) to control an industrial process. The application program (AW) has at least one main block (OB1) and at least one function block (FB1) and at least one function (FC1) which can be invoked within the main block (OB1). The operating system (2) is designed to process the main block (OB1) cyclically and to execute the program code in the main block (OB1) and is further designed to invoke the at least one function block (FB1) and / or the function (FC1) and, after invocation, to also execute its / their program code / s. The operating system (2) is also designed to include a recording means (3) which, when the main block (OB1) is executed during program execution, records the invocations of the function block(s) (FB1) and / or the function(s) (FC1) coordinated by the operating system (2) as event description data (4) in an analysis memory (5). The operating system (2) is designed to communicate these invocation results (E1,E2,E3) for the event description data (4) to the recording means (3) when the main block (OB1), the function block (FB1) or the function (FC1) is invoked. An output means (6) is also present, which provides the event description data (4) at an interface (7) for an analysis tool (200).

Description

[0001] Description

[0002] Industrial control, system and method for analysis

[0003] The invention relates to an industrial control system with a computing unit, an operating system and a user program which is executed in the computing unit to control an industrial process, wherein the user program has at least one main module and at least one function module and at least one function which can be called within the main module, the operating system is designed to process the main module cyclically and to execute the program code in the main module, further designed to call the at least one function module and / or the function and, after the call, to also execute its program code.

[0004] The invention also relates to a method for analyzing the temporal execution behavior of a user program. For this purpose, in an industrial controller with a computing unit and an operating system, the user program for controlling an industrial process is executed in the computing unit, wherein at least one main module is called in the user program and at least one function module and / or at least one function is called in the main module. The operating system processes the main module and the program code in the main module cyclically. Likewise, the program code in the function module and / or the function is also executed after the call.

[0005] Furthermore, the invention relates to a system for analyzing a temporal behavior of a user program in an industrial control system, comprising the industrial control system, an analysis tool with a computer unit and with a screen and a communication connection.

[0006] For the purposes of the invention, an industrial control system is preferably understood to mean a programmable logic controller (PLC), which is an automation device used to control or regulate a machine or system in an industrial environment. In a cycle-oriented PLC, this cycle is controlled by an operating system permanently stored by the manufacturer. Depending on its program modules, the control program can contain branches and conditional calls, which result in different runtimes.

[0007] For a user of industrial controllers there is currently the option of analyzing and evaluating the runtime behavior of an application on a S IMATIC S7-1500 controller with S IMATIC S7-1500 Profiling see "S IMATIC S7-1500 Profiling Entry ID: 109750245, VI. 0. 2, 11 / 2017". However, this has the disadvantage that two additional blocks have to be introduced into the user program. The user must therefore instrumentalize his user program with this call of FBs, which on the one hand means a lot of adaptation work for the customer, is accompanied by temporal changes in the user program and can only be done after problems have been identified.

[0008] From DE 10 2005 020 507 A1 the setup and conditioning of automation devices is known, in which the expected processing times of programs, subroutines and procedures under predeterminable conditions are calculated in an analysis device.

[0009] EP 2 477 085 B1 introduces a recording device. It is located in the PLC and measures the block times. This corresponds to the block call in the SIMATIC S7-1500 profiling tool.

[0010] It is therefore an object of the present invention to provide the user with an improved analysis option for subsequent optimization of the temporal behavior of the control program. This object is achieved in that the operating system is further configured with a recording means which, when the main module is executed during program execution, records the calls of the function module(s) and / or the function(s) coordinated by the operating system as event description data in an analysis memory. The operating system is configured to communicate these call events for the event description data to the recording means when the main module, the function module or the function is called. Furthermore, an output means is provided which provides the event description data at an interface for an analysis tool. The recording means is configuredFor each call event, a data record with at least the following data structure is stored in the analysis memory: an event ID, an event category, an event type, a timestamp, a process ID, a thread ID. This is very useful in terms of a raw data format.

[0011] The data required for profiling the application program is now always recorded. The user does not have to do anything and can access the data at any time.

[0012] The goal of an analysis is to identify various program sections that can or must be optimized to increase application speed and responsiveness, and reduce memory and resource consumption. This operating system-internal solution does not impact the runtime of the user program. From a raw data format for the event description data, the data can be processed so that it can be visualized using standard tools. As an example, a Chrome browser with the tracing function (URL: chrome: / / tracing / ) could be used here.

[0013] According to the invention, a PLC is now available to which a profiler can be connected for analysis. Profilers are tools for analyzing the runtime and other metrics of software. Profiling tools allow bottlenecks to be quickly and easily identified and problems to be resolved.

[0014] A relatively simple format accepted by browsers with tracing viewer functionality is the JSON array format. Essentially, it is an array of event objects. The events do not need to be sorted by timestamp. The event ID would then correspond to the called module, and additional information could even be provided if needed, namely an event name such as "FBI."

[0015] A further advantageous embodiment provides that the interface is designed as an application programming interface for a web server or a web browser.

[0016] Users can now communicate with the analytics store through the application programming interface via a request channel and a delivery channel.

[0017] To prevent data loss due to overwriting during recording, the analysis memory is divided into a plurality of buffer memories, and the operating system has a memory management tool designed to coordinate the write accesses of the recording tool to the analysis memory and to redirect them to different buffer memories in the event that a buffer memory is blocked for further write accesses in the interests of data consistency. The permanent data accesses to the memory must not affect existing data; if a buffer is currently being queried, it is frozen.

[0018] The inventors recognized that there is a need for PLC devices that are "ready to run" or function immediately "out of the box," especially with regard to data profiling, without having to make changes to the PLC itself. Users can quickly answer the following questions:

[0019] - What is the current utilization of the PLC?

[0020] - Which blocks have the longest runtime?

[0021] - Which block creates a bottleneck?

[0022] - Where are the hot spots in the application (due to inefficient programming)?

[0023] The solution is that this information can be retrieved as raw data directly from the PLC using the modern WebAPI, accessed on a client system, and displayed graphically. This provides the user with transparency regarding the execution levels and program sections, runtime optimization and error diagnostics, evaluation of the system's performance reserves, and quality assurance of the application in the PLC.

[0024] A profile view is then created on a graphical tool for later optimization of the runtime fluctuation, in which, for example, only the OBs (main OB) and interrupt events can be seen. Communication information (e.g. communication task by priority) may also be responsible for heavy loads and interruptions.

[0025] The object mentioned at the outset is also achieved by a method for analyzing the temporal behavior of a user program. For this purpose, in an industrial control system with a computing unit and an operating system, the user program for controlling an industrial process is executed in the computing unit, wherein at least one main block is called in the user program and at least one function block and / or at least one function is called in the main block. The operating system processes the main block and the program code in the main block cyclically. Likewise, the program code is also executed in the function block and / or in the function after the call. A recording medium is operated in the operating system.which, when the main module is executed during program execution, records the calls of the function module(s) and / or the function(s) coordinated by the operating system as event description data in an analysis memory. For this purpose, the call events are communicated by the operating system when the main module, the function module or the function is called to the recording device for entry in the event description data. Furthermore, the event description data is provided via an output device to an interface for an analysis tool. The recording device stores a data record with at least the following data structure in the analysis memory for each call event: an event ID, an event category, an event type (ET), a timestamp, a process ID, a thread ID.

[0026] The method described allows users to retrieve raw data from the PLC for a precise analysis of the runtime behavior of a PLC project. It supports the identification of time-consuming program sections, inefficient programming, and enables the early detection of runtime problems.

[0027] To obtain the necessary raw data, namely the profiling data, neither the application program needs to be modified, nor does the temporal behavior of the application program change. Customers who detect a problem in their application program can immediately analyze their problem using the profiling data.

[0028] The profiling data can be converted into any data format for other profiling tools. Furthermore, the total and actual times of each call in the PLC project can be recorded and displayed with cycle precision.

[0029] A block ID and from this the name, e.g. "FBI", can be derived from the event ID. This additional information is retrieved via an API call when required.

[0030] This allows for a type-based view that allows for easy comparison of different instances and calls. A flow structure of the user program for one or more cycles can be displayed. Detecting hotspots in a cycle and displaying jitter behavior for individual OBs is now possible.

[0031] For this purpose, the interface is operated as an application programming interface for a web server or a web browser and the event description data can be evaluated by a user by means of a graphical display on a screen.

[0032] The web server or the web browser can select desired data via the application programming interface using a request channel and receive the desired data via a delivery channel.

[0033] For data consistency, the analysis memory is divided into a plurality of buffer memories and the operating system coordinates the write accesses of the recording medium to different buffer memories of the analysis memory by means of a memory management means, in the event that, in favor of data consistency, a certain buffer memory is blocked for further write accesses.

[0034] By dividing the data into several individual buffers, data consistency can be achieved because access to the buffer must not affect existing data. If a buffer is currently being queried, that buffer is frozen.

[0035] The object mentioned above is also achieved by a system for analyzing the temporal behavior of a user program in an industrial control system. For this purpose, the system comprises the industrial control system, an analysis tool with a computer unit and a communication connection with a screen. The industrial control system comprises a computing unit, an operating system and a user program which is executed in the computing unit to control an industrial process. The user program has at least one main module and at least one function module and at least one function which can be called within the main module. The operating system is designed to process the main module cyclically and to execute the program code in the main module. It is further designed to call the at least one function module and / or the function and, after the call, also to execute its program code.The operating system is further configured with a recording device which, when the main module is executed during program execution, records the calls of the function module(s) and / or the function(s) coordinated by the operating system as event description data in an analysis memory. The operating system is configured to communicate these call events for the event description data to the recording device when the main module, the function module or the function is called. Furthermore, an output device is provided which provides the event description data at an interface for the analysis tool. The analysis tool is configured with a software-based graphic display device to display the event description data on the screen for evaluation by a user. An exemplary embodiment of the industrial control system,and the system, in which the procedure is explained in more detail, is shown in the drawing. Shown are:,

[0036] FIG 1 an industrial control system according to the invention,

[0037] FIG 2 a data set with event data,

[0038] FIG 3 the industrial control system known from FIG 1 with AB queries,

[0039] FIG 4 a data query mask of an analysis tool,

[0040] FIG 5a shows a possible screen display using a software-based display means and

[0041] FIG 5b shows a possible screen display using a software-based display means in tabular form.

[0042] 1 shows an industrial controller 100, in particular a PLC, with a computing unit 1, an operating system 2 and a user program AW. The industrial controller 100 is designed to repeatedly execute the user program AW by means of a cyclic program execution Z. In the present example, a main block UB1 calls a function block FBI and the function block FBI in turn calls a function FC1. The operating system 2 is designed to cyclically process the main block OBI and to execute the program code in the main block OBI. Likewise, the operating system is designed to execute the program code of the function block FBI and / or the function FC1 after calling them.

[0043] According to the invention, the operating system 2 now has a recording means 3 which, when the main block OBI is executed during program execution, is designed to record the calls of the function block FBI and the function FC1 coordinated by the operating system 2 as event description data 4 in an analysis memory 5. When the main block OBI, the function block FBI, or the function FC1 are called, the operating system 2 is designed to communicate the corresponding call events E1, E2, E3 or corresponding end events E1', E2', E3' to the recording means 3. Furthermore, an output means 6 is provided in the industrial controller 100, which is designed to provide the event description data 4 at an interface 7 for an analysis tool 200.

[0044] Starting from the user program AW, this generates an OB1 call 30 which executes the main block OBI. In the main block OBI, the main block OBI generates an FBI call 31 which calls the function block FBI. Within the function block FBI, an FC1 call 32 is executed which calls the function FC1. Each of the named calls generates a call event E1, E2, E3. If the main block OBI is called, the operating system 2 records a first call event E1. If the function block FBI is called, the operating system 2 records a second call event E2. If the function FC1 is called, the operating system 2 records a third call event E3. Analogous to the call events, the operating system 2 also records the end events E1', E2', E3'. Once the function FC1 has completed its work, it notifies the end event E3 '.If the FBI function block has completed its work, it communicates this with the end event E2 '. If the main OBI block has been completely executed, this is communicated with the end event E1'. Accordingly, the blocks return the OBl feedback signal 35, the FBI feedback signal 34, and the FCl feedback signal 33.

[0045] The analysis memory 5 has a plurality of buffer memories buf 1 , bufn and the operating system 2 has a memory management means 8 which is designed to coordinate the write accesses of the recording means 3 to the analysis memory 5 and to redirect them to different buffer memories buf 1 , bufn in the event that a buffer memory bufl is blocked for further write accesses in favor of data consistency.

[0046] The event description data 4 (or 4' or 4'') can thus be communicated to the analysis tool 200 via the interface 7. The analysis tool 200 has a computer unit 201 with a screen 202 and is connected to the interface 7 via a communications link 203. The event data can be displayed on the screen 202 via a software-based graphic display 204.

[0047] FIG. 2 shows the event description data 4 using the example of the second call event E2. The following data structure DS is stored in the analysis memory 5 in the data set D: an event ID E-ID, an event category EK, an event type ET, a timestamp TS, a process ID P-ID, a thread ID T-ID, and an entry for a nesting depth e args = level : 3.

[0048] A line could look like this: {"name":"FB 52", "cat":"FB", "ph" : "B", "pid" : 1, "tid": 127, "ts" : 104484883526.7440, "args": {"level": 3}},

[0049] The event category EK can be an OB call, an FB call, an FC call, a process image (PII and PAA) update or a direct write to a peripheral.

[0050] If the inputs and outputs are accessed in the user program via the "I" or "Q" operands, there is no direct access to the input and / or output modules. In this case, a memory area in the CPU's system memory is accessed. This area is referred to as the process input image (PII) and process output image (PIQ). The contents of the process image (PII and PIQ) do not reflect the current values ​​of the inputs and outputs, but rather the values ​​at the time the process image is updated.

[0051] If more current values ​​are required for individual processes, direct peripheral addressing is also possible.

[0052] Likewise, I / O addresses outside the process image can also be assigned to the inputs and outputs of peripheral modules. These I / O addresses must be accessed via "peripheral addressing." For better understanding, this article first describes the various process image types and then "peripheral addressing."

[0053] OBl process abb i 1 d

[0054] The OBl process image (OBI-PA) can be used in any CPU. It is updated cyclically before the OBI is processed. Cyclic program processing occurs in the following order:

[0055] Processing of internal tasks of the CPU's operating system. Writing the states from the OBl process image of the outputs to the module outputs. Reading the input states from the modules into the OBl process image of the inputs.

[0056] The update of the OBl process image can then be carried out in the user program with SFC 26 (UPDAT_PI) and SFC 27 (UPDAT_PO).

[0057] In general, the following applies to cyclic updating of the OBl process image:

[0058] The shorter the cycle time, the more frequently the OBl process image is updated.

[0059] The time required to update the process image depends on the specific system. Influencing factors include: the number of individual modules from which data must be read or written.

[0060] The baud rate used for communication with the individual modules. The protocols used to address the individual modules (MPI, PROFIBUS, etc.). If the OBl process image has been enlarged (not possible with all CPUs), the cycle time may also be longer if this means more modules are in the process image.

[0061] Partial process images (TPA)

[0062] In addition to the OBl process image, some CPU types offer the option of using partial process images (TPA). You can assign I / O address ranges of the modules to these partial process images. Each address range can only be assigned to either the OBl process image or a partial process image. Multiple assignments are not possible.

[0063] The process image partitions can be updated in two different ways; in the user program via SFC 26 (UPDAT_PI) and SFC 27 (UPDAT_PO) by assigning a TPA to an OB.

[0064] The data read from / written to the process image partitions is consistent when updated with an SFC up to a CPU-dependent data length. Information about this can be found in the S7 online help for the SFC.

[0065] The output values ​​of the assigned process image subset are written to the outputs immediately after the OB has been processed.

[0066] The "peripheral addressing"

[0067] The process image often does not cover the entire peripheral address range of the CPU.

[0068] If I / O address ranges of a module are located outside the process image, these ranges must be accessed using "peripheral addressing." Access to the peripheral addresses occurs immediately after the address is addressed in the user program. "Peripheral addressing" thus always ensures that the current value is read in immediately or that an output is implemented immediately. This is especially important for analog values ​​and process interrupts.

[0069] "Peripheral addressing" therefore means that the modules are accessed directly. A command in the user program precedes the address range with a "P": .

[0070] In summary, it can be said that the communication events are also recorded, which can then be displayed later in a view.

[0071] For example, the event type ET can contain a B for start or E for end.

[0072] The required data could also be represented as a binary file with an array of runtime data entries (each 16 bytes long), as follows. The byte order of the profiling data is little endian. The format of the data entries (always 16 bytes) depends on the first byte, the entry type. The events can also be a PIP (process image peripheral) for reading and writing.

[0073] The above mentioned block event would then be divided like this The timestamp is given in pico seconds.

[0074] The block type would then look like this: An example:

[0075] 0x01: start of a code block

[0076] 0x02: block type (FC) 0x0012: block number (18)

[0077] 0x0001: OB number (1)

[0078] 0x01: Call hierarchy (1)

[0079] 0x01: Priority (1) 0x0102030405060708: Time stamp [ps]

[0080] 0x10: PIP Read

[0081] 0x0001: PIP ID (1)

[0082] 0x01: Priority (1)

[0083] 0x0102030405060708: Time stamp [ps]

[0084] A communication load can also be recorded:

[0085] Communication load in [%]

[0086] Cycle time:

[0087] Example :

[0088] 0x31: Communication load event

[0089] 0x0012: Communication load (18%)

[0090] 0x00010203: Last cycle time (66051us)

[0091] 0x0102030405060708: Time stamp [ps]

[0092] FIG. 3 essentially shows the industrial controller 100 from FIG. 1. FIG. 3 illustrates how data can be queried via the WEBAP application programming interface, via a request channel 71 and a provision channel 72. A first API call 41 sends a "Get profiling data" request to interface 7, which is configured as a web API.

[0093] The event description data 4 are retrieved as raw data via the request channel 71 in the analysis memory 5 into the corresponding buffer memory buf1, bufn. Additionally, an additional designation of a block ID, for example, FB52, can be obtained via the web-api application programming interface using a special API command, namely the second API call 42 "Get block name."

[0094] FIG. 4 shows a data query 50, as it occurs in the analysis tool 200. The corresponding industrial controller 100 can be selected via a target address setting 51. A data format setting 52, for example, can be preset for the query in a JSON data format. The data is retrieved using the API functionality via a data query button 53.

[0095] {"name":"FB 52", "cat":"FB", "ph" : "B", "pid" : 1, "tid": 127, "ts": 104484883526.7440, "args": {"level": 3}},

[0096] Regarding the write access to the peripherals, such as the peripheral addressing PIP = Process Image Peripheral or Direct, a JSON data format file can also look like this: { "name" : "PIP

[0097] WRITE", "cat" : "PIP", "id" : "2", "ph" : "0", "pid" : 1.0, "tid" : 1, "ts" : 129789199.4574, "args": {"snapshot": {"params": {" read" : 0, "0B61cycle" : 147}}}} ,

[0098] { "name" : "PIP

[0099] READ", "cat" : "PIP", "id" : "1", "ph" : "0", "pid" : 1.0, "tid" : 1 , "ts":129789225.9189, "args": { "snapshot" : { "params" : { "read" : 0, "0B61cycle" : 147}}}} ,

[0100] { "name" : "DIRECT

[0101] WRITE", "cat" : "DIRECT", "id" : "5", "ph" : "0", "pid" : 16, "tid ": 1, "ts" : 129790110.6174, "args" : { "snapshot" : { "params" : {"write address" : "Q1032.0" , "db" : 0, "type" : "byte 8 bit", "value" : "Oxff ", "OB33cycle" : 184}}}} ,

[0102] { "name" : "ASLOG", "cat" : "DIAG", "id" : "3", "ph" : "O", "pid" : 16, "tid" : 1, "ts" : 1297901143070, "args":{"snapshot":{"params":{"error": "0x2943", "OB33cycle":184}}}},

[0103] JSON stands for "JavaScript Object Notation"

[0104] FIG 5a shows a possible screen display using a software-based display using chrome : / / tracing / as an example.

[0105] The view can be used to examine the behavior of a block. The length of the bar corresponds to the runtime for the block call. Call sequences in blocks can be made visible, and individual unusually long functions can be quickly identified. A search can be performed for the longest and second-longest blocks, which can then be examined more closely. It is possible to search for an OB with a short call interval and a long runtime. Color coding can help differentiate the blocks. Search for the FB or FC that is called very frequently and thus has the longest total runtime; this promises the greatest success after subsequent optimization.

[0106] You can get a general overview of the distribution of the total runtime across the respective modules and gain insight into the call structure. Library and operating system modules can be hidden. Furthermore, it is possible to forward the profiling data to customer support to monitor the performance of library modules or hardware across multiple versions.

[0107] Making all events visible with a breakdown of the individual events on the screen helps the commissioning engineer when troubleshooting. The direct write accesses to the I / O could also be shown as small circles in Figure 5a. If, for example, in addition to the OBI, a cycle OB a special OB is called by an interrupt and something is calculated in this special OB, but no write access to the I / O follows, the call to the special OB would be visible in the view according to Figure 5a, but the small circle would be missing. This is then an indicator that an error has occurred, because something is calculated but there is no reaction.

[0108] For example, it is now noticeable that in the area marked with the time span of 4,884 ms, the communication load is greater than in the other areas. You can then zoom in and examine the behavior more closely.

[0109] FIG 5a shows the calls of OB253, OB31, OB92, FB9 and FB239.

[0110] The diagram in FIG. 5b shows that 0B31 and FB239 require the most time, which also indicates potential for optimization. In addition to the diagram in FIG. 5a, the view in FIG. 5b shows additional blocks and function calls.

Claims

Patent claims 1. Industrial control system (100) with a computing unit (1), an operating system (2) and an application program (AW) which is executed in the computing unit (1) to control an industrial process, wherein the application program (AW) has at least one main module (OBI) and at least one function module (FBI) and at least one function (FC1), which can be called within the main module (OBI), the operating system (2) is designed to process the main module (OBI) cyclically and to execute the program code in the main module (OBI), further designed to call the at least one function module (FBI) and / or the function (FC1) and, after the call, also to execute their program code, characterized in that the operating system (2) is further designed with a recording means (3),which, upon execution of the main module (OBI) during program execution, records the calls of the function module(s) (FBI) and / or the function(s) (FC1) coordinated by the operating system (2) as event description data (4) in an analysis memory (5), wherein the operating system (2) is designed to inform the recording means (3) of these call events (E1, E2, E3) for the event description data (4) upon call of the main module (OBI), the function module (FBI) or the function (FC1), that an output means (6) is also present which provides the event description data (4) at an interface (7) for an analysis tool (200), wherein the recording means (3) is designed to store a data record (D) with at least the following data structure (DS) in the analysis memory (5) for each call event (E1, E2, E3): an event ID (B-ID) , an event category (EK) , an event type (ET) , a timestamp (TS) ,a process ID (P-ID) , a thread ID (T-ID) ., 2. Industrial control (100) according to claim 1, wherein the interface (7) is designed as an application programming interface (web-api) for a web server or a web browser.

3. Industrial control (100) according to claim 2, wherein the application programming interface (web-api) is connected to the analysis memory (5) via a request channel (71) and a provision channel (72).

4. Industrial control (100) according to one of claims 1 to 3, wherein the analysis memory (5) has a plurality of buffer memories (buf 1 , bufn) and the operating system (2) has a memory management means (8) which is designed to coordinate the write accesses of the recording means (3) to the analysis memory (5) and to redirect them to different buffer memories (buf 1 bufn) in the event that a buffer memory (bufl) is blocked for further write accesses in favor of data consistency.

5. A method for analyzing the temporal behavior of an application program (AW), for which purpose, in an industrial controller (100) having a processing unit (1) and an operating system (2), the application program (AW) for controlling an industrial process is executed in the processing unit (RE), wherein at least one main block (OBI) is called in the application program (AW) and at least one function block (FBI) and / or at least one function (FC1) is called in the main block (OBI), the operating system (2) cyclically processes the main block (OBI) and the program code in the main block (OBI), and the program code in the function block (FBI) and / or the function (FC1) is also executed after the call, characterized in that a recording means (3) is operated in the operating system (2),which, when the main block (OBI) is executed during program execution, calls of the function block(s) (FB) and / or the function(s) (FC1) coordinated by the operating system (2) as, Event description data (4) is recorded in an analysis memory (5), for this purpose the call events (E1, E2, E3) are communicated by the operating system (3) when the main module (OBI), the function module (FBI) or the function (FC1) is called to the recording means (3) for entry in the event description data (4), furthermore the event description data (4) is made available via an output means (6) at an interface (7) for an analysis tool (200), wherein the recording means (3) stores a data record (D) with at least the following data structure (DS) in the analysis memory (5) for each call event (E1, E2, E3): an event ID (B-ID), an event category (EK), an event type (ET), a time stamp (TS), a process ID (P-ID) and a thread ID (T-ID).

6. The method according to claim 5, wherein the interface (7) is operated as an application programming interface (web-api) for a web server or a web browser and the event description data (4) can be evaluated by a user by means of a graphical display on a screen.

7. The method according to claim 6, wherein the web server or the web browser can select desired data via the application programming interface (web-api) via a request channel (71) and receives the desired data via a provision channel (72).

8. Method according to one of claims 5 to 7, wherein the analysis memory (5) is divided into a plurality of buffer memories (buf 1 , bufn) and the operating system (2) coordinates the write accesses of the recording means (3) to the analysis memory (5) by means of a memory management means (8) and redirects them to different buffer memories (buf 1 bufn), in the event that in favor of a For data consistency, a buffer memory (bufl) is locked for further write accesses.

9. System (101) for analyzing the temporal behavior of an application program (AW) in an industrial controller (100), comprising the industrial controller (2), an analysis tool (200) with a computer unit (201) and with a screen (202) and a communication connection (203). The industrial controller (100) comprises a computing unit (1), an operating system (2), and an application program (AW) which is executed in the computing unit (1) to control an industrial process. The application program (AW) has at least one main module (OBI) and at least one function module (FBI) and at least one function (FC1), which can be called within the main module (OBI). The operating system (2) is designed to process the main module (OBI) cyclically and to execute the program code in the main module (OBI).further configured to call the at least one function block (FBI) and / or the function (FC1) and, after the call, also to execute their program code, characterized in that the operating system (2) is further configured with a recording means (3) which, upon execution of the main block (OBI) during program execution, records the calls of the function block(s) (FBI) and / or the function(s) (FC1) coordinated by the operating system (2) as event description data (4) in an analysis memory (5), wherein the operating system (2) is configured to communicate these call events (E1, E2, E3) for the event description data (4) to the recording means (3) upon call of the main block (OBI), the function block (FBI) or the function (FC1), that an output means (6) is further provided which outputs the event description data (4) to an interface (7) for the analysis tool (200) provides, wherein the recording means (3) is designed to store a data record (D) with at least the following data structure (DS) in the analysis memory (5) for each call event (E1, E2, E3): an event ID (B-ID), an event category (EK), an event type (ET), a time stamp (TS), a process ID (P-ID), a thread ID (T-ID), the analysis tool (200) is designed with a software-based graphic display means (204) in order to display the event description data (4) on the screen in a way that can be evaluated by a user.

Images