EP3446216A1 - Echtzeitumgebung und speicherprogrammierbare steuerung - Google Patents

Echtzeitumgebung und speicherprogrammierbare steuerung

Info

Publication number
EP3446216A1
EP3446216A1 EP17720035.9A EP17720035A EP3446216A1 EP 3446216 A1 EP3446216 A1 EP 3446216A1 EP 17720035 A EP17720035 A EP 17720035A EP 3446216 A1 EP3446216 A1 EP 3446216A1
Authority
EP
European Patent Office
Prior art keywords
time
function
watchdog
real
monitoring function
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP17720035.9A
Other languages
English (en)
French (fr)
Inventor
Marko TSCHEREPANOW
Dirk Janssen
Andre FOLKERS
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beckhoff Automation GmbH and Co KG
Original Assignee
Beckhoff Automation GmbH and Co KG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beckhoff Automation GmbH and Co KG filed Critical Beckhoff Automation GmbH and Co KG
Publication of EP3446216A1 publication Critical patent/EP3446216A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/054—Input/output
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4887—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues involving deadlines, e.g. rate based, periodic
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/11—Plc I-O input output
    • G05B2219/1134—Fieldbus

Definitions

  • Real-time environment and programmable logic controller The invention relates to a real-time environment and a SpeI ⁇ logic controller.
  • PLC programmable logic controller
  • the control of actuators and sensors takes place on the PLC in the form of tasks, so-called tasks.
  • the tasks are often executed cyclically.
  • a PLC can also distribute tasks across multiple cores of a processor or multiple processors.
  • a central task of the PLC in controlling the actuators and sensors is synchronization with the production process.
  • a controller with function blocks is also described, wherein the function blocks can contain a real ⁇ time function.
  • the real-time function is off, broken when the computing time exceeds a predetermined Re ⁇ conference time.
  • DE 10 2009 055 752 A1 further discloses a method in which a task can be interrupted in favor of another task.
  • a production system In addition to the actuators and sensors that are controlled by the PLC, a production system usually has a large number of other systems whose functions must be synchronized with the production process and its control by the PLC.
  • vision systems an essential Be ⁇ stand part of modern production facilities. They serve for object recognition, surface inspection, measurement or identification. In vision systems have a variety of image processing and image analysis operations are performed, which are preferably to be in synchronism with the production process Runaway ⁇ leads.
  • Another additional function to be synchronized with the production process is condition monitoring, in which a regular or permanent recording and evaluation of the condition of the production plant is carried out by measuring and analyzing machine parameters that reflect the current state of the production process. Also in the field of machine learning, a synchronization of additional functions with the production process is desirable. The same applies to the numerical control, in which a program code is converted into working or movement sequences for a machine.
  • Vision systems as well as the other additional systems mentioned Condition Monitoring, Machine Learning and Numerical Control are usually in the form of separate software components separated from the PLC.
  • vision systems usually separate image processing computer or smart cameras are used, which are connected to the PLC via a Kom ⁇ munikationsmedium for example the Ethernet, I / Os or egg NEN field bus, to transmit the calculation results to the PLC.
  • the connected cameras transmit the images or image regions to the image processing computer, which then carries out the problem-specific image analysis.
  • the vision function can also be performed directly on the camera.
  • the cameras can also have their own I / Os to communicate directly with the actuators and sensors of the production plant after appropriate configuration. It is then for the actuators and sensors of the production plant, the Mög ⁇ friendliness to trip over hardware trigger image capture by the cameras or to control the lighting.
  • a software PLC can be used for control and image processing same hardware ⁇ to.
  • the software PLC can also run on the camera, which additionally limits the usually limited computing capacity of the intelligent camera. This approach is therefore only feasible for simple control and vision tasks.
  • a data processing method is described in EP 1 312 990 A2 with which image and audio data relating to the movement sequence of a machine can be linked to the data of the movement and drive control of the machine.
  • the image and audio data are provided with a time stamp generated by the motion and drive control.
  • the image and audio data synchronized in time to the data of the movement and drive control of the machine can then be further processed or displayed.
  • a significant problem in the synchronization of additional functions, such as vision systems, the production process is that their maturity strongly with output data is affected by a ⁇ .
  • condition monitoring time series are often analyzed with the aid of iterative methods whose duration depends on the achievement of a quality criterion.
  • the required computation time for example for training and the application of classifiers or function approximators, depends significantly on the input data.
  • the numerical control uses complex iterative optimization algorithms whose runtime varies.
  • the object of the present invention is to provide a real-time environment and a programmable logic controller circuitzustel ⁇ len that allow integration of additional functions with an undefined function term in the real-time environment. This object is achieved with a real-time system according to claim 1 and with a programmable logic controller according to claim 12Q. Preferred developments are specified in the dependent claims.
  • At least one task is executed in the real-time environment with a predetermined task runtime, wherein at least one function is to be executed within the specified task runtime.
  • the execution of the function takes place by starting a time monitoring function, which determines a termination time for the function within the specified task runtime, and then executing the function.
  • the time monitoring function monitors the function run time, wherein a function abort is initiated when the predetermined abort time is exceeded. On closing ⁇ the time monitoring function is terminated.
  • the execution of the additional function is designed such that the functional runtime can be controlled in dependence on the computing time still available in the current cycle of the task.
  • the additional function can therefore be executed directly in the real-time environment of the PLC. Data processing of the additional function outside of the real-time environment and its einherge- Henden communication and synchronization steps entfal ⁇ len. Furthermore, a time-exact coupling of additional function to the timing of the production process is achieved.
  • an abort function is also provided, which is called when the predetermined abort time is exceeded by the function runtime in order to execute the abort function.
  • ab ⁇ working additional function is timely terminated after exceeding the termination time.
  • the function may include an abort condition which, when the predetermined abort time is exceeded by the functional run time, aborts the execution of the function and returns a processing result. Such a procedure ensures a controlled abort of the function. The results of the additional function at the cut-off time can then be fully continue USAGE ⁇ det.
  • the time monitoring function can determine the given abort time when called as the sum of the current time and a maximum allowed time. The termination time can then be determined dynamically and flexibly adjusted. Further, the time monitoring function when quitting may output a parameter indicating the fraction of the carriedgnacsaus ⁇ management. Alternatively or additionally, the parameter may indicate the number of accumulated functional elements. The parameter represents a measure of confidence in the corresponding calculation results of the additional function. The parameter can also be used to carry out an adaptation of the additional function.
  • the function can have a plurality of functional elements, wherein the characteristic value output when terminating the time monitoring function indicates the accumulated component of the execution of the functional elements. With this hens as is possible functional elements to bün ⁇ spindles to monitor their maturity together. Furthermore, loops, for example, which call functional elements iteratively, can also be included in runtime monitoring in a simple manner. The accumulation then calculates the parameters of the transit time monitoring of the individual functional elements to a total result over the entire monitored period of time. Furthermore, the time monitoring function can output a time value when ending, which indicates the time difference between the current time and the predetermined abort time. This determined remaining time can be used, for example, to optimize the execution of the additional function in the real-time environment. Furthermore, a use of a computing time interval in the length of the remaining time by other components of the real-time system is conceivable.
  • the time monitoring function can return an error code representative of an error condition in the exporting ⁇ tion of the time monitoring function when closing further.
  • the time monitoring function may include at least one subordinate time monitoring function element that sets an abort time for an associated function within the predetermined task run time prior to the abort time point of the time monitoring function.
  • time monitoring function is managed using a stack.
  • the stack provides an easy way of forming hierarchical levels of the individual time monitoring function elements by means of an appropriate positioning on the stack.
  • a programmable logic controller is connected via a fieldbus with actuators and sensors of a production plant.
  • the programmable logic controller in this case comprises a real-time environment in the previously explained form whose task is to control actuators and sensors, the execution of the function being synchronized with the control by the time-monitoring function.
  • the programmable logic controller may be connected to a function ⁇ onshim for image acquisition, in order to transmit the image data in the real-time environment, wherein the function is a vision function for processing and / or analysis of image data.
  • Figure 1 shows schematically a structure of a programmable logic controller according to the invention for a production plant, the actuators and sensors and an image detection unit has on ⁇ .
  • Figure 2 shows a structure of a data structure of a time monitoring function, which is executed in a real-time environment according to the invention.
  • 3 shows a structure of a stack with time monitoring ⁇ functions.
  • FIG. 4 shows a possible program flow chart for starting a time monitoring function, which is executed in a real-time environment according to the invention.
  • Figure 5 shows a possible program flow chart for performing a vision function executed in a real-time environment according to the invention.
  • FIG. 6 shows a possible program flow chart for starting a time monitoring function, which is executed in a real-time environment according to the invention.
  • Figure 7 shows an example of propagating the remaining time when performing multiple interleaved time monitoring functions.
  • a programmable logic controller (PLC) 3 is used to control sensors 1 and actuators 2, which, as shown in FIG. 1, is connected via a field bus 4 to the sensors 1 and actuators 2.
  • the PLC can be designed as an independent data processing unit, for example in the form of an industrial PC 5, as shown in FIG. 1, or run as a software PLC additionally on an already existing unit of the production plant.
  • a field bus 4 is a differently configured communica tion ⁇ compound 3 can be inserted for data exchange between the sensors 1 and actuators 2 and the PLC.
  • the processing of the data from or for the sensors 1 and actuators 2 takes place on the PLC 3 in the form of tasks, so-called tasks.
  • the tasks are executed for control of the sensors 1 and actuators 2 generally cyclically, said safety must be provided that the tasks are guaranteed to within ei ⁇ ner predetermined maximum time, for example within the standing for one cycle time available, processed. Furthermore, the cyclic execution of the tasks without jitter must be guaranteed with a predictable response time (latency).
  • This Anforderun ⁇ gen to the PLC 3 are implemented by a real-time environment.
  • production plants usually have a large number of other systems whose functions must be synchronized with the production process and its control with the aid of the sensors 1 and actuators 2 by the PLC 3.
  • Vision systems pose a sol ⁇ ches auxiliary system. With vision systems object detection, surface inspection, a survey or an identification can be performed vide 1952. To achieve these objectives, the vision systems must perform a multi ⁇ number of image processing and analysis operations.
  • image processing and image analysis operations may include, for example, filters, thresholds, morphological
  • the PLC 3, as Fig. 1 shows extended so that image data of a functional unit 6 for Bil ⁇ der charged such as a camera of the vision system di- enter directly into a memory space of the PLC 3.
  • the functional unit 6 for image acquisition is also referred to below as the image acquisition unit 6.
  • Ethernet packets of the image acquisition unit 6 are transmitted directly from a network adapter into the real-time environment of the PLC 3.
  • a protocol-specific processing of the Ethernet packets takes place in order to process and analyze the image data in the real-time environment with the help of vision functions.
  • Ethernet 7 for image data transmission
  • other data bus systems can also be used.
  • the functional run times depend essentially on the available data volume.
  • the processing time can vary greatly in identifying relevant structures within a topological structure analysis, for example, a con ⁇ tures seeking.
  • the iterative application of an algorithm as a function of a convergence criterion for example an iterative filter or a subpixel optimization, can also lead to a fluctuating functional runtime.
  • search strategies for example, that if a first sub-algorithm is unsuccessful, a second sub-algorithm is attempted.
  • a so-called region-of-interest variable size leads to different functional maturity.
  • condition monitoring iterative methods are often used to analyze the recorded data, whereby the running time depends on the achievement of a quality criterion and is therefore not fixed from the outset. Also in the field of machine learning and numerical control and other additional functions to be synchronized with the production process, the functional runtime varies.
  • a time-monitoring function is provided according to the invention, which defines an abort time for the function within the specified task runtime.
  • the time monitoring function is started. The time monitoring function then monitors the functional runtime, wherein a function abort is initiated when the predetermined abortive ⁇ time point is exceeded.
  • the execution of the additional function is designed such that the functional ⁇ running time depending on the current cycle of the task still available computing time can be controlled.
  • the additional function can be executed directly in the real-time environment of the PLC 3, as the cyclic execution of the task can be guaranteed with a predictable response time with the aid of the time monitoring function. Furthermore, a time ⁇ precise coupling of the algorithms performed by the additional function is achieved at the timing of the production process.
  • the time monitoring function also referred to below as a watchdog
  • the time monitoring function can be designed as a wrapper function, which surrounds the additional function.
  • the time monitoring function is executed as a program code which surrounds thetemperatursssoft ⁇ ware.
  • the program code of the additional function then runs within the Pro ⁇ program codes of the time monitoring function.
  • the watchdog can be realized both preemptively and cooperatively. In a preemptive Watchdog the to be executed within the given task runtime ⁇ additional function is temporarily stopped just after exceeding the termination timing. The watchdog ensures continuous monitoring of the functional runtime.
  • an abort function When exceeding the specified differently surrounded abort time point by the function of maturity an abort function is called to the function abort perform.
  • an interrupt program can be set up outside the watchdogs and the per ⁇ bib additional function that is executed to termination date.
  • the abort function can also be part of the watchdog, in which the watchdog program code branches, when the termination condition is satisfied ⁇ by exceeding the predefined termination timing.
  • Aborting the execution of the additional function can be done, for example, via interrupts.
  • a timer is started when starting, which triggers the interrupt on execution, which terminates the additional function to be monitored.
  • the abort of the additional function usually takes place at an unknown program position within the additional function, so that the additional function can be in an undefined state, as a result of which the results of the additional function can often only be used to a limited extent at the abort time.
  • the preemptive watchdog of koopera ⁇ tive watchdog allows a controlled function abort.
  • the program code of the additional function is erwei ⁇ tert by an additional condition is inserted, for example, to function ⁇ specific central processing loops.
  • the additional condition checks the computing time consumed for the algorithm of the additional function at fixed times, for example at the end of the associated processing loop. If it is determined during the review that the function ⁇ term has exceeded the cut-off time, the associated processing loop of the additional function leaving ⁇ sen is.
  • Already existing results of the additional function can be ge ⁇ uses, since the additional function is stopped in a controlled manner by branching out at the end of a processing loop.
  • the abort of the additional function in the cooperative watchdog is, however, generally less accurate than the preemptive watchdog, since only aborts to those times defined by the additional function.
  • the time monitoring function can determine the predetermined termination time t A break when called as the sum of the current time taktueii and a maximum allowable time period At max .
  • the current time t a ktueii can be related to the beginning of lukewarm ⁇ fenden task cycle while: ⁇ ⁇ -Abort -News ⁇ t max (1)
  • Watchdogs which dynamically determine their termination time in accordance with equation (1) are also referred to below as time span watchdogs.
  • the time monitoring function can output a parameter on termination that indicates the proportion of the executed function execution .
  • the indicator while a numerical value can be used by the watchdog function that reflects the purchase in part a f the already completed processing steps in Behaves ⁇ nis to complete processing an additional function f.
  • the calculation of the parameter depends on the algorithmic ⁇ mus the additional function from f.
  • Exemplary variants for calculating the proportion a f for a vision function as an additional function are current share of processed ROI
  • Equation (2) is suitable for algorithms which process all pixels of a region-of-interest (ROI) sequentially, wherein the ROI can also include the entire image.
  • the algorithms used may be, for example, simple convolution filters or threshold operators. Even for more complex algorithms such as labeling or contour search, equation (2) is suitable for calculating the fraction a f .
  • the field of application of equation (3) are mainly itera ⁇ tive algorithms where additional iterations are performed until a desired accuracy is reached. In this case, the accuracy can be specified, for example, by the absolute value of the change in one or more variables to be optimized between two successive iterations of the algorithm.
  • Equation (4) is suitable for complex algorithms that perform alternative processing strategies depending on the results.
  • an algorithm for license plate recognition can only try Data Matrix codes to identify and, if that fails, then another search for QR codes and then perform possibly after eindimen ⁇ dimensional barcodes.
  • Combinations of the above equations for determining the proportion a f for a vision function are also conceivable.
  • the determined characteristic variable which shows the share of the carried radio ⁇ tion execution when the function is canceled, then available in addition to the calculation results of the additional function.
  • the indicator provides a measure of the Ver ⁇ trust in the corresponding calculation results.
  • the already completed processing steps in relation to the complete processing of the additional function f less trustworthy calculation results from further proces ⁇ equipment may for example be excluded or these are incorporated with a low weighting.
  • the ascertained characteristic variable which indicates the proportion of the performed function execution in the case of the aborted function, can also be used to carry out an adaptation of the additional function.
  • a lesser processing component a f for a vision function could be increased, for example, by adapting the image acquisition parameters or the processing strategy in the next task cycle.
  • the programmer of the PLC obtains the possibility of recognizing problems during the execution of the additional function during a running task cycle and to prevent discontinuations of vision functions and timeouts in the future by subsequent modifications.
  • the time monitoring function as a wrapper function can be called immediately before and immediately after the vision function to be controlled.
  • tAbstract indicates the abort time relative to the current task cycle.
  • n of the tuple indicates the number of executed functional elements of the additional function. The meaning of the functional elements will be explained in connection with FIG. 2.
  • the watchdog determined residual time At Res t is to optimize the execution of the additional function in the real-time environment.
  • the residual time At Res t can be used in particular for evaluating the execution of the additional function by software components outside the current task. For example, a PLC program which is part of a further task of the Echtzeitumge- is advertising, the residual time determined by the watchdog At Re s t abfra ⁇ gene to determine what proportion consumes available STE Henden computing time actually executing the additional function of has been. If there is unused computing ⁇ time available, this computation time can then be used dyna ⁇ mixed for other, less time-critical tasks such as exporting images of the vision function of a man-machine interface outside the real-time environment.
  • the watchdogs can be constructed in a standardized manner, which allows a simple modification and adaptation.
  • the monitoring of the time behavior ei ⁇ ner specific additional function, for example, the vision function can be adjusted without changing the additional function itself or their function parameters.
  • a possible data structure for a watchdog 200 is shown in FIG.
  • the watchdog data structure has several data fields containing watchdog parameters.
  • a first data field 210 can indicate the watchdog type.
  • Watchdog type can indicate, for example, whether a preemptive watchdog or a cooperative watchdog is used.
  • the watchdog data structure contains the termination time point t Fig ruc h - Further, a data field 230 for the number of accumulated functional elements is n, a data field
  • the accumulated machining portion can ä approximately as incremental With ⁇ average value of the processing units of all the called function ⁇ elements are determined, a f the machining portion of the current function element f and n the number of previously called functional elements indicating :
  • equation (6) provides for the calculation of the calculation proportions to optimistic values for the accumulated calculation proportion a, since the current functional element can only use the successfully calculated proportion of results of the preceding functional elements.
  • a multiplicative calculation is suitable, as indicated in equation (7) below: cif, if n
  • WatchdogType A can determine the accumulated processing fraction a with equation (6) and WatchdogTypB with equation (7).
  • the choice of to-use watchdogs can be re ⁇ alnose example, using the commands to start and stop.
  • the commands StarteWatchdogTypA and StoppeWatchdogTypA can be used to start and stop a watchdog of type A and the commands StartWatchdogTypB and StopWatchdogTypB to start and stop a watchdog of type B.
  • the time monitoring function (watchdog), at least one child timing function element, hereinafter also referred to as a subordinate watchdog exhibit ⁇ , which defines a cut-off time for an auxiliary function within the given task runtime before the termination time ⁇ point of the time monitoring function.
  • the watchdogs can form a hierarchy which allows a more precise time monitoring of the additional function.
  • Nesting causes one or more child watchdogs to be called while a watchdog is running using startup and stop commands.
  • One possible implementation may be, for example, a LIFO (last in, first out), also called a stack, as shown in FIG.
  • the stack has two watchdogs, with the higher-level watchdog being a type A watchdog and the subordinate watchdog being a type B watchdog.
  • Is to be ⁇ monitors the timing of a vision function, which includes three functional elements VisionTalkl VF1, VisionFunk- tion2 VF2 and VF3 VisionService3.
  • Fig. 3 shows in the left part of the program sequence for monitoring the vision function with the two interleaved watchdogs and parallel to the individual program steps in the right part of the respective active watchdogs in the stack.
  • the higher-level watchdog type A is started in program step 100 with the command StartWatchdogTypA.
  • the watchdog type A is an periods watchdog, the termination time according to equation (1) from the economic refreshes ⁇ time t a k ll do and the maximum allowable time period At max, which is ys, for example, 5000 is determined.
  • vision function is called and then one after the vision function elements VisionRel VF1, VF2 and VisionService2 toarbei tet ⁇ VisionService3 VF3.
  • the subordinate watchdog type B is started with the command StartWatchdogTypB.
  • the subordinate watchdog type B is formed as ⁇ derum as periods watchdog, the t a k doing the demolition ⁇ time when called from the sum of the current time ii and the maximum allowable time period At max, which ys, for example, 4000 is determined.
  • the subordinate watchdog type B monitors the operating times of the vision function elements VisionFunction2 VF2 and VisionFunction3 VF3. Thereafter, in program step 300, the subordinate watchdog type B is stopped with the command StopWatchdogTypB.
  • the superordinate watchdog type B is terminated with the command StopWatchdogTypA.
  • the active watchdogs are respectively marked for the individual program steps.
  • the command StarteWatchdogTypA the parent watchdog Type A is stored in the watchdog stack in program step 100 and remains active until the command StoppeWatch- dogTypA in program step 400.
  • the active übergeordne ⁇ th watchdog type A is in program step 200 with the command StarteWatchdogTypB in Watchdog Stack then the subordinate watchdog type B put on.
  • the subordinate watchdog type B remains active above the higher-level watchdog type A until the command StopWatchdogTypB in the program step 300.
  • Watchdog type B the timing of the vision function elements VisionSub2 VF2 and VisionService3 VF3, during the higher-level watchdog type A monitors the time behavior of the entire vision function, including the vision function element VisionFunctionl VF1 that was executed before the start of the subordinate watchdog type B.
  • each task that supports watchdogs gets its own stack.
  • the hierarchy level of a ⁇ individual watchdog is represented by the position of the watchdog on the stack. For reasons of efficiency, it is possible for the time monitoring of an additional function to always use only the highest and thus the hierarchically highest ranked watchdog in the stack of the task. In an alternative implementation, however, the termination time of all watchdogs on the stack can also be checked.
  • the processing shares of the individual watchdogs can be offset against each other.
  • the processing shares of all watchdogs on the stack can be adapted. In addition to a possible redundancy of performed
  • the billing can also be designed so that only the processing share of the highest and thus the hierarchically highest ranked watchdog is adjusted on the stack.
  • the accumulated processing proportion a and the number of accumulated function elements n of the additional function are then called upon calling the command to stop the Watchdogs propagated to the underlying and thus hierarchically deeper classified watchdog. In this way, multiple and possibly different allocations of the processing content of individual functional elements are the avoided to ⁇ set function.
  • the propagation of the accumulated processing shares can be done analogously to the calculation of the processing shares, as indicated in equations (6) and (7).
  • a hierarchically higher watchdog W2 of the accumulated machining ⁇ tung proportion of W2 is for example adjusted as follows:
  • the notation W X .Y denotes the data field Y of Watch ⁇ dog W x .
  • the equation (8) corresponds to a calculation analogous to the equation (6) and the equation (9) a calculation analogous to the equation (7).
  • the number of accumulated functional elements n can also be propagated from the watchdog Wi to the underlying hierarchical watchdog W2:
  • 4 to 6 is a possible program sequence of a time monitoring function with a watchdog stack, as
  • AtRest / err uses StoppeWatchDog ().
  • an oval represents a control point such as start and stop
  • a rectangle represents a program step
  • a rhombus is a branch step in which a decision must be made.
  • arrows represent the connections between the program and branch steps.
  • S In addition to the number of watchdog on the watchdog stack and W s for the top watchdog of the watchdog stack.
  • the watchdog W initializes its data structure shown in FIG.
  • the watchdog W which is a time spans watchdog determines the ⁇ From break time point t A bbruch from the current time t a ktueii and maximum permitted time span At max . Further, the data fields are accumulated number n of functional elements, accumulated percentage working, etc., and accumulated time remaining At Rest set to 0.
  • a first decision step SZ1 it is then determined whether watchdogs are already active in the watchdog stack.
  • the query determines that a watchdog is already active, ie
  • the watchdog W is a preemptive watchdog, it prepares an abort function in a third program step SP3.
  • an error code err 0 is set to indicate that no error has occurred during program execution.
  • an initialization takes place in a first program step VP1, in which the processing fraction a f is set to 0 and the abort time t interrupt is set to infinity.
  • VEl is then checked whether there is an active watchdog in the watchdog stack.
  • step VE2 checked whether the current time t ak tueii time ⁇ Lich before the termination time t A bbruch the topmost active Watchdogs W s is in the watchdog stack. If this is the case, in a second program step VP2 the termination time t A break is set to the termination time t A interruption of the uppermost active watchdog W s . Subsequently, the vision algorithm VA of the vision function element Visionstand is executed. At the end of each loop of the vision algorithm, the respective loop condition is checked in decision step VA1.
  • the current time t a ktueii m is continuously compared with the termination time t A break.
  • the vision algorithmic ⁇ mechanism is executed until a loop condition is he fills ⁇ or the current time talking ent ⁇ the termination date.
  • the active watchdog is a preemptive watchdog, wherein exceeding the termination timing called a termination function by the function ⁇ onsertonzeit of the vision algorithm VA to cancel the vision algorithm VA.
  • a cooperative watchdog as an active watchdog Pro ⁇ program code of the vision algorithm VA is extended by an additional condition.
  • the additional condition compares ⁇ step VA1 the current time t a ktueii w ith t demolition time ⁇ point A bbruch at the end of each processing loop in the decision. If it is determined during the review that the cut-off time on ⁇ steps, the processing loop is left and the vision algorithm VA so controlled ended.
  • a third decision step VE3 checks again whether there is an active watchdog in the watchdog stack. If this is the case, in a third program step VP3 processing share a f of the vision function ⁇ elements vision function is determined.
  • the calculation rule is predefined by the vision algorithm VA, where, for example, equations (2), (3) or (4) can be used.
  • the percentage working a f is then charged in a fourth Pro ⁇ program step VP4 with the accumulated the watchdog stack processing units, to determine the processing content for the entire vision function, for example, the equations (8) or (9) can be used , Then the program sequence of the command Visionbridge () is ended. If it is determined in the first decision step VE1 that no watchdog is active, ie
  • 0, is passed directly to the execution of the vision algorithm VA of the vision function ⁇ onselements vision function. Since no time monitoring is then carried out with a watchdog, the originally initialized termination time remains at infinity and only the loop condition is checked during execution.
  • the vision algorithm VA of the vision func ⁇ tion element Visiontransport not performed and the Pro ⁇ program sequence continues with the fourth program step VP4.
  • a first decision step EE1 it is checked whether a watchdog to be terminated is in the watchdog stack.
  • the query determines that a watchdog is active in the watchdog stack, it is checked in a second decision step EE2 whether it is a type A watchdog.
  • the watchdog W s active in the watchdog stack is such a type A watchdog, the watchdog is removed from the stack in a first program step EP 1.
  • a second program step EP2 the data structure of the watchdog W removed from the stack is then updated.
  • the processing component a is set to the value determined in the fourth program step VP4 of the program sequence of the command Visionbridge (), as has been described with reference to FIG.
  • the remaining time At Res t is with of equation (5), which determines the time difference from current time t ak tueii to abort time t Abb ruc h .
  • the abort function is then removed in a third program step EP3.
  • a third decision step EE3 it is checked whether, after removal of the watchdog W, further
  • Watchdogs are in the watchdog stack.
  • a fifth program step EP5 the number of accumulated functional elements Wn, which accumulate on profiled W.ä percentage working, and the accumulated time remaining W.At rest on the top that are available in the watchdog active stack watchdog W s is then propagated by the watchdog W.
  • an error code err 0 is set to indicate that no error has occurred during program execution.
  • Fig. 7 shows an example of the propagation of the remaining time in a watchdog stack with five watchdog 701-705, which are distributed on three hierarchical levels 1, 2, 3, wherein to ei ⁇ nem time at each level of the hierarchy most one Watch ⁇ dog active is.
  • the three hierarchy levels 1, 2, 3 are entered on the Y-axis.
  • the watchdog is 701.
  • the next hierarchical level 2 of the Watchdog 702 Watchdog 703 and the watchdog are 705 arranged ⁇ .
  • At the top hierarchy level 3 is the watchdog 704.
  • the time sequence of the five watchdogs 701 to 705 in the watchdog stack is indicated on the X-axis in FIG.
  • the numbering of the watchdogs corresponds to the start time of the watchdog respective watchdogs.
  • the arrow from the lower hierarchy level to the next higher hierarchical level always indicates the call of the watchdog.
  • the arrow from the higher hierarchical level to the next lower hierarchy level indicates the end of the watchdog.
  • the watchdog 701 located in the hierarchy level 1 starts at the time 0 ms and terminates its execution at the time 100 ms.
  • the watchdog 702, which is located in the hierarchy level 2 starts at the time 10 ms and ends its execution at the time 20 ms. Which are currently looking Dende in the hierarchy level 2 ⁇
  • Watchdog 703 starts 40ms at the time and ended his execution at the time of 70ms.
  • Watchdog 705, which is in hierarchy level 2 starts at time 80 ms and terminates its execution at the time
  • the watchdog 704 located in the hierarchy level 3 starts at the time 50 ms and ends its execution at the time 60 ms.
  • the five watchdog 701-705 are each Zeitspannen- watchdog, wherein in Fig. 7, the actual running time of the watchdog, which results from the specified start and stop newspaper th and to be monitored by the function of duration of the fed arrange ⁇ th functional elements determined becomes.
  • the watchdog 702 has a termination period of 15ms
  • the watch dog ⁇ 703 has a termination period of Iliad
  • the watchdog 704 has a termination period of 37 ms
  • the Watchdog 705 has a termination period of 18ms.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)
  • Testing And Monitoring For Control Systems (AREA)

Abstract

In einer Echtzeitumgebung wird wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt,wobei wenigstens eine Zusatzfunktion mit unbestimmter Funktionslaufzeit innerhalb der vorgegebenen Task-Laufzeit abgearbeitet werden soll. Die Abarbeitung der Funktion erfolgt, indem eine Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, gestartet und dann die Funktion ausgeführt wird. Die Zeitüberwachungsfunktion überwacht die Funktionslaufzeit, wobei bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird. Anschließend wird die Zeitüberwachungsfunktion beendet.

Description

Beschreibung
Echtzeitumgebung und speicherprogrammierbare Steuerung Die Erfindung betrifft eine Echtzeitumgebung und eine spei¬ cherprogrammierbare Steuerung.
Die Steuerung von Aktoren und Sensoren einer Produktionsanlage erfolgt in der Regel mit Hilfe einer speicherprogram- mierbare Steuerung (SPS) , welche sowohl als externes Gerät als auch als Software-SPS vorliegen kann. Die SPS steuert über eine geeignete Kommunikationsschnittstelle, wie bei¬ spielsweise einen Feldbus, die jeweiligen Aktoren und Senso¬ ren an.
Die Steuerung von Aktoren und Sensoren erfolgt auf der SPS in Form von Aufgaben, sogenannten Tasks. Die Tasks werden dabei häufig zyklisch ausgeführt. Zur schnelleren Verarbeitung kann eine SPS die Tasks auch auf mehrere Kerne eines Prozessors o- der mehrere Prozessoren verteilen. Eine zentrale Aufgabe der SPS bei der Steuerung der Aktoren und Sensoren ist die Synchronisation mit dem Produktionsprozess .
Um eine Echtzeitsteuerung zu realisieren, muss sichergestellt werden, dass die auszuführende Task innerhalb einer vorgege¬ benen Maximalzeit, beispielsweise innerhalb der für einen Zyklus zur Verfügung stehenden Zeit, abgearbeitet wird. Wei¬ terhin muss die zyklische Ausführung der Task ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) durchgeführt werden. Aus der EP 2 568 346 Bl ist bekannt, eine Task abzubrechen, wenn die Ausführungszeit der Task länger als eine vorher de¬ finierte maximale Ausführungszeit ist. Wenn die Task wegen Zeitüberschreitung nicht ausgeführt wurde, werden die Ein- gangsvariablen als Ausgangsvariablen der Task ausgegeben.
In der DE 102 43 856 B4 wird ferner einen Regler mit Funktionsblöcken beschrieben, wobei die Funktionsblöcke eine Echt¬ zeitfunktion enthalten können. Die Echtzeitfunktion wird ab- gebrochen, wenn die benötigte Rechenzeit eine vorgegebene Re¬ ferenzzeit überschreitet.
Die DE 10 2009 055 752 AI offenbart weiter ein Verfahren, bei dem eine Task zugunsten einer anderen Task unterbrochen wer- den kann.
Aus der US 7,207,045 B2 eine Überwachung der Laufzeit von Tasks mit Hilfe von Zeitfenstern, die den Tasks zugeordnet sind, bekannt.
Neben den Aktoren und Sensoren, deren Steuerung mit Hilfe der SPS erfolgt, sind bei einer Produktionsanlage in der Regel noch eine Vielzahl weiterer Systeme vorhanden, deren Funktionen mit dem Produktionsprozess und dessen Steuerung durch die SPS synchronisiert werden müssen.
So sind beispielsweise Vision-Systeme ein wesentlicher Be¬ standteil zeitgemäßer Produktionsanlagen. Sie dienen zur Objekterkennung, Oberflächeninspektion, Vermessung oder Identi- fikation. Bei Vision-Systemen müssen eine Vielzahl von Bild- verarbeitungs- und Bildanalyse-Operationen ausgeführt werden, die vorzugsweise synchron mit dem Produktionsprozess durchge¬ führt werden sollen. Eine weitere mit dem Produktionsprozess zu synchronisierende Zusatzfunktion ist die Zustandsüberwachung (Condition Monitoring) , bei der eine regelmäßige oder permanente Erfassung und Bewertung des Zustandes der Produktionsanlage durch Messung und Analyse von Maschinenparametern, die den aktuellen Zustand des Produktionsprozesses widerspiegeln, durchgeführt wird. Auch im Bereich des maschinellen Lernens ist eine Synchronisation von Zusatzfunktionen mit dem Produktionsprozess wünschenswert. Gleiches gilt für die numerische Steuerung, bei der ein Programmcode in Arbeits- bzw. Bewegungsabläufe für eine Maschine umgesetzt wird.
Vision-Systeme wie auch die anderen genannten Zusatzsysteme Zustandsüberwachung, maschinelles Lernen und numerische Steu- erung liegen in der Regel in Form eigenständiger, von der SPS getrennter Softwarekomponenten vor. Bei Vision-Systemen werden üblicherweise separate Bildverarbeitungsrechner oder intelligente Kameras eingesetzt, die mit der SPS über ein Kom¬ munikationsmedium beispielsweise über Ethernet, I/Os oder ei- nen Feldbus verbunden sind, um die Berechnungsergebnisse an die SPS zu übermitteln.
Wenn die Vision-Funktion auf einem Bildverarbeitungsrechner läuft, übermitteln die angeschlossenen Kameras die Bilder o- der Bildregionen an den Bildverarbeitungsrechner, der dann die problemspezifische Bildanalyse durchführt. Die Vision- Funktion kann aber auch direkt auf der Kamera ausgeführt werden. Die Kameras können ferner eigene I/Os besitzen, um nach entsprechender Konfiguration direkt mit den Aktoren und Sen- soren der Produktionsanlage zu kommunizieren. Es besteht dann für die Aktoren und Sensoren der Produktionsanlage die Mög¬ lichkeit, über Hardware-Trigger die Bilderfassung durch die Kameras auszulösen oder die Beleuchtung anzusteuern. Bei der Verwendung einer Software-SPS können für die Steuerung und die Bildverarbeitung dieselbe Hardware genutzt wer¬ den. Beim Einsatz einer intelligenten Kamera kann zusätzlich zur Vision-Funktion auch noch die Software-SPS auf der Kamera laufen, was jedoch die in der Regel begrenzte Rechenkapazität der intelligenten Kamera zusätzlich einschränkt. Dieser Ansatz ist folglich nur für einfache Steuerungs- und Vision- Aufgaben durchführbar.
Zur Übermittlung der Berechnungsergebnisse der Bildanalyse von der Vision-Komponente an die SPS wird üblicherweise eine Datenübertragung zwischen einer normalen Nutzerumgebung, in der die Software der Vision-Komponente läuft, und der Echt- zeitumgebung der SPS durchgeführt. Es sind dann aber aufwändige Kommunikations- und Synchronisationsschritte bei der Da¬ tenübertragung erforderlich. Ferner erfolgen die für die Bildanalyse erforderlichen Berechnungen außerhalb der Echtzeitumgebung der SPS und damit auch asynchron zum Produkti- onsprozess.
In der EP 1 312 990 A2 ist ein Datenverarbeitungsverfahren beschrieben, mit dem auf den Bewegungsablauf einer Maschine bezogene Bild- und Audiodaten mit den Daten der Bewegungs- und Antriebssteuerung der Maschine verknüpft werden können. Hierzu werden die Bild- und Audiodaten mit einem von der Be- wegungs- und Antriebssteuerung generierten Zeitstempels versehen. Die auf die Daten der Bewegungs- und Antriebssteuerung der Maschine zeitsynchronisierten Bild- und Audiodaten können dann weiterverarbeitet oder angezeigt werden. Ein wesentliches Problem bei der Synchronisation von Zusatzfunktionen, wie der der Vision-Systeme, mit dem Produktions- prozess besteht darin, dass ihre Laufzeit stark durch die Ein¬ gabedaten beeinflusst wird. Grund hierfür können bei der Bild- analyse durch die Vision-Systeme beispielsweise die Weiterver¬ arbeitung nach der Erkennung relevanter Strukturen, die iterative Anwendung eines Algorithmus in Abhängigkeit eines Kon¬ vergenzkriteriums, alternative Suchstrategien oder sogenannte Regions-of-Interest im Bild mit variabler Größe sein. Die Be- rechnungsergebnisse liegen dann zu variablen Zeitpunkten vor. Dies widerspricht jedoch der Anforderung an die SPS, eine zyk¬ lische Ausführung der Task ohne zeitliche Schwankungen (Jit- ter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) zu ge¬ währleisten, wodurch eine einfache Integration der Vision- Funktion in die Echtzeitumgebung der SPS verhindert wird.
Gleiches gilt auch bei den anderen genannten Zusatzfunktionen. Bei der Zustandsüberwachung werden oft mit Hilfe iterativer Verfahren, deren Laufzeit vom Erreichen eines Gütekriteriums abhängig ist, Zeitreihen analysiert. Auch beim maschinellen Lernen hängt die benötigte Rechenzeit beispielsweise für das Training und die Anwendung von Klassifikatoren oder Funktions- approximatoren wesentlich von den Eingabedaten ab. In der numerischen Steuerung werden komplexe iterative Optimierungsal- gorithmen eingesetzt, deren Laufzeit variiert.
Aufgabe der vorliegenden Erfindung ist es, ein Echtzeitumgebung und eine speicherprogrammierbare Steuerung bereitzustel¬ len, die eine Integration von Zusatzfunktionen mit unbestimm- ter Funktionslaufzeit in die Echtzeitumgebung ermöglichen. Diese Aufgabe wird mit einem Echtzeitsystem gemäß Anspruch 1 und mit einer speicherprogrammierbaren Steuerung gemäß Anspruch 12Q gelöst. Bevorzugte Weiterbildungen sind in den abhängigen Ansprüchen angegeben.
Erfindungsgemäß wird in der Echtzeitumgebung wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt, wobei wenigstens eine Funktion innerhalb der vorgegebenen Task- Laufzeit abgearbeitet werden soll. Die Abarbeitung der Funk- tion erfolgt, indem eine Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, gestartet und dann die Funktion aus¬ geführt wird. Die Zeitüberwachungsfunktion überwacht die Funktionslaufzeit, wobei bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird. An¬ schließend wird die Zeitüberwachungsfunktion beendet.
Durch Vorsehen der Zeitüberwachungsfunktion ist die Ausführung der Zusatzfunktion so ausgestaltet, dass die Funktions- laufzeit in Abhängigkeit der im aktuellen Zyklus der Task noch verfügbaren Rechenzeit gesteuert werden kann. Die Zusatzfunktion kann deshalb direkt in der Echtzeitumgebung der SPS ausgeführt werden. Eine Datenverarbeitung der Zusatzfunktion außerhalb der Echtzeitumgebung und die damit einherge- henden Kommunikations- und Synchronisationsschritte entfal¬ len. Weiterhin wird eine zeitgenaue Kopplung von Zusatzfunktion an das Timing des Produktionsprozesses erreicht.
In der Echtzeitumgebung ist ferner eine Abbruchsfunktion vor- gesehen, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit aufgerufen wird, um den Funktionsabbruch auszuführen. Bei einer solchen Vorgehens- weise wird die innerhalb der vorgegebenen Task-Laufzeit abzu¬ arbeitende Zusatzfunktion zeitgenau nach Überschreiten des Abbruchszeitpunktes beendet. Alternativ kann die Funktion eine Abbruchsbedingung umfassen, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit das Ausführen der Funktion ab¬ bricht und ein Bearbeitungsergebnis rückmeldet. Bei einer solchen Vorgehensweise wird ein kontrollierter Funktionsab- bruch gewährleistet. Die Ergebnisse der Zusatzfunktion beim Abbruchszeitpunkt können dann uneingeschränkt weiter verwen¬ det werden.
Die Zeitüberwachungsfunktion kann den vorgegebenen Abbruchs- Zeitpunkt beim Aufruf als Summe aus der aktuellen Zeit und einer maximal erlaubten Zeitspanne bestimmen. Der Abbruchszeitpunkt lässt sich dann dynamisch bestimmen und flexibel anpassen . Ferner kann die Zeitüberwachungsfunktion beim Beenden eine Kenngröße ausgeben, die den Anteil der erfolgten Funktionsaus¬ führung angibt. Alternativ oder zusätzlich kann die Kenngröße die Anzahl akkumulierter Funktionselemente anzeigen. Die Kenngröße stellt ein Maß für das Vertrauen in die korrespondieren- den Berechnungsergebnisse der Zusatzfunktion dar. Die Kenngröße kann auch herangezogen werden, um eine Anpassung der Zusatzfunktion durchzuführen.
Die Funktion kann eine Mehrzahl von Funktionselementen auf- weisen, wobei die beim Beenden der Zeitüberwachungsfunktion ausgegebene Kenngröße den akkumulierten Anteil der erfolgten Ausführung der Funktionselemente anzeigt. Mit dieser Vorge- hensweise besteht die Möglichkeit Funktionselemente zu bün¬ deln, um deren Laufzeit gemeinsam zu überwachen. Ferner lassen sich beispielsweise auch Schleifen, die Funktionselemente iterativ aufrufen, auf einfache Weise in die Laufzeitüberwa- chung mit einbeziehen. Die Akkumulation verrechnet dann die Kenngrößen der Laufzeitüberwachung der einzelnen Funktionselemente zu einem Gesamtergebnis über die gesamte überwachte Zeitspanne . Weiterhin kann die Zeitüberwachungsfunktion beim Beenden einen Zeitwert ausgeben, der die Zeitdifferenz zwischen der aktuellen Zeit und dem vorgegebenen Abbruchszeitpunkt anzeigt. Diese ermittelte Restzeit kann beispielsweise zur Optimierung der Ausführung der Zusatzfunktion in der Echtzeitumgebung einge- setzt werden. Weiterhin ist eine Nutzung eines Rechenzeitintervalls in der Länge der Restzeit durch andere Komponenten des Echtzeitsystems denkbar.
Die Zeitüberwachungsfunktion kann beim Beenden ferner einen Fehlercode ausgeben, der einen Fehlerzustand bei der Ausfüh¬ rung der Zeitüberwachungsfunktion wiedergibt.
Die Zeitüberwachungsfunktion kann wenigstens ein untergeordnetes Zeitüberwachungsfunktionselement aufweisen, das einen Abbruchszeitpunkt für eine zugeordnete Funktion innerhalb der vorgegebenen Task-Laufzeit vor dem Abbruchszeitpunkt der Zeitüberwachungsfunktion festlegt. Mit solchen verschachtelten Zeitüberwachungsfunktionselementen lassen sich einzelne Funktionselemente der Zusatzfunktion, also Programmcodeberei- che wie Schleifen, in Bezug auf ihre Laufzeit getrennt über¬ wachen . Die Zeitüberwachungsfunktion wird unter Verwendung eines Stacks verwaltet. Der Stack bildet eine einfache Möglichkeit, Hierarchieebenen der einzelnen Zeitüberwachungsfunktionsele- mente durch eine entsprechende Positionierung auf dem Stack auszubilden.
Eine speicherprogrammierbare Steuerung ist über einen Feldbus mit Aktoren und Sensoren einer Produktionsanlage verbunden. Die speicherprogrammierbare Steuerung umfasst dabei eine Echtzeitumgebung in der vorher erläuterten Form, deren Task zur Steuerung von Aktoren und Sensoren dient, wobei die Ausführung der Funktion durch die Zeitüberwachungsfunktion mit der Steuerung synchronisiert ist. Die speicherprogrammierbare Steuerung kann mit einer Funkti¬ onseinheit zur Bilderfassung verbunden sein, um deren Bilddaten in die Echtzeitumgebung zu übertragen, wobei die Funktion eine Vision-Funktion zur Verarbeitung und/oder Analyse der Bilddaten ist.
Die Erfindung wird anhand der beigefügten Zeichnungen näher erläutert .
Figur 1 zeigt schematisch einen Aufbau einer erfindungsgemäßen speicherprogrammierbaren Steuerung für eine Produktionsanlage, die Aktoren und Sensoren und eine Bilderfassungseinheit auf¬ weist.
Figur 2 zeigt einen Aufbau einer Datenstruktur einer Zeit- Überwachungsfunktion, die in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird. Figur 3 zeigt einen Aufbau eines Stacks mit Zeitüberwachungs¬ funktionen .
Figur 4 zeigt einen möglichen Programmablaufplan zum Start einer Zeitüberwachungsfunktion, der in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
Figur 5 zeigt einen möglichen Programmablaufplan zum Ausführen einer Vision-Funktion, die in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
Figur 6 zeigt einen möglichen Programmablaufplan zum Start einer Zeitüberwachungsfunktion, der in einer erfindungsgemäßen Echtzeitumgebung ausgeführt wird.
Figur 7 zeigt ein Beispiel für das Propagieren der Restzeit beim Ausführen mehrerer verschachtelter Zeitüberwachungsfunktionen . In einer Produktionsanlage wird zur Steuerung von Sensoren 1 und Aktoren 2 eine speicherprogrammierbare Steuerung (SPS) 3 eingesetzt, die, wie Fig. 1 zeigt, über einen Feldbus 4 mit den Sensoren 1 und Aktoren 2 verbunden ist. Die SPS kann als eigenständige Datenverarbeitungseinheit beispielsweise in Form eines Industrie-PCs 5, wie in Fig. 1 dargestellt, ausgeführt sein oder auch als Software-SPS zusätzlich auf einer bereits vorhandenen Einheit der Produktionsanlage laufen. Alternativ zu einem Feldbus 4 kann eine anders ausgestaltete Kommunika¬ tionsverbindung zum Datenaustausch zwischen den Sensoren 1 und Aktoren 2 und der SPS 3 eingesetzt werden. Die Verarbeitung der Daten von bzw. für die Sensoren 1 und Aktoren 2 erfolgt auf der SPS 3 in Form von Aufgaben, sogenannten Tasks. Die Tasks werden zur Steuerung der Sensoren 1 und Aktoren 2 in der Regel zyklisch ausgeführt, wobei sicher- gestellt werden muss, dass die Tasks garantiert innerhalb ei¬ ner vorgegebenen Maximalzeit, beispielsweise innerhalb der für einen Zyklus zur Verfügung stehenden Zeit, abgearbeitet werden. Weiterhin muss die zyklische Ausführung der Tasks ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Ant- wortzeit (Latenzzeit) gewährleistet werden. Diese Anforderun¬ gen an die SPS 3 werden durch eine Echtzeitumgebung implementiert .
Neben den Aktoren 2 und Sensoren 1 weisen Produktionsanlagen in der Regel noch eine Vielzahl weiterer Systeme auf, deren Funktionen mit dem Produktionsprozess und dessen Steuerung mit der Hilfe der Sensoren 1 und Aktoren 2 durch die SPS 3 synchronisiert werden müssen. Vision-Systeme stellen ein sol¬ ches Zusatzsystem dar. Mit Vision-Systemen kann beispiels- weise eine Objekterkennung, eine Oberflächeninspektion, eine Vermessung oder eine Identifikation durchgeführt werden. Um diese Aufgaben zu lösen, müssen die Vision-Systeme eine Viel¬ zahl von Bildverarbeitungs- und Bildanalyse-Operationen ausführen. Solche Bildverarbeitungs- und Bildanalyse-Operationen können beispielsweise Filter, Schwellwerte, morphologische
Operatoren, geometrische Transformationen, Farbraumtransformationen, Segmentierungsverfahren, Konturensuche sowie Methoden zur Textur- und Formanalyse umfassen. Erfindungsgemäß ist die SPS 3, wie Fig. 1 zeigt, dahingehend erweitert, dass Bilddaten einer Funktionseinheit 6 zur Bil¬ derfassung beispielsweise einer Kamera des Vision-Systems di- rekt in einen Speicherraum der SPS 3 gelangen. Die Funktionseinheit 6 zur Bilderfassung wird im Folgenden auch als Bilderfassungseinheit 6 bezeichnet. In der in Fig. 1 gezeigten beispielhaften Implementierung, welche Ethernet 7 als Kommu- nikationsmedium zwischen der Bilderfassungseinheit 6 und der SPS 3 nutzt, werden Ethernet-Pakete der Bilderfassungseinheit 6 direkt von einem Netzwerkadapter in die Echtzeitumgebung der SPS 3 übertragen. In der Echtzeitumgebung der SPS 3 erfolgt eine protokollspezifische Bearbeitung der Ethernet-Pa- kete, um die Bilddaten dann in der Echtzeitumgebung mit Hilfe von Vision-Funktionen zu verarbeiten und zu analysieren.
Statt dem Einsatz von Ethernet 7 zur Bilddatenübertragung können auch andere Datenbussystem eingesetzt werden. Bei den Vision-Funktionen hängen die Funktionslaufzeiten wesentlich von der vorliegenden Datenmenge ab. So kann die Verarbeitungszeit beim Erkennen relevanter Strukturen im Rahmen einer topologischen Strukturanalyse beispielsweise einer Kon¬ turensuche stark variieren. Auch die iterative Anwendung ei- nes Algorithmus in Abhängigkeit eines Konvergenzkriteriums beispielsweise ein iteratives Filter oder eine Subpixelopti- mierung kann zu einer schwankenden Funktionslaufzeit führen. Gleiches gilt für die Verwendung alternativer Suchstrategien beispielsweise, dass, wenn ein erster Teilalgorithmus nicht erfolgreich ist, ein zweiter Teilalgorithmus versucht wird. Auch eine sogenannte Region-of-Interest mit variabler Größe führt zu unterschiedlichen Funktionslaufzeiten. Folglich liegen die Ergebnisse der jeweiligen Funktionsoperationen zu variablen Zeitpunkten vor. Dies widerspricht jedoch der Anfor- derung an die Echtzeitumgebung der SPS 3, die die zyklische Ausführung der Task ohne zeitliche Schwankungen (Jitter) mit einer vorhersehbaren Antwortzeit (Latenzzeit) gewährleisten muss . Auch einer Integration anderer Zusatzfunktionen, die mit dem Produktionsprozess und dessen Steuerung durch die SPS 3 syn¬ chronisiert werden sollen, in die Echtzeitumgebung der SPS 3, steht die unbekannte Funktionslaufzeit entgegen. Eine solche Zusatzfunktion ist beispielsweise die Zustandsüberwachung (Condition Monitoring) , bei der eine regelmäßige oder permanente Erfassung und Bewertung des Zustandes der Produktions¬ anlage durch Messung und Analyse von Maschinenparametern, die den aktuellen Zustand des Produktionsprozesses widerspiegeln, durchgeführt wird. Bei der Zustandsüberwachung werden oft iterative Verfahren zur Analyse der erfassten Daten eingesetzt, wobei die Laufzeit vom Erreichen eines Gütekriteriums abhängig und damit nicht von vornherein festgelegt ist. Auch im Bereich des maschinellen Lernens und der numerischen Steuerung und weiteren mit dem Produktionsprozess zu synchronisierende Zu- satzfunktionen, variiert die Funktionslaufzeit.
Um eine Zusatzfunktion mit unbestimmter Funktionslaufzeit in eine Echtzeitumgebung, in der wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt wird, integrieren zu können, ist erfindungsgemäß eine Zeitüberwachungsfunktion, die einen Abbruchszeitpunkt für die Funktion innerhalb der vorgegebenen Task-Laufzeit festlegt, vorgesehen. Wenn eine Funktion innerhalb der vorgegebenen Task-Laufzeit abgearbei¬ tet werden soll, wird die Zeitüberwachungsfunktion gestartet. Die Zeitüberwachungsfunktion überwacht dann die Funktionslaufzeit, wobei bei Überschreiten des vorgegebenen Abbruchs¬ zeitpunktes einen Funktionsabbruch veranlasst wird.
Durch Vorsehen der Zeitüberwachungsfunktion ist die Ausführung der Zusatzfunktion so ausgestaltet, dass die Funktions¬ laufzeit in Abhängigkeit der im aktuellen Zyklus der Task noch verfügbaren Rechenzeit gesteuert werden kann. Die Zusatzfunktion kann direkt in der Echtzeitumgebung der SPS 3 ausgeführt werden, da mit Hilfe der Zeitüberwachungsfunktion die zyklische Ausführung der Task mit einer vorhersehbaren Antwortzeit garantiert werden kann. Weiterhin wird eine zeit¬ genaue Kopplung der von der Zusatzfunktion ausgeführten Algorithmen an das Timing des Produktionsprozesses erreicht.
Im Weiteren wird die Erfindung am Beispiel der Vision-Funk- tion erläutert. Die Ausführungen lassen sich aber auch auf andere Zusatzfunktionen, insbesondere die vorstehend genann¬ ten weiteren Zusatzfunktionen, übertragen.
Die Zeitüberwachungsfunktion, im Weiteren auch als Watchdog bezeichnet, kann als Wrapper-Funktion ausgebildet sein, die die Zusatzfunktion umhüllt. Die Zeitüberwachungsfunktion ist dabei als Programmcode ausgeführt, welcher die Funktionssoft¬ ware umgibt. Mit der Ausbildung der Zeitüberwachungsfunktion als Wrapper besteht die Möglichkeit, die Software der Zusatz- funktion auf einfache Weise zu erweitern, ohne umfangreich in den Programmcode der Zusatzfunktion eingreifen zu müssen. Der Programmcode der Zusatzfunktion läuft dann innerhalb des Pro¬ grammcodes der Zeitüberwachungsfunktion. Der Watchdog kann sowohl präemptiv als auch kooperativ realisiert werden. Bei einem präemptiven Watchdog wird die innerhalb der vorgegebenen Task-Laufzeit abzuarbeitende Zusatz¬ funktion zeitgenau nach Überschreiten des Abbruchszeitpunktes beendet. Der Watchdog sorgt dabei für eine fortlaufende Über- wachung der Funktionslaufzeit. Bei Überschreiten des vorgege¬ benen Abbruchszeitpunktes durch die Funktionslaufzeit wird eine Abbruchsfunktion aufgerufen, um den Funktionsabbruch auszuführen. Hierzu kann außerhalb des Watchdogs und der je¬ weiligen Zusatzfunktion ein Unterbrechungsprogramm eingerichtet sein, das zum Abbruchszeitpunkt ausgeführt wird. Alterna¬ tiv kann die Abbruchsfunktion auch Teil des Watchdogs sein, in die der Watchdog-Programmcode abzweigt, wenn die Abbruch¬ bedingung durch Überschreiten des vorgegebenen Abbruchszeitpunktes erfüllt ist.
Der Abbruch der Ausführung der Zusatzfunktion kann beispiels- weise über Interrupts erfolgen. Beim präemptiven Watchdog wird beim Starten beispielsweise ein Timer gestartet, der beim Ablauf den Interrupt auslöst, der die zu überwachende Zusatzfunktion abbricht. Beim präemptiven Watchdog erfolgt der Abbruch der Zusatzfunktion in der Regel an einer unbe- kannten Programmposition innerhalb der Zusatzfunktion, so dass die Zusatzfunktion sich in einem Undefinierten Zustand befinden kann, wodurch die Ergebnisse der Zusatzfunktion zum Abbruchszeitpunkt oft nur eingeschränkt verwendbar sind. Im Gegensatz zum präemptiven Watchdog ermöglicht der koopera¬ tive Watchdog einen kontrollierten Funktionsabbruch. Dazu wird vorzugsweise der Programmcode der Zusatzfunktion erwei¬ tert, indem eine Zusatzbedingung beispielsweise an funktions¬ spezifisch zentrale Bearbeitungsschleifen eingefügt wird. Die Zusatzbedingung überprüft die für den Algorithmus der Zusatzfunktion verbrauchte Rechenzeit zu festgelegten Zeitpunkten, beispielsweise am Ende der zugeordneten Bearbeitungsschleife. Wird bei der Überprüfung festgestellt, dass die Funktions¬ laufzeit den Abbruchszeitpunkt überschritten hat, wird die zugeordnete Bearbeitungsschleife der Zusatzfunktion verlas¬ sen . Bereits vorliegende Ergebnisse der Zusatzfunktion können ge¬ nutzt werden, da die Zusatzfunktion kontrolliert durch Herauszweigen am Ende einer Bearbeitungsschleife abgebrochen wird. Der Abbruch der Zusatzfunktion beim kooperativen Watch- dog ist im Vergleich zum präemptiven Watchdog aber in der Regel weniger zeitgenau, da nur zu durch die Zusatzfunktion festgelegten Zeitpunkten abgebrochen wird.
Die Zeitüberwachungsfunktion kann den vorgegebenen Abbruchs- Zeitpunkt tAbbruch beim Aufruf als Summe aus der aktuellen Zeit taktueii und einer maximal erlaubten Zeitspanne Atmax bestimmen. Die aktuelle Zeit taktueii kann dabei auf den Beginn des lau¬ fenden Taskzyklus bezogen werden: ^-Abbruch ^-aktuell ^tmax (1 )
Watchdogs, die ihre Abbruchszeit entsprechend der Gleichung (1) dynamisch bestimmen, werden im Weiteren auch als Zeit- spannen-Watchdogs bezeichnet.
Die Zeitüberwachungsfunktion kann ferner beim Beenden eine Kenngröße ausgeben, der den Anteil der erfolgten Funktionsaus¬ führung anzeigt. Als Kenngröße kann dabei ein numerischer Wert von der Zeitüberwachungsfunktion verwendet werden, der den An- teil af der bereits erfolgten Bearbeitungsschritte im Verhält¬ nis zur vollständigen Bearbeitung einer Zusatzfunktion f widerspiegelt. Die Berechnung der Kenngröße hängt vom Algorith¬ mus der Zusatzfunktion f ab. Beispielhafte Varianten zur Berechnung des Anteils af für eine Vision-Funktion als Zusatzfunktion sind aktueller Anteil der verarbeiteten ROI
Gesamtgröße der verarbeiteten ROI gewünschte Genauigkeit
max(gewünschte Genauigkeit, aktuelle Genauigkeit)
Anzahl ausgeführter Teilalgorithmen
Anzahl möglicher Teilalgorithmen
Die Gleichung (2) ist dabei für Algorithmen geeignet, die alle Bildpunkte einer Region-of-Interest (ROI) sequenziell verarbeiten, wobei die ROI auch das gesamte Bild umfassen kann. Die verwendeten Algorithmen können beispielsweise einfache Faltungsfilter oder Schwellwertoperatoren sein. Auch für komplexere Algorithmen wie Labelling oder Konturensuche ist die Gleichung (2) zur Berechnung des Anteils af geeignet. Das Anwendungsgebiet von Gleichung (3) sind vor allem itera¬ tive Algorithmen, bei denen solange weitere Iterationen durchgeführt werden, bis eine gewünschte Genauigkeit erreicht ist. Die Genauigkeit kann hierbei beispielsweise durch den absoluten Betrag der Veränderung einer oder mehrerer zu opti- mierender Größen zwischen zwei aufeinanderfolgenden Iterationen des Algorithmus angegeben werden.
Die Gleichung (4) ist für komplexe Algorithmen geeignet, die alternative Verarbeitungsstrategien in Abhängigkeit der Er- gebnisse durchführen. Beispielsweise kann ein Algorithmus zur Kennzeichenerkennung erst versuchen Datamatrix-Codes zu ermitteln und, falls dies fehlschlägt, dann eine weitere Suche nach QR-Codes und anschließend gegebenenfalls nach eindimen¬ sionalen Barcodes durchführen. Auch Kombinationen der vorstehenden Gleichungen zur Ermittlung des Anteils af für eine Vision-Funktion sind denkbar. Die ermittelte Kenngröße, die den Anteil der erfolgten Funk¬ tionsausführung beim Funktionsabbruch angibt, steht dann zu- sätzlich zu den Berechnungsergebnissen der Zusatzfunktion zur Verfügung. Die Kenngröße stellt dabei ein Maß für das Ver¬ trauen in die korrespondierenden Berechnungsergebnisse dar. Anhand des jeweiligen Anteil af der bereits erfolgten Bearbeitungsschritte im Verhältnis zur vollständigen Verarbeitung der Zusatzfunktion f können beispielsweise weniger vertrauenswürdige Berechnungsergebnisse von der weiteren Verarbei¬ tung ausgeschlossen werden oder in diese mit einer geringen Gewichtung einfließen. Alternativ kann die ermittelte Kenngröße, die den Anteil der erfolgten Funktionsausführung beim Funktionsabbruch angibt, auch herangezogen werden, um eine Anpassung der Zusatzfunktion durchzuführen. Ein geringerer Bearbeitungsanteil af bei einer Vision-Funktion könnte beispielweise durch eine Anpas- sung der Bildaufnahmeparameter oder der Bearbeitungsstrategie im nächsten Taskzyklus erhöht werden. Der Programmierer der SPS erhält durch die Ausgabe der Kenngröße, die Möglichkeit schon während eines laufenden Taskzyklus Probleme bei der Ausführung der Zusatzfunktion zu erkennen und durch eine an- schließende Modifikationen Abbrüche von Vision-Funktionen und Zeitüberschreitung in der Zukunft zu verhindern.
Die Zeitüberwachungsfunktion als Wrapper-Funktion kann unmittelbar vor der zu steuernden Vision-Funktion und unmittelbar danach aufgerufen werden. Eine mögliche Befehlsstruktur ist: err = StarteWatchdog ( tAbbruch )
VisionFunktion (); (n, a, AtRest/ err) = StoppeWatchDog ( ) tAbbruch gibt dabei den Abbruchszeitpunkt relativ zum aktuellen Taskzyklus an. err bezeichnet einen Fehlercode, dessen Werte dazu dienen, Fehlerzustände bei der Ausführung der Zeitüberwachungsfunktion anzuzeigen. In einer möglichen Implementierung kann err = 0 bedeuten, dass kein Fehler bei der Ausführung der Zeitüberwachungsfunktion aufgetreten ist, wohingegen err + 0 einen Fehler signalisiert.
Das Element n des Tupels (n, a, AtRest, err) gibt die Anzahl der ausgeführten Funktionselemente der Zusatzfunktion an. Die Bedeutung der Funktionselemente wird in Zusammenhang mit Fig. 2 noch erläutert werden.
Ferner ist im Tupel (n, a, AtRest, err) weiter neben dem Bear¬ beitungsanteil a (in Prozent) die Zeitdifferenz AtRest von ak¬ tueller Zeit taktueii zu Abbruchszeitpunkt tAbbruch:
AtRest = tAbbruch— taktueu (5)
Wird eine Zusatzfunktion, im Beispiel die Vision-Funktion, vorzeitig abgebrochen, sind 0% ^ af < 100% und AtRest - 0.
Wenn eine Zusatzfunktion vollständig ausgeführt, also vor Er- reichen des Abbruchszeitpunktes tAbbruch beendet wird, sind af = 100% und AtRest > 0.
Neben der Kenngröße af, die den Anteil der erfolgten Funkti¬ onsausführung beim Funktionsabbruch angibt, eignet sich die vom Watchdog ermittelte Restzeit AtRest zur Optimierung der Ausführung der Zusatzfunktion in der Echt zeitumgebung . Die Restzeit AtRest kann insbesondere zur Bewertung der Ausführung der Zusatzfunktion durch Softwarekomponenten außerhalb der aktuellen Task eingesetzt werden. Beispielsweise kann ein SPS-Programm, das Teil einer weiteren Task der Echtzeitumge- bung ist, die vom Watchdog ermittelte Restzeit AtRe st abfra¬ gen, um festzustellen, welcher Anteil der zur Verfügung ste- henden Rechenzeit tatsächlich durch die Ausführung der Zusatzfunktion verbraucht wurde. Falls noch ungenutzte Rechen¬ zeit zur Verfügung steht, kann dann diese Rechenzeit dyna¬ misch für andere, weniger zeitkritische Aufgaben eingesetzt werden, beispielsweise den Export von Bildern der Vision- Funktion an eine Mensch-Maschine-Schnittstelle außerhalb der Echtzeitumgebung .
Durch die Implementierung des Watchdogs als die Zusatzfunktion ergänzendes Funktionselement beispielsweise in Form ei- ner Wrapper-Befehlsstruktur können die Watchdogs standardisiert aufgebaut werden, was eine einfache Modifikation und Anpassung ermöglicht. Die Überwachung des Zeitverhaltens ei¬ ner spezifischen Zusatzfunktion beispielsweise der Vision- Funktion kann so ohne Veränderung der Zusatzfunktion selbst bzw. deren Funktionsparameter angepasst werden.
Eine mögliche Datenstruktur für einen Watchdog 200 ist in Fig. 2 dargestellt. Die Watchdog-Datenstruktur weist mehreren Datenfeldern auf, die Watchdog-Parameter enthalten. Ein ers- tes Datenfeld 210 kann dabei den Watchdog-Typ anzeigen. Der
Watchdog-Typ kann beispielsweise anzeigen, ob ein präemptiver Watchdog oder ein kooperativer Watchdog eingesetzt wird. Als weiteres Datenfeld 220 enthält die Watchdog-Datenstruktur den Abbruchzeitpunkt tAbbruch - Ferner ist ein Datenfeld 230 für die Anzahl der akkumulierten Funktionselemente n, ein Datenfeld
240 für den akkumulierten Bearbeitungsanteil ä und ein Datenfeld 250 für die akkumulierte Restzeit AtRest vorgesehen. Mit der in Fig. 2 gezeigten Watchdog-Datenstruktur lässt sich eine Überwachung größerer Programmcodebereiche einschließlich Schleifen und Verzweigungen, im Weiteren als Funktionselemente bezeichnet, bei einer Zusatzfunktion realisieren. Dabei ist es vorteilhaft, zu Beginn der Ausführung jedes Funktions¬ elements der Zusatzfunktion zu überprüfen, ob der Abbruchzeitpunkt tAbbruch überschritten wurde. Wenn dies der Fall ist, unterbleibt dann die Bearbeitung weiterer Funktionselemente. Funktionselemente, die keine partielle Bearbeitung unterstüt¬ zen, gehen entweder mit Bearbeitungsanteil af = 0% oder af = 100% in die Berechnung ein.
Falls die Ergebnisse der überwachten Zusatzfunktionselemente weitgehend unabhängig voneinander sind, kann der akkumulierte Bearbeitungsanteil ä näherungsweise als inkrementeller Mit¬ telwert der Bearbeitungsanteile aller aufgerufenen Funktions¬ elemente ermittelt werden, wobei af den Bearbeitungsanteil des aktuellen Funktionselements f und n die Anzahl der vorher aufgerufenen Funktionselemente angibt:
Falls die Berechnungsergebnisse der Funktionselemente der überwachten Zusatzfunktion dagegen aufeinander aufbauen, liefert die Gleichung (6) zur der Verrechnung der Berechnungsanteile zu optimistische Werte für den akkumulierten Berechnungsanteil ä, da das aktuelle Funktionselement nur auf den erfolgreich berechneten Anteil an Resultaten der vorhergehenden Funktionselemente zurückgreifen kann. In diesem Fall ist eine multiplikative Verrechnung geeignet, wie sie in der nachstehenden Gleichung (7) angeben ist: cif , falls n
α (n + 1) = [ (7)
ä(n) ■ üf , sonst
Alternativ zu den Gleichungen (6) und (7) sind auch andere Berechnungsarten zur Bestimmung des akkumulierten Bearbei- tungsanteils ä denkbar. Welche Berechnungsart im jeweiligen Fall verwendet werden soll, kann durch die Auswahl eines zu¬ geordneten Watchdog-Typs entschieden werden. WatchdogTypA kann beispielsweise den akkumulierten Bearbeitungsanteil ä mit der Gleichung (6) und WatchdogTypB mit der Gleichung (7) ermitteln. Die Wahl des zu nutzenden Watchdogs kann beispielsweise mit Hilfe der Befehle zum Starten und Stoppen re¬ alisiert werden. So können die Befehle StarteWatchdogTypA und StoppeWatchdogTypA zum Starten und Stoppen eines Watchdogs vom Typ A und die Befehle StarteWatchdogTypB und StoppeWatch- dogTypB zum Starten und Stoppen eines Watchdogs vom Typ B verwendet werden.
Ferner kann die Zeitüberwachungsfunktion (Watchdog) wenigstens ein untergeordnetes Zeitüberwachungsfunktionselement , im Weiteren auch als untergeordneter Watchdog bezeichnet, auf¬ weisen, das einen Abbruchzeitpunkt für ein Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit vor dem Abbruchzeit¬ punkt der Zeitüberwachungsfunktion festlegt. Durch eine solche Verschachtelung können die Watchdogs eine Hierarchie aus- bilden, die eine genauere Zeitüberwachung der Zusatzfunktion ermöglicht .
Bei einer Verschachtelung werden während der Ausführung eines Watchdogs mit Hilfe der Befehle zum Starten und Stoppen ein oder mehrere untergeordnete Watchdogs aufgerufen. Die Anzahl bereits ausgeführter Befehle zum Starten von Watchdogs, für die noch kein entsprechender Befehl zum Stoppen des gestarteten Watchdogs erfolgt ist, gibt die Hierarchieebene des je¬ weiligen Watchdogs an. Eine mögliche Implementierung kann beispielsweise ein LIFO (last in, first out) , auch Stack genannt, sein, wie er in Fig. 3 dargestellt ist.
Im Beispiel in Fig. 3 weist der Stack zwei Watchdogs auf, wo- bei der übergeordnete Watchdog ein Watchdog vom Typ A ist und der untergeordnete Watchdog ein Watchdog vom Typ B ist. Über¬ wacht werden soll das Zeitverhalten einer Vision-Funktion, die drei Funktionselemente VisionFunktionl VF1, VisionFunk- tion2 VF2 und VisionFunktion3 VF3 umfasst. Fig. 3 zeigt im linken Teil den Programmablauf zur Überwachung der Vision- Funktion mit den beiden verschachtelten Watchdogs und parallel zu den einzelnen Programmschritten im rechten Teil die jeweils aktiven Watchdogs im Stack. Nach dem Programmstart wird im Programmschritt 100 mit dem Befehl StarteWatchdogTypA der übergeordnete Watchdog Typ A gestartet. Der Watchdog Typ A ist ein Zeitspannen-Watchdog, der die Abbruchszeit entsprechend Gleichung (1) aus der aktu¬ ellen Zeit t aktuell und der maximal erlaubten Zeitspanne Atmax, , die beispielsweise 5000 ys ist, bestimmt. Nach dem Start des Watchdogs Typ A wird die Vision-Funktion aufgerufen und dann nacheinander die Vision-Funktionselemente VisionFunktionl VF1, VisionFunktion2 VF2 und VisionFunktion3 VF3 abgearbei¬ tet .
Zwischen den Vision-Funktionselementen VisionFunktionl VF1 und VisionFunktion2 VF2 wird weiter im Programmschritt 200 der untergeordnete Watchdog Typ B mit dem Befehl StarteWatch- dogTypB gestartet. Der untergeordnete Watchdog Typ B ist wie¬ derum als Zeitspannen-Watchdog ausgebildet, der die Abbruch¬ zeit beim Aufruf aus der Summe der aktuellen Zeit taktueii und der maximal erlaubten Zeitspanne Atmax, , die beispielweise 4000 ys ist, bestimmt. Der untergeordnete Watchdog Typ B dient zur Überwachung der Funktionslaufzeiten der Vision- Funktionselemente VisionFunktion2 VF2 und VisionFunktion3 VF3. Danach wird im Programmschritt 300 der untergeordnete Watchdog Typ B mit dem Befehl StoppeWatchdogTypB angehalten. Anschließend wird dann im Programmschritt 400 mit dem Befehl StoppeWatchdogTypA auch der übergeordnete Watchdog Typ B beendet . Im in Fig. 3 weiter gezeigten Watchdog-Stack sind zu den einzelnen Programmschritten jeweils die aktiven Watchdogs angezeichnet. Mit dem Befehl StarteWatchdogTypA wird im Programmschritt 100 der übergeordnete Watchdog Typ A im Watchdog- Stack abgelegt und bleibt aktiv bis zum Befehl StoppeWatch- dogTypA im Programmschritt 400. Auf den aktiven übergeordne¬ ten Watchdog Typ A wird im Programmschritt 200 mit dem Befehl StarteWatchdogTypB im Watchdog-Stack dann der untergeordnete Watchdog Typ B aufgesetzt. Der untergeordnete Watchdog Typ B bleibt über dem übergeordneten Watchdog Typ A aktiv liegen bis zum Befehl StoppeWatchdogTypB im Programmschritt 300.
Mit dem Watchdog-Stack und den darin enthaltenen verschachtelten Watchdogs lassen sich einzelne Funktionselemente der Zusatzfunktion, also Programmcodebereiche wie Schleifen, in Bezug auf ihre Laufzeit getrennt überwachen. Bei dem in Fig. 3 gezeigten Programmablauf überwacht der untergeordnete
Watchdog Typ B das Zeitverhalten der Vision-Funktionselemente VisionFunktion2 VF2 und VisionFunktion3 VF3, während der übergeordnete Watchdog Typ A das Zeitverhalten der gesamten Vision-Funktion einschließlich des vor Start des untergeordneten Watchdogs Typ B ausgeführten Vision-Funktionselements VisionFunktionl VF1 überwacht.
In der Echtzeitumgebung erhält jede Task, die Watchdogs unterstützt, einen eigenen Stack. Die Hierarchieebene der ein¬ zelnen Watchdogs wird durch die Position des Watchdogs auf dem Stack repräsentiert. Aus Effizienzgründen besteht dabei die Möglichkeit für die Zeitüberwachung einer Zusatzfunktion immer nur den obersten und damit den hierarchisch am höchsten eingestuften Watchdog im Stack der Task heranzuziehen. In einer alternativen Implementierung kann aber auch der Abbruchzeitpunkt aller Watchdogs auf dem Stack überprüft werden.
Bei der Verschachtelung von Watchdogs können die Bearbeitungsanteile der einzelnen Watchdogs miteinander verrechnet werden. In einer möglichen Implementierung können dabei die Bearbeitungsanteile aller Watchdogs auf dem Stack angepasst werden. Neben einer möglichen Redundanz von durchgeführten
Berechnungen kann eine solche Implementierung aber bei unterschiedlichen Verrechnungsvorschriften für den akkumulierten Bearbeitungsanteil der verschiedenen Watchdogs, wie sie bei¬ spielsweise in den Gleichungen (6) und (7) angegeben sind, zu inkonsistenten Ergebnissen führen.
Alternativ kann die Verrechnung auch so ausgestaltet sein, dass nur der Bearbeitungsanteil des obersten und damit des hierarchisch am höchsten eingestuften Watchdogs auf dem Stack anpasst wird. Der akkumulierte Bearbeitungsanteil ä und die Anzahl der akkumulierten Funktionselemente n der Zusatzfunktion werden dann beim Aufruf des Befehls zum Stoppen des Watchdogs zum darunter liegenden und damit hierarchisch tiefer eingestuften Watchdog propagiert. Auf diese Weise werden mehrfache und gegebenenfalls unterschiedliche Verrechnungen des Bearbeitungsanteils einzelner Funktionselemente der Zu¬ satzfunktion vermieden.
Die Propagierung der akkumulierten Bearbeitungsanteile kann analog zu der Verrechnung der Bearbeitungsanteile, wie sie in den Gleichungen (6) und (7) angegeben ist, erfolgen. Bei der Propagierung der akkumulierten Bearbeitungsanteile von einem Watchdog Wi zu einem darüber liegenden und damit einem hierarchisch höheren Watchdog W2 wird der akkumulierte Bearbei¬ tungsanteil von W2 beispielsweise wie folgt angepasst:
W . ä , falls W2. n = 0
w2.n-W2.ä+ W.n-W.ä (8)
— — , sonst
W2.n+W1.n oder
( W1. a , falls W2. n = 0
W2. ä = ]„, *„, - R (9)
2 {W2. a(n)■ W1. a(n) , sonst
Die Notation WX.Y bezeichnet dabei das Datenfeld Y von Watch¬ dog Wx. Die Gleichung (8) entspricht einer Verrechnung analog zur Gleichung (6) und die Gleichung (9) einer Verrechnung analog zur Gleichung (7) .
Zusätzlich zur Propagierung der Bearbeitungsanteile kann auch die Anzahl der akkumulierten Funktionselemente n von dem Watchdog Wi zu dem darunter liegenden und damit hierarchisch tieferen Watchdog W2 propagiert werden:
W2. n = W2. n + W1. n (10 ) Neben der Überwachung des Zeitverhaltens von Zusatzfunktionen eignen sich die Watchdogs, wie erläutert, auch zur Optimie¬ rung der SPS. Dies gilt insbesondere für die vom Watchdog zu- sätzlich ermittelte akkumulierte Restzeit AtRest , die in der Watchdog-Datenstruktur, die in Fig. 2 gezeigt ist, in einem Datenfeld gespeichert ist und von extern abgefragt werden kann . In der akkumulierten Restzeit AtRest kann dabei die ungenutzte Rechenzeit der Watchdogs der verschiedenen Hierarchieebenen in einem Stack gesammelt werden. Beim Aufruf des Befehls zum Stoppen des Watchdogs Wi kann die Restzeit AtRest, die sich als W1.AtRest = tRest ergibt, an den Watchdog W2 der darunter lie- genden Hierarchieebene propagiert werden. Die Propagierung der Restzeit von dem Watchdog Wi zu dem Watchdog W2 kann da¬ bei folgendermaßen durchgeführt werden:
W2.AtRest = W1.AtRest (11)
Für Zeitspannen-Watchdogs , die den Abbruchszeitpunkt beim Aufruf als Summe aus der aktuellen Zeit und einer maximal er¬ laubten Zeitspanne bestimmen, ist diese Art der Berechnung jedoch nicht ausreichend, da eine Zeitersparnis bei einem vorher ausgeführten Watchdog automatisch in die Berechnung der Abbruchzeitpunkte tAbbruch der folgenden Zeitspannen-Watch¬ dogs einfließt, wie sich aus der vorstehenden Gleichung (1) ergibt. Die Restzeit vorhergehender Watchdogs muss bei Zeit¬ spannen-Watchdogs deshalb explizit gesammelt werden. Dafür kann die folgende Vorschrift zur Propagierung von dem Zeit- spannen-Watchdog Wi zu dem Watchdog W2 genutzt werden:
W2.AtRest = W2.AtRest + Wi.d (12) Die Summe der akkumulierten Restzeit ΔΐΚβ5ί aller Watchdogs auf dem Stack gibt in beiden Varianten die ungenutzte Rechenzeit an und kann dann von Softwarekomponenten anderer Tasks aus der Watchdog-Datenstruktur ausgelesen und weiterverarbeitet werden, um das Verhalten der Echtzeitumgebung der SPS zu optimieren .
In den Fig. 4 bis 6 ist ein möglicher Programmablauf einer Zeitüberwachungsfunktion mit einem Watchdog-Stack, die als
Wrapper-Funktion für eine Vision-Funktion ausgeführt ist und die die bereits erläuterte Befehlsstruktur mit den Befehlen err = StarteWatchdog ( tAbbruch) ; VisionFunktion (); (n, a,
AtRest/ err) = StoppeWatchDog ( ) nutzt, gezeigt. Im Programmab- lauf stellt ein Oval einen Kontrollpunkt wie Start und Stopp dar, ein Rechteck gibt einen Programmschritt wieder und eine Raute ist ein Verzweigungsschritt, bei dem eine Entscheidung getroffen werden muss. Ferner geben Pfeile die Verbindungen zwischen den Programm- und Verzweigungsschritten wieder. In den Fig. 4 bis 6 steht |S| außerdem für die Anzahl der Watchdogs auf dem Watchdog-Stack und Ws für den obersten Watchdog auf dem Watchdog-Stack.
Fig. 4 zeigt beispielhaft für den Befehl err = StarteWatch- dogTypA (tAbbruch) den Programmablauf, wobei ein Watchdog W vom Watchdog Typ A im Rahmen eines Watchdog-Stacks gestartet wer¬ den soll.
In einem ersten Programmschritt SP1 initialisiert der Watch- dog W seine in Fig. 2 gezeigte Datenstruktur. Der Watchdog W, der ein Zeitspannen-Watchdog ist, bestimmt dabei den Ab¬ bruchszeitpunkt tAbbruch aus der aktuellen Zeit taktueii und der maximal erlaubten Zeitspanne Atmax. Ferner werden die Datenfelder Anzahl akkumulierter Funktionselemente n, akkumulierter Bearbeitungsanteil ä und akkumulierte Restzeit AtRest auf 0 gesetzt .
In einem ersten Entscheidungsschritt SZ1 wird dann ermittelt, ob im Watchdog-Stack bereits Watchdogs aktiv sind.
Wenn bei der Abfrage festgestellt wird, dass bereits ein Watchdog aktiv ist, also |S| > 0 ist, wird in einem zweiten Entscheidungsschritt SZ2 geprüft, ob im Vergleich zur Ab¬ bruchzeit des obersten Watchdogs Ws im Watchdog-Stack die Ab¬ bruchzeit des Watchdogs W kleiner oder gleich ist. Wenn dies zutrifft, legt sich der Watchdog W in einem zweiten Programmschritt SP2 oben auf den Watchdog-Stack.
Optional bereitet der Watchdog W dann, wenn es sich um einen präemptiven Watchdog handelt, in einem dritten Programm- schritt SP3 eine Abbruchfunktion vor.
Anschließend wird in einem vierten Programmschritt SP4 ein Fehlercode err = 0 gesetzt, um anzuzeigen, dass kein Fehler bei der Programmausführung aufgetreten ist.
Wenn im ersten Entscheidungsschritt SZ1 festgestellt wird, dass kein Watchdog im Watchdog-Stack aktiv ist, also |S| = 0, zweigt das Programm ab und umgeht einen zweiten Entschei¬ dungsschritt SZ2 und fährt direkt mit dem zweiten Programm- schritt SP2 fort.
Wenn in einem zweiten Entscheidungsschritt SZ2 festgestellt wird, dass die Abbruchzeit des Watchdogs W größer ist als die Abbruchzeit des obersten Watchdogs Ws im Watchdog-Stack, also der Abbruchszeitpunkt des oberste Watchdogs Ws im Watchdog- Stack vor dem Abbruchszeitpunkt des zu startenden Watchdogs W liegt, wird aus dem Programm abgezweigt und in einem fünften Programmschritt SP5 ein Fehlercode err = 1 gesetzt, um anzu¬ zeigen, dass ein Fehler beim Watchdog-Start vorliegt.
Nach dem vierten Programmschritt SP4, bei dem der Fehlercode err = 0 gesetzt wird, oder dem fünften Programmschritt SP5, bei dem der Fehlercode err = 1 gesetzt wird, wird der Pro¬ grammablauf des Befehls err = StarteWatchdog ( tAbbruch) beendet.
Fig. 5 zeigt beispielhaft den Programmablauf des Befehls Vi- sionFunktion () zur Ausführung und Zeitüberwachung des Vi- sion-Funktionselements VisionFunktion, der nach dem Befehl err = StarteWatchdog (tAbbruch) , dessen Programmablauf in Fig. 4 gezeigt ist, aufgerufen wird.
Im Programmablauf des Befehls VisionFunktion () erfolgt in einem ersten Programmschritt VP1 eine Initialisierung, bei der der Bearbeitungsanteil af auf 0 und der Abbruchzeitpunkt tAbbruch auf unendlich gesetzt wird.
Im einem nachfolgenden ersten Entscheidungsschritt VEl wird dann geprüft, ob sich im Watchdog-Stack ein aktiver Watchdog befindet .
Wenn bei der Abfrage festgestellt wird, dass ein Watchdog ak¬ tiv ist, also I S I > 0 ist, wird in einem zweiten Entschei- dungsschritt VE2 geprüft, ob die aktuelle Zeit taktueii zeit¬ lich vor dem Abbruchszeitpunkt tAbbruch des obersten aktiven Watchdogs Ws im Watchdog-Stack liegt. Wenn dies zutrifft, wird in einem zweiten Programmschritt VP2 die Abbruchs Zeitpunkt tAbbruch auf den Abbruchs Zeitpunkt tAbbruch des obersten aktiven Watchdogs Ws festgelegt. Anschließend wird dann der Vision-Algorithmus VA des Vision- Funktionselements VisionFunktion ausgeführt. Dabei wird am Ende jeder Schleife des Vision-Algorithmus die jeweilige Schleifenbedingung im Entscheidungsschritt VA1 überprüft. Gleichzeitig wird fortlaufend die aktuellen Zeit taktueii mit dem Abbruchszeitpunkt tAbbruch verglichen . Der Vision-Algorith¬ mus wird so lange ausgeführt, bis eine Schleifenbedingung er¬ füllt ist oder die aktuelle Zeit dem Abbruchzeitpunkt ent¬ spricht .
Wenn der aktive Watchdog ein präemptiver Watchdog ist, wird bei Überschreiten des Abbruchszeitpunktes durch die Funkti¬ onslaufzeit des Vision-Algorithmus VA eine Abbruchsfunktion aufgerufen, um den Vision-Algorithmus VA abzubrechen. Bei einem kooperativen Watchdog als aktiver Watchdog ist der Pro¬ grammcode des Vision-Algorithmus VA um eine Zusatzbedingung erweitert. Die Zusatzbedingung vergleicht im Entscheidungs¬ schritt VA1 die aktuellen Zeit taktueii mit dem Abbruchszeit¬ punkt tAbbruch am Ende jeder Bearbeitungsschleife. Wird bei der Überprüfung festgestellt, dass der Abbruchszeitpunkt über¬ schritten ist, wird die Bearbeitungsschleife verlassen und der Vision-Algorithmus VA so kontrolliert beendet.
Wenn die Ausführung des Vision-Algorithmus VA des Vision- Funktionselements VisionFunktion beendet ist, wird in einem dritten Entscheidungsschritt VE3 erneut geprüft, ob sich im Watchdog-Stack ein aktiver Watchdog befindet. Falls dies der Fall ist, wird in einem dritten Programmschritt VP3 der Bearbeitungsanteil af des Vision-Funktions¬ elements VisionFunktion bestimmt. Die Berechnungsvorschrift wird vom Vision-Algorithmus VA vorgeben, wobei beispielsweise die Gleichungen (2), (3) oder (4) herangezogen werden können.
Der Bearbeitungsanteil af wird dann in einem vierten Pro¬ grammschritt VP4 mit den im Watchdog-Stack akkumulierten Bearbeitungsanteilen verrechnet, um den Bearbeitungsanteil für die gesamten Vision-Funktion bestimmen zu können, wobei beispielsweise die Gleichungen (8) oder (9) herangezogen werden können. Anschließend wird dann der Programmablauf des Befehls VisionFunktion () beendet. Wenn im ersten Entscheidungsschritt VE1 festgestellt wird, dass kein Watchdog aktiv ist, also | S | = 0 ist, wird direkt zur Ausführung des Vision-Algorithmus VA des Vision-Funkti¬ onselements VisionFunktion übergegangen. Da dann keine Zeitüberwachung mit einem Watchdog ausgeführt wird, bleibt der ursprünglich initialisierte Abbruchzeitpunkt auf unendlich stehen und nur die Schleifenbedingung wird bei der Ausführung überprüft .
Wenn im zweiten Entscheidungsschritt VE2 festgestellt wird, dass die aktuelle Zeit taktueii zeitlich nach dem Abbruchszeit¬ punkt tAbbruch des obersten aktiven Watchdogs Ws im Watchdog- Stack liegt, wird der Vision-Algorithmus VA des Vision-Funk¬ tionselements VisionFunktion nicht ausgeführt und der Pro¬ grammablauf mit dem vierten Programmschritt VP4 fortgesetzt. Der initialisierte Bearbeitungsanteil af = 0 wird dann mit dem im Watchdog-Stack akkumulierten Bearbeitungsanteilen verrechnet und anschließend der Programmablauf des Befehls Visi¬ onFunktion () beendet. Wenn im dritten Entscheidungsschritt VE3 festgestellt wird, dass im Watchdog-Stack kein weiterer aktiver Watchdog enthalten ist, zweigt das Programm ab und der Programmablauf des Befehls VisionFunktion () wird sofort beendet.
Fig. 6 zeigt beispielhaft für den Befehl (n, a, AtRest, err) = StoppeWatchDogTypA ( ) den Programmablauf, mit dem der Watchdog W vom Watchdog Typ A wieder beendet wird. Der Befehl (n, a, AtRest / err) = StoppeWatchDogTypA ( ) wird nach dem Befehl Visi¬ onFunktion (), dessen Programmablauf in Fig. 5 gezeigt ist, aufgerufen .
In einem ersten Entscheidungsschritt EE1 wird überprüft, ob sich ein zu beendender Watchdog im Watchdog-Stack befindet.
Wenn bei der Abfrage festgestellt wird, dass ein Watchdog im Watchdog-Stack aktiv ist, wird in einem zweiten Entscheidungsschritt EE2 geprüft, ob es sich um einen Watchdog vom Typ A handelt.
Wenn festgestellt wird, dass der im Watchdog-Stack aktive Watchdog Ws solch ein Watchdog vom Typ A ist, wird der Watchdog in einem ersten Programmschritt EP1 aus dem Stack ent- fernt.
In einem zweiten Programmschritt EP2 wird dann die Datenstruktur des aus dem Stack entfernten Watchdogs W aktualisiert. Der Bearbeitungsanteil a wird dabei auf den Wert ge- setzt, der im vierten Programmschritt VP4 des Programmablaufs des Befehls VisionFunktion () bestimmt wurde, wie es anhand von Figur 5 beschrieben wurde. Die Restzeit AtRest wird mit der Gleichung (5) ermittelt, welche die Zeitdifferenz von aktueller Zeit taktueii zu Abbruchszeitpunkt tAbbruch bestimmt.
Wenn es sich beim Watchdog W um einen präemptiven Watchdog handelt, wird in einem dritten Programmschritt EP3 dann noch die Abbruchsfunktion entfernt.
Anschließend wird in einem dritten Entscheidungsschritt EE3 geprüft, ob nach Entfernen des Watchdogs W noch weitere
Watchdogs im Watchdog-Stack liegen.
Wenn im dritten Entscheidungsschritt EE3 festgestellt wird, dass weitere Watchdogs im Watchdog-Stack aktiv sind, also | S | > 0 ist, wird in einem vierten Programmschritt EP4 die akku- mulierte Restzeit AtRest für den Watchdog W auf die im zweiten Programmschritt EP2 ermittelte Restzeit AtRe st festgestellt.
In einem fünften Programmschritt EP5 wird dann vom Watchdog W die Anzahl akkumulierter Funktionselemente W.n, der akkumu- lierten Bearbeitungsanteil W.ä und die akkumulierte Restzeit W.AtRest auf den obersten sich im Watchdog-Stack befindenden aktiven Watchdog Ws propagiert.
Anschließend wird in einem sechsten Programmschritt EP6 ein Fehlercode err = 0 gesetzt, um anzuzeigen, dass kein Fehler bei der Programmausführung aufgetreten ist.
Wenn im ersten Entscheidungsschritt EE1 festgestellt wird, dass kein Watchdog im Watchdog-Stack aktiv ist, also |S| = 0, zweigt das Programm ab und setzt in einem siebten Programmschritt EP7 ein Fehlercode err = 1, um anzuzeigen, dass ein Fehler beim Watchdog-Stop aufgetreten ist. Wenn im zweiten Entscheidungsschritt EE2 festgestellt wird, dass der im Watchdog-Stack oben liegende aktive Watchdog Ws kein Watchdog vom Typ A ist, wird der Programmablauf eben¬ falls mit dem siebten Programmschritt EP7 fortgesetzt, der den Fehlercode err auf 1 setzt, um einen Ausführungsfehler anzuzeigen .
Wenn im dritten Entscheidungsschritt EE3 festgestellt wird, dass kein Watchdog im Watchdog-Stack mehr aktiv ist, also | S | = 0, wird anschließend der sechste Programmschritt EP6 ausge¬ führt und ein Fehlercode err = 0 gesetzt.
Nach dem sechsten Programmschritt EP6, der den Fehlercode err = 0 setzt, oder dem siebten Programmschritt EP7, bei dem der Fehlercode err = 1 festgelegt wird, wird der Programmablauf des Befehls (a, AtRest, err) = StoppeWatchDogTypA ( ) beendet.
Fig. 7 zeigt ein Beispiel für die Propagierung der Restzeit in einem Watchdog-Stack mit fünf Watchdogs 701 bis 705, die auf drei Hierarchieebenen 1, 2, 3 verteilt sind, wobei zu ei¬ nem Zeitpunkt auf jeder Hierarchieebene höchstens ein Watch¬ dog aktiv ist. In der Darstellung in Fig. 7 sind die drei Hierarchieebenen 1, 2, 3 auf der Y-Achse eingetragen. In der hierarchisch tiefsten Hierarchieebene 1 befindet sich der Watchdog 701. In der nächst höheren Hierarchieebene 2 sind der Watchdog 702, der Watchdog 703 und der Watchdog 705 ange¬ ordnet. Auf der obersten Hierarchieebene 3 liegt der Watchdog 704.
Auf der X-Achse in Fig. 7 ist die zeitliche Abfolge der fünf Watchdogs 701 bis 705 im Watchdog-Stack angezeigt. Die Numme- rierung der Watchdogs entspricht dabei dem StartZeitpunkt des jeweiligen Watchdogs . Der Pfeil von der tieferen Hierarchieebene zu der nächst höheren Hierarchieebene zeigt jeweils den Aufruf des Watchdogs an. Der Pfeil von der höheren Hierarchieebene zu der nächst tieferen Hierarchieebene zeigt das Beenden des Watchdogs an.
Der sich in der Hierarchieebene 1 befindende Watchdog 701 startet zum Zeitpunkt 0ms und beendet seine Ausführung zum Zeitpunkt 100ms. Der sich in der Hierarchieebene 2 befindende Watchdog 702 startet zum Zeitpunkt 10ms und beendet seine Ausführung zum Zeitpunkt 20ms. Der sich in der Hierarchie¬ ebene 2 befindende Watchdog 703 startet zum Zeitpunkt 40ms und beendet seine Ausführung zum Zeitpunkt 70ms. Der sich in der Hierarchieebene 2 befindende Watchdog 705 startet zum Zeitpunkt 80ms und beendet seine Ausführung zum Zeitpunkt
90ms. Der sich in der Hierarchieebene 3 befindende Watchdog 704 startet zum Zeitpunkt 50ms und beendet seine Ausführung zum Zeitpunkt 60ms. Die fünf Watchdogs 701 bis 705 sind jeweils Zeitspannen- Watchdogs, wobei in Fig. 7 die tatsächliche Laufzeit des Watchdogs, die sich aus den angegebenen Start- und Stop-Zei- ten ergibt und die durch die Funktionslaufzeit der zugeordne¬ ten zu überwachenden Funktionselemente bestimmt wird. Der Watchdog 702 hat eine Abbruchszeitspanne von 15ms, der Watch¬ dog 703 hat eine Abbruchszeitspanne von Ilms, der Watchdog 704 hat eine Abbruchszeitspanne von 37ms und der Watchdog 705 hat eine Abbruchszeitspanne von 18ms. Es bleiben somit Rest¬ zeiten für den Watchdog 702 von 5ms, für den Watchdog 703 von 7ms, für den Watchdog 704 von 1ms und für den Watchdog 705 von 8ms . Wenn eine Propagierung der Restzeit zum Beispiel zum Zeit¬ punkt 65 ms, der als gestrichelte Linie in Fig. 7 angezeigt ist, durchgeführt werden soll, ergibt sich auf der Hierar¬ chieebene 3 eine Zeitersparnis durch den Watchdog 704 von 1ms und auf der darunter liegenden Hierarchieebene 2 eine Zeitersparnis von 5ms durch den Watchdog 702, sodass bei einer RestZeitpropagierung zum Zeitpunkt 65ms die akkumulierte Restzeit 6ms beträgt.

Claims

Ansprüche
1. Echtzeitumgebung, in der wenigstens eine Task mit einer vorgegebenen Task-Laufzeit ausgeführt wird, wobei wenigstens eine Zusatzfunktion mit unbestimmter Funktionslaufzeit innerhalb der vorgegebenen Task-Laufzeit mit Hilfe einer Zeitüberwachungsfunktion abgearbeitet werden soll,
mit den Schritten:
Starten der Zeitüberwachungsfunktion, die einen Abbruchszeit- punkt für die Zusatzfunktion innerhalb der vorgegebenen Task- Laufzeit festlegt,
Ausführen der Zusatzfunktion, wobei die Zeitüberwachungsfunktion die Funktionslaufzeit überwacht und bei Überschreiten des vorgegebenen Abbruchszeitpunktes ein Funktionsabbruch veranlasst wird, und
Beenden der Zeitüberwachungsfunktion.
2. Echtzeitumgebung nach Anspruch 1, wobei die Zeitüberwachungsfunktion als Wrapper-Funktion ausgebildet ist, welche den Programmcode der Zusatzfunktion umgibt, so dass der Pro¬ grammcode der Zusatzfunktion innerhalb des Programmcodes der Zeitüberwachungsfunktion abläuft .
3. Echtzeitumgebung nach Anspruch 1 oder 2, wobei eine Ab- bruchsfunktion vorgesehen ist, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit aufgerufen wird, um den Funktionsabbruch auszuführen.
4. Echtzeitumgebung nach Anspruch 1 oder 2, wobei die Zu- satzfunktion eine Abbruchsbedingung umfasst, die bei Überschreiten des vorgegebenen Abbruchszeitpunktes durch die Funktionslaufzeit das Ausführen der Zusatzfunktion abbricht und ein Bearbeitungsergebnis rückmeldet.
5. Echtzeitumgebung nach einem der Ansprüche 1 bis 4, wobei die Zeitüberwachungsfunktion den vorgegebenen Abbruchszeitpunkt beim Aufruf als Summe aus der aktuellen Zeit und einer maximal erlaubten Zeitspanne bestimmt.
6. Echtzeitumgebung nach einem der Ansprüche 1 bis 5, wobei die Zeitüberwachungsfunktion beim Beenden eine Kenngröße ausgibt, der den Anteil der erfolgten Funktionsausführung anzeigt .
7. Echtzeitumgebung nach Anspruch 6, wobei die Zusatzfunktion eine Mehrzahl von Funktionselementen aufweist und wobei die beim Beenden der Zeitüberwachungsfunktion ausgegebene Kenngröße den akkumulierten Anteil der erfolgten Ausführung der Funktionselemente und/oder die Anzahl akkumulierter Funktionselemente angibt.
8. Echtzeitumgebung nach einem der Ansprüche 1 bis 7, wobei die Zeitüberwachungsfunktion beim Beenden einen Zeitwert ausgibt, der die Zeitdifferenz zwischen der aktuellen Zeit und dem vorgegebenen Abbruchszeitpunkt anzeigt.
9. Echtzeitumgebung nach einem der Ansprüche 1 bis 8, wobei die Zeitüberwachungsfunktion beim Beenden einen Fehlercode ausgibt, der einen Fehlerzustand bei der Ausführung der Zeit¬ überwachungsfunktion anzeigt.
10. Echtzeitumgebung nach einem der Ansprüche 1 bis 9, wobei die Zeitüberwachungsfunktion wenigstens ein untergeordnetes Zeitüberwachungsfunktionselement aufweist, das einen Ab¬ bruchszeitpunkt für eine zugeordnete Zusatzfunktion innerhalb der vorgegebenen Task-Laufzeit vor dem Abbruchszeitpunkt der Zeitüberwachungsfunktion festlegt .
11. Echtzeitumgebung nach Anspruch 10, wobei die Zeitüberwa- chungsfunktion unter Verwendung eines Stacks verwaltet wird.
12. Speicherprogrammierbare Steuerung (3), die über einen Feldbus (4) mit Aktoren (2) und Sensoren (1) einer Produktionsanlage verbunden ist, wobei die speicherprogrammierbare Steuerung (3) eine Echtzeitumgebung nach einem der Ansprüche 1 bis 11 umfasst, deren Task zum Steuerung von Aktoren (2) und Sensoren (1) dient, wobei die Ausführung der Zusatzfunktion durch die Zeitüberwachungsfunktion mit der Steuerung synchronisiert ist.
13. Speicherprogrammierbare Steuerung (3) nach Anspruch 12, die mit einer Funktionseinheit (6) zur Bilderfassung verbunden ist, um deren Bilddaten in die Echtzeitumgebung zu übertragen, wobei die Zusatzfunktion eine Vision-Funktion zur Verarbeitung und/oder Analyse der Bilddaten ist.
EP17720035.9A 2016-04-22 2017-04-18 Echtzeitumgebung und speicherprogrammierbare steuerung Pending EP3446216A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102016107527.2A DE102016107527A1 (de) 2016-04-22 2016-04-22 Echtzeitumgebung und speicherprogrammierbare Steuerung
PCT/EP2017/059185 WO2017182467A1 (de) 2016-04-22 2017-04-18 Echtzeitumgebung und speicherprogrammierbare steuerung

Publications (1)

Publication Number Publication Date
EP3446216A1 true EP3446216A1 (de) 2019-02-27

Family

ID=58640840

Family Applications (1)

Application Number Title Priority Date Filing Date
EP17720035.9A Pending EP3446216A1 (de) 2016-04-22 2017-04-18 Echtzeitumgebung und speicherprogrammierbare steuerung

Country Status (5)

Country Link
US (1) US10782667B2 (de)
EP (1) EP3446216A1 (de)
CN (1) CN109074279B (de)
DE (1) DE102016107527A1 (de)
WO (1) WO2017182467A1 (de)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP6781191B2 (ja) * 2018-05-24 2020-11-04 ファナック株式会社 プログラマブルコントローラ及び機械学習装置
DE102018133058A1 (de) 2018-12-20 2020-06-25 Beckhoff Automation Gmbh Verfahren zum steuern eines automatisierungsprozesses in echtzeit
CN111708670B (zh) * 2020-06-10 2023-05-09 中国第一汽车股份有限公司 实时操作系统中任务时间参数的确定方法、装置及车辆
US11904399B2 (en) * 2020-11-30 2024-02-20 Metal Industries Research & Development Centre Online prediction method of tool-electrode consumption and prediction method of machining accuracy
CN114879593B (zh) * 2022-05-07 2023-03-14 科东(广州)软件科技有限公司 实时系统运行plc控制器的方法、装置、设备及存储介质
JP7221465B1 (ja) * 2022-06-15 2023-02-13 三菱電機株式会社 制御システム、プログラマブルロジックコントローラ、可視化方法及びプログラム

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4215399A (en) * 1978-08-24 1980-07-29 Texas Instruments Incorporated Special function control system for a dual microprocessor programmable process control system
DE19648422C2 (de) 1996-11-22 2000-03-30 Hans Beckhoff Verfahren und Vorrichtung zum Implementieren eines echtzeitfähigen Steuerprogramms in einem nicht-echtzeitfähigen Betriebsprogramm
FR2818769B1 (fr) * 2000-12-21 2004-06-18 Eads Airbus Sa Procede et systeme d'exploitation temps reel multitaches
DE10148160A1 (de) 2001-09-28 2003-04-24 Siemens Ag Verfahren und Einrichtung zur Bereitstellung von Daten
US7310803B2 (en) * 2001-10-19 2007-12-18 419638 Canada Inc. Method and system for executing multiple tasks in a task set
DE10243856B4 (de) 2002-09-20 2004-09-30 Siemens Ag Regler und Verfahren zum Betreiben eines Reglers
TWI220700B (en) * 2003-08-20 2004-09-01 Delta Electronics Inc Programmable logic controller with an auxiliary processing unit
ATE408178T1 (de) 2004-04-08 2008-09-15 Festo Ag & Co Kg Bilderfassungsvorrichtung für automatisierungsgeräte
DE102005048037A1 (de) * 2005-10-07 2007-04-12 Robert Bosch Gmbh Verfahren zur Steuerung/Regelung wenigstens einer Task
ATE522862T1 (de) * 2008-05-13 2011-09-15 Dspace Gmbh Verfahren zur ausführung von tasks zur berechnung eines zu simulierenden signals in echtzeit
DE102009055752A1 (de) 2009-11-25 2011-05-26 Robert Bosch Gmbh Verfahren zum Ermöglichen einer sequentiellen, nicht blockierenden Abarbeitung von Anweisungen in nebenläufigen Tasks in einer Steuereinrichtung
EP2568346B1 (de) 2011-09-06 2015-12-30 Airbus Operations Robustes Systemsteuerungsverfahren mit kurzen Ausführungsfristen
US9135062B2 (en) * 2013-04-09 2015-09-15 National Instruments Corporation Hardware assisted method and system for scheduling time critical tasks
US10782668B2 (en) * 2017-03-16 2020-09-22 Siemens Aktiengesellschaft Development of control applications in augmented reality environment

Also Published As

Publication number Publication date
CN109074279A (zh) 2018-12-21
CN109074279B (zh) 2022-02-25
US10782667B2 (en) 2020-09-22
WO2017182467A1 (de) 2017-10-26
US20190033814A1 (en) 2019-01-31
DE102016107527A1 (de) 2017-10-26

Similar Documents

Publication Publication Date Title
EP3446216A1 (de) Echtzeitumgebung und speicherprogrammierbare steuerung
EP0655682B1 (de) Recheneinheit mit mehreren ausführbaren Tasks
EP0852759A1 (de) Entwurfsverfahren für die anlagentechnik und rechnergestütztes projektierungssystem zur verwendung bei diesem verfahren
EP2513796B1 (de) Verfahren zum betreiben einer recheneinheit
DE102010028259A1 (de) Mikrocontroller mit einer Recheneinheit und einer Logikschaltung sowie Verfahrung zur Durchführung von Rechnungen durch einen Mikrocontroller für eine Regelung oder eine Steuerung in einem Fahrzeug
EP3417373B1 (de) Verfahren und vorrichtung zum betreiben eines steuergeräts
WO2011063869A1 (de) Verfahren zum ermöglichen einer sequentiellen, nicht blockierenden abarbeitung von anweisungen in nebenläufigen tasks in einer steuereinrichtung
EP0799441A1 (de) Verfahren zur steuerung von technischen vorgängen
EP2363809B1 (de) Verfahren zur Optimierung eines Steuerprogramms für Aktuatoren
CN111679970B (zh) 机器人软件系统运行环境状态预测方法
DE102004059972B4 (de) Thread-Scheduling-Verfahren, und Thread-List-Scheduler-Vorrichtung
DE102009025572A1 (de) Eine Methode zur Entwicklung von garantiert korrekten Echtzeitsystemen
EP2592504B1 (de) Verfahren zur Abschätzung eines Ressourcenverbrauchs bei der Erzeugung eines Steuergeräteprogrammcodes
EP2189908B1 (de) Verfahren und Vorrichtung zum Bestimmen einer Kenngröße eines IT-Systems
WO2021249616A1 (de) Verfahren zum konfigurieren von komponenten in einem system mit hilfe von multi-agent reinforcement learning, computerlesbares speichermedium und system
EP3331740B1 (de) Verfahren zum betreiben einer steuervorrichtung und diagnosesystem
DE102019135293A1 (de) Überwachungseinheit und Verfahren zur Überwachung der von Treibern einer Gerätezugriffseinrichtung belegten Ressourcen
DE102021213918A1 (de) Identifikation von Fehlerursachen auf Befehlsebene in Prozessen
EP2101264B1 (de) Verfahren zur Fehlerbehandlung und Tachographensystem
EP3588849A1 (de) Verfahren zum quantifizieren der zuverlässigkeit einer steuerfunktion, die durch mehrere unabhängige funktionseinheiten bereitgestellt wird; sowie steuereinrichtung
EP3588223A1 (de) Verfahren und system zum bereitstellen einer analysefunktion
WO2010094295A1 (de) Verfahren und vorrichtung zur anpassung der prozessorauslastung in einem automatisierungssystem
EP3403148A1 (de) Verfahren zur steuerung, steuersystem und anlage
EP2936262A1 (de) Verfahren zur überwachung einer ereignisgesteuerten funktion und überwachungsvorrichtung zur ausführung einer ereignisgesteuerten funktion
WO2014044625A1 (de) Verfahren zur projektierung einer automatisierungslösung und vorrichtung zur ausführung des verfahrens

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20181010

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20190416

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

RAP1 Party data changed (applicant data changed or rights of an application transferred)

Owner name: BECKHOFF AUTOMATION GMBH

APBK Appeal reference recorded

Free format text: ORIGINAL CODE: EPIDOSNREFNE

APBN Date of receipt of notice of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA2E

APBR Date of receipt of statement of grounds of appeal recorded

Free format text: ORIGINAL CODE: EPIDOSNNOA3E

APAF Appeal reference modified

Free format text: ORIGINAL CODE: EPIDOSCREFNE