EP1226473A2

EP1226473A2 - Method for controlling mechanisms and technical systems, a corresponding device and control software

Info

Publication number: EP1226473A2
Application number: EP01931411A
Authority: EP
Inventors: Volker MÖBIUS; Knut Grossmann
Original assignee: Technische Universitaet Dresden
Current assignee: Technische Universitaet Dresden
Priority date: 2000-04-04
Filing date: 2001-04-03
Publication date: 2002-07-31
Also published as: JP2003529835A; DE10017708B4; US20030040814A1; WO2001075535A3; US7065413B2; WO2001075535A2; DE10017708A1

Abstract

The invention relates to a method for controlling mechanisms or technical systems, whereby the mechanisms or technical systems to be controlled are, in the elementary functions (8) thereof, stored in a controller with their states, which are defined in an instruction-appropriate manner, and with the associated signal formers of the sensors (13) and actuators (12). When initiated, a new instruction that changes the state of the mechanisms or of the technical system updates the specified state (24) for the comparison and, based on permissible transition times that are also stored, monitors the time till the acknowledgment of the instruction-appropriate new state. In addition, sensor signals and comparable information exclusively serve the state identification of elementary functions (8), state changes exclusively ensue upon the initiation of elementary instructions (16) to which the sensor and actuator signals are assigned as the specified state, and the utilization instructions (32) freely defined at the logic-functional language level are defined by the corresponding assignment of elementary instructions (16).

Description

Process for controlling mechanisms and technical systems, equipment and control software

description

The invention relates to a ner driving for controlling mechanisms and technical systems as well as to the devices of an electronic control to be designed therefor and a ner driving for creating the control software.

From DE 44 07 334 AI a ner driving for creating and displaying controls is known with which controls can be designed graphically in a simple manner. The desired function of the control system is entered graphically into an computer as an event-controlled network of symbols with freely selectable connections or is represented by a computer. The network, converted into machine-readable form, can be used as a control program by the computer or a separate control computer. The method is suitable for programmable logic controllers and DDC systems.

DE 195 13 801 AI discloses a method for automatically generating a controller for a process in which a non-deterministic automaton that describes all physically possible behavior of the controller is defined, in which the permitted state transitions of the controller Process to be influenced are described, in which the machine is set so that it fulfills predetermined safety conditions, in which the machine is set so that it fulfills the function of the system consisting of the control and process. The method uses the programming language CSLxt to describe the components of the system specification. For the specification of the process model, the state transitions are not described in detail, but so-called predefined qualitative constraints are used, which are used to automatically generate the control.

It is disadvantageous that the description of state transitions at a higher language level can be incorrect, and that a subsequent correction of the control is not readily possible.

Beyond that Programmable logic controllers PLC

Hardware PLC

Software PLC

Programming systems and programming languages

Simatic S7

Programming according to IEC 1131-3 standard

Standard programming languages: ladder diagram, function diagram, STL, structured text known.

A disadvantage of the prior art is that, in principle, Boolean algebra is used to formulate conditions from inputs (sensors) for setting outputs (actuators), which are constantly recalculated cyclically. This programming approach was developed historically. Evidence or evidence of this condition is the fact that, according to the generally accepted standard, the "contact plan" can still be used as a programming language.

In spite of all CAE support through graphic interfaces and high-level languages, fundamental defects, such as the complexity of the program and its individual character by the programmer, never fully test the functionality of the program, since the result of the cyclical calculations can be influenced by combinatorial and temporal randomness and the difficult design of differentiated error reactions.

The object of the invention is to provide a control for mechanisms or technical systems that solves the control task without the use of Boolean algebra conditions, with a clear program, free of individual character and with complete verifiability.

According to the invention the object is achieved by a method with the features mentioned in claim 1. The object is further achieved by a method for creating control software having the features listed in claim 11 and by a device having the features listed in claim 16.

Advantageous refinements and developments are the subject of associated subclaims. The essence of the invention is that derived from the functionality of the mechanism or technical system to be controlled, in particular with its development, with technical means the functionality of the device to be controlled is stored in a control computer designed as a control as a complete image of the commanded desired state of the system , is managed and updated and a comparison of this target state is carried out via the reported sensor signals with the actual state of the technical device. This target-actual comparison is carried out continuously for all sensor signals of the system to be controlled. If the actual state deviates from the target state, prepared algorithms are processed and prepared appropriate decisions are activated. Each sensor signal is therefore only compared with exactly one target signal and this comparison is used exclusively for the state identification of the technical system. Status changes are made exclusively via commands at a linguistic-functional level. These commands are managed in a special area of the control system. When a command is started, the target state in the image is updated and the change in the actual state of the technical system corresponding to the command is checked within a predetermined time.

The elementary functions of the devices to be controlled are stored in the control with their states defined in accordance with the command and the associated signal images of the sensors and actuators, with a constant comparison of the actual values reported by the technical system by the sensors starting from a defined reference state at the start of the control activation. States with the target state stored in the controller for all elementary functions and thus any deviation in the system to be controlled from the command-based target state is recognized, a new command changing the state of the technical system updating the target state for the comparison with its start and also based on this stored permissible transition times monitors the time until the commanded new status is reported, sensor signals and comparable information being used exclusively for status identification and status changes is carried out exclusively by starting commands that are freely defined at a logical-functional language level, to which the elementary commands defined with sensor and actuator signals are assigned.

The states of all elementary functions are advantageously carried out as the current target state with the associated actuators and sensors in a program module referred to as an EF controller and thus evaluates every change in the state of the technical system detected by the sensors in accordance with the desired state carried out in the control.

A state of an elementary function of the state-describing signal image which does not correspond to the target is advantageously transferred to a program module which is referred to as a "non-target evaluator" and in which reaction commands for selected states of elementary functions are stored, which are started in accordance with the state transferred for testing, in all cases differentiated error messages are generated.

A command as a command set is assigned both the new target states of the sensors and actuators, the transition times to the new target state as well as the reaction commands to be started in the event of deviations, each differentiated into reaction commands to be deleted and set before the start and after execution of selected status messages, whereby Advantageously, a program module referred to as "command processor" takes over the necessary organization in the system and in this program module the release of a next command for command sequences after completion of the previous message and the organization of parallel commands is realized by temporarily opening parallel processing sequences as required.

The organized control system is advantageously combined with sensor signals and other information to be checked in a program module referred to here as a "status monitor" to form a complete data word, the signals remaining assigned to the address of the associated elementary function in the EF controller and the actual signal for the comparison of each target signal has the same structure, which enables a programmatically very effective target / actual comparison, whereby a deviation of a signal after the transfer is entered for evaluation as a new comparison state and thus a comparison is always made with the last evaluated state and each state change is only evaluated once the comparison of the target / actual signals takes place in a directed manner and, after an interruption for the evaluation of a deviation, the comparison is continued with the signal following the point of interruption, thereby ensuring that Every change of state that is sufficiently long in time can be recorded and evaluated.

In a control system organized in this way, every change in status recorded in the status monitor program module is stored in an event-time log, which means that The process parameters described are accessible in the simplest way so that, for example, signal vibrations can also be recognized and, if necessary, filtered out.

The program modules, which are subject to the real-time requirements, command conditioners, EF controllers, status monitors and non-target evaluators are advantageously combined to form a functional unit which is referred to as an "execution computer", for which purpose a special processor is used, while the commands of the actual usage programs, which are only formulated at a logical-functional language level a second functional unit, which is not subject to real-time requirements and is referred to as a "command computer", can be organized, the command computer expediently having its own processor for a larger and variable range of commands, and communication here can also be designed conveniently.

Commands transferred from the command computer to the execution computer are advantageously carried out there without checking, the execution computer realizing the action to be carried out independently. For this reason, lock directories are maintained and managed in the command computer at the logical-functional command level to the mutually exclusive states, which take over the part of locks determined on the process and machine side. Here, in the command computer with a usage process command, in addition to the information, which commands the execution computer to be handed over, it is also stipulated for which other usage commands blocks should be set or removed during or after execution.

The execution computer can execute a received command autonomously, whereby the command computer provides the execution computer with the next checked command in a command buffer as a buffer and, after being made available, updates the state in the command computer to the state that will occur after the execution of this command and thus a check of the subsequent command in the command computer is already carried out during the execution of the previous command in the execution computer and, as a rule, a faster program execution can thus be implemented. Incompatible commands are recognized and flagged as not permitted in the command computer and no such command is started. If the prepared command is permissible, the state expected for checking the command in the command computer occurs if the execution is error-free and the process is continued, while in the event of an error, the status of the current command is reset as an error state. The user of this control is advantageously supported in a dialog-guided manner by a development program in the creation of a control program, the first description of the system to be controlled requiring the hierarchical functional structure of the system to be specified, the lower end of this structure being regarded as an elementary function and each elementary function also being in dialogue is to be defined in their command states and these defined commands are to be assigned the sensor signals, the actuators, the control times for the transition between the command states and a reference state for the start, and the integration of more complex subsystems can be defined, whereby the user of the control system only makes the primary statements mentioned here and the control development program uses them to generate the system elementary function memory, the EF controller and the signal vector for the condition monitor and thus the technical system already put into operation. Checked for error-free signal definition in the reference state, controlled with the defined elementary functions and, if permissible, tested and checked in individual commands.

For such a dialog-based system, the usage commands are advantageously developed in such a way that usage commands to be defined in a process-related manner from the previously defined elementary commands are assigned individually, in parallel or as a sequence, for this purpose the blocking conditions at the command level in the command computer and for those to be transferred to the execution computer Instruction set also the reaction commands to be entered in the non-target evaluator for selected deviations, combined with suitable error messages, are specified.

For a control system constructed in this way, changes to elementary functions remain locally limited. New usage commands, blocking conditions or error responses can be expanded or changed at any time and also with a manageable local effect, or a new assignment of commands and command conditions can be made without any effect on already defined programs, differentiated by the allocation of status information for the system.

Each program created in this way can be fully checked in its logical-functional structure. Important additional process information is accessible via the event-time protocol, a clear cause is always diagnosed for every fault without additional measures, the system status can be shown completely and at any time, a copy that is equally meaningful to the status of the system to be controlled can be sent to one connected to the system external control computer, the elementary functions and the defined commands can directly serve as a functional basis for a visualization of the systems and processes to be controlled and the communication of the control program with other intelligent program modules, such as simulations for process optimization, can be organized in a simple manner.

For small control systems with a limited range of commands, the modules of the execution computer and the command computer can be introduced with fixed command sets, which can be called up with simple control elements, with an identical interface and an external computer connected via a suitable interface can be implemented, with which the introduction of the control software and, if necessary, comfortable communication and diagnosis can be realized and thus comparable control properties and comparable comfort can be achieved at low cost.

The solution according to the invention avoids the shortcomings of the prior art by means of a previously unusual programming approach, which makes use of the designed and thus imprinted functionality of the system. A signal link with Boolean algebra in condition equations for setting outputs is completely replaced by new means.

The invention is explained in more detail below on the basis of exemplary embodiments. The drawings show:

Fig. 1 shows a basic structure of the areas of responsibility in the structure of the controller

2 shows a hierarchically structured functional structure of a technical system

Fig. 3 for the elementary functions information to be determined using a general example

Fig. 4 shows a simple technical system in a schematic representation

5 shows a functional structure corresponding to FIG. 4

6 shows a definition of the elementary commands corresponding to FIG. 4

7 shows a representation of the input and structure of a data structure for implementing the control Fig. 8 shows a structure of an execution computer

9 shows a content of an instruction as an instruction set for the instruction buffer

Fig. 10 is an illustration of the operation of a command starter

Fig. 11 shows the operation of an EF controller

Fig. 12 shows the operation of a non-target evaluator

Fig. 13 is an illustration of the operation of a condition monitor

14 shows a structure of an event-time protocol

Fig. 15 shows an example of a formal instruction name formation base

Figure 16 shows an example of defining usage commands

17 shows an example of a lock directory maintained in a controller

18 shows an example for the definition of error commands

19 shows an example of a controller with more complex tasks

20 shows a structure and name definition according to FIG. 19

21 shows all the information for a command library of a command computer according to FIGS. 19 and 20

Fig. 22 features of a design as a small controller

Fig. 1 shows the basic structure of the task areas in the structure 1 of the new controller. The execution computer 2 is assigned the time-critical tasks target-actual comparison, reactions to deviations from the actual to the target status and the command-based call of state-changing actuators. Instructions received by the instruction computer 3 are implemented by the execution computer 2 without checking, the execution of an instruction and the reaction to deviations from the target / actual state being implemented autonomously by the execution computer 2. It is expedient or, for the shortest possible control response times in more complex systems, to assign the execution computer 2 its own hardware with its own processor.

In the command computer 3, all control operations are managed on a logical-functional level. Here, device-oriented elementary commands become process-related usage commands as Single commands, defined as parallel or serial command sequences, filed and called. Here, locks for mutually exclusive states are also managed at the logical command level as an alternative to previous interlocks and condition formulations via Boolean signal links. In this control concept, the application computer 4 has all the tasks that are not assigned to the execution computer or the command computer. This primarily concerns process-related problems, such as those in the area of workpiece programming for a CNC control.

The control can be configured appropriately for different scope and different task complexity, whereby the same principles apply in the development system for all configurations. With a very small number of instructions, the portion of the instruction computer 3 can be assigned to the execution computer 2 as a software area. In today's typical PLC tasks, execution and command computers with their own processors would be used, whereby the system can be operated via operating and signaling elements and monitor equipment. In all versions, it is also possible to connect a convenient communication system - for example a portable computer - via an easy-to-design interface and thus carry out programming and commissioning or diagnosis in the event of a fault.

2 shows an example of the hierarchically structured functional structure 5 of a technical system. It is justified in terms of the development method that such a system structure can be set up specifically for each technical system, from the functional unit for the overall system 6 via different functional units of the subsystems 7 to the functional units elementary functions 8. The end branches of this tree structure represent elementary functions in the sense of the new control, which are characterized by the fact that these functional units can assume different states and cannot be further subdivided, the functional states of interest on the control side therefore no longer represent the combined states of other elementary and functional groups to be controlled are, as is characteristic of superordinate non-elementary functional units 6 and 7 in the structure. The decisive factor here is the position in the system to be controlled, so that an intelligent subsystem integrated by a few elementary commands is also classified as an elementary function. 3 uses a general example to describe the information to be determined for elementary functions in a “data sheet for elementary functions” 9. The name for the elementary function that identifies this elementary function is specified in 10. A functional sketch 11 expediently shows the features of the states of the elementary function with the assignment of actuators 12 and sensors 13. The information required for the control is systematized and defined in a manner suitable for data processing in the marked area for the state definitions 14. The state definitions 14 show the states that the elementary function can assume and the definition of the signal vectors assigned to the states 15 for the actuators 12 and sensors 13. Likewise, the commands 16 that trigger a transition to a specific state are defined here, and a control time 17 is specified for each of these transitions, which is usually a multiple de r is likely to be a functional time and is only used to identify execution errors if the commanded state is not reached. With the marking, one of the possible states is defined as the reference state 18.

FIG. 4 shows a simple technical system, for which the functional structure is shown in FIG. 5 and the definition of the elementary commands in FIG. 6.

The hierarchical functional structure described here and the definition of the associated elementary functions are essentially primary development contents that can be documented with only a little additional effort and at a relatively early stage in product development.

Fig. 7 shows the input and structure of the data structure when using the new control. The editing level 19 contains the two main components hierarchical function structure 5 and the data sheets of the elementary functions 9. Each functional unit elementary function 8 in the structure must be described with a corresponding data sheet on elementary functions 9. This completeness of the information and its formal correctness is automatically checked on the editing level. If the test result is positive and the user confirms that the system description has been completed, the input is closed and the database for the control system for the system described is generated from the available information. The first step is to generate the elementary function memory 20. This elementary function memory 21 contains all the elementary commands of the system, all system states and the information defined for this, such as they were described with Fig. 3. The formal names of the elementary functions are derived from the structure, so that elementary functions are given an unmistakable name even when using the same data sheet. In the second step, the EF controller 22 is generated. For this purpose, the reference state of the system is set up in the EF controller 23 from the defined reference states 18 of all elementary functions. For the actual state of the elementary functions, which is likewise carried out here, the data structure for storing the actual state of the elementary functions 25 is created by doubling the data structure of the target state of the elementary functions 24. It would thus already be possible to make a comparison between the target and the actual state of the sensors of the elementary functions when operating the control. However, greater effectiveness is made possible by the third step, identified by 26, for generating the condition monitor 27 (also described in more detail later). The desired signal vectors of the elementary functions 28 and, likewise, the actual signal vectors of the elementary functions 29 become the desired signal vector of the system 30 and the Actual signal vector of the system 31 is formed. Each sensor in the system signal vector remains assigned its source address as the name of the elementary function 10 in the EF controller 23.

FIG. 8 shows the structure of the execution computer 2 and the interaction with the instruction computer 3. The execution computer 2 receives a usage instruction 32 to be executed from the instruction computer 3. This is decoded in a command conditioner block 33. In doing so, usage commands are converted into their corresponding elementary commands and the complete assigned information content of the command set is transferred from the elementary function memory 21. This instruction set is entered in the instruction buffer 34 of the execution computer. After acknowledgment that the previous command has been completed, the command starter 35 starts the command waiting in the command buffer 34 and carries out all the activities associated therewith. This applies to the updating in the EF-Controler 36 block, in the status monitor 37 block and in the non-target evaluator 38 block. The command starter 35 block enters the new target state for the sensors in the EF-Controler 36 block for the elementary function in question and by setting it according to the command of the outputs the corresponding actuator command started. The control time 17 assigned to the execution of the command is also started. In the non-target action memory 39, the components of the command set "non-target commands and messages" are entered. After execution of the start activities by the command starter 35, the state monitor 37 again compares the target signal vector of the system 30 with the actual signal vector of the system 31. If there is a discrepancy between the target and the actual detected in this comparison, the EF controller 36 the actual state of the deviating signal in the actual signal vector of the elementary function 29 is updated. In the EF controller 36, the deviation is evaluated (described in more detail in FIG. 11), either a) without further reaction due to the status “when changing”, which is recognized by the current timer, and thus the activities are returned to the state monitor 37, b). By recognizing an executed command when the target signal vector of the elementary function 28 and the actual signal vector of the elementary function 29 match in the EF controller 36 and thus calling the command starter block 35, or - if neither is true - c) the transfer of the actual signal vector of the elementary function 29 to the component non-target evaluator 38. There, this actual signal vector 29 is compared with the signal vectors in the non-target action memory 39 and, if there is a match, the non-target command 40 assigned to this case is started via the component command starter 35. If there is no match, there is a return to the condition monitor 37. In all cases, a corresponding Message 41 generated. The area marked with 42 marks the time-critical activities.

FIG. 9 shows the content of an instruction 43 as it is entered as an instruction set in the instruction buffer 34 of the execution computer 2. Line (1) contains the designation of the elementary function 10 instructed to change, line (2) and line (3) contain the new target state of the sensors or the actuators and thus the target signal vector of the elementary function 28, line (4) gives the control time 17, in which the change of the state to the new specification must have taken place, line (5) contains the information for updating the entries in the non-target action memory 39 for reactions with non-target commands 40 that are valid from the start of the command, and line (6 ) includes the same for the update after successful command execution. The information in lines (1) to (4) corresponds directly to the definitions from the editing level 19 for the elementary functions 8. The lines (5) and (6) can also non-target commands 40 from definitions of process-related specifications about the usage commands 32 include.

10 describes the mode of operation of the command starter 35 module and the handling of subsequent commands 44 and parallel commands 45. The command buffer 3 is always loaded by the command computer 3 with the command following the current command execution. Defined command sequence gen (= follow-up commands 44) do not differ from individually defined, independent commands.

Parallel commands 45 are characterized in that they can be executed functionally and temporally independently of one another and also have to be executed in parallel for an optimal time sequence. For each command defined as parallel, a separate command buffer 46 is therefore defined at the interface between command computer 3 and execution computer 2, from which independent parallel command sequences 45 can be processed. If there are no more pending after parallel commands 45 have been processed, the opened memory areas are closed again, so that only buffer memories 46 that are currently required are kept. 10 shows an example of three opened parallel commands 45, from which the entered commands 43 are started one after the other. If test 47 shows that no further command is pending in the memory buffer, the corresponding parallel command buffer 46 is closed and the status monitor 37 block is called. If the test result 48 is positive, the command content 43 is updated and started. After these operations have been completed, the EF controller 36 is activated 49. After the command-appropriate state 50 has been reached, the updates specified for this in the command set 43 are carried out by the command starter 35 and the next command is then determined and started.

11 shows the mode of operation of the EF controller 36 module. The start 51 for an activity of the EF controller is always triggered by a current change. This is either a new setpoint signal vector of an elementary function 28, which the command starter 35 enters 52 with a new command, or an update 53 of the present actual state 29 carried out by the state monitor module. The first check 54 compares the setpoint with the actual state , If there is a match, it is checked whether the change status 55 was set. If this is the case 56, an ongoing command has been completed, otherwise 57 the commanded state has been reached again after a faulty deviation. In both cases, a corresponding message is generated and the command starter block 35 started 58 - if the actual and target states do not match, branch 59 is processed. The change status is checked again 60. If the change status for this elementary function is before 61, the message “EF when changing” is generated 62 and the module status monitor 37 is started. However, if there is no change status before 63, the name and the present non-target actual signal vector become 64 the elementary funct on is entered in the evaluation memory of the non-target evaluator 65 and the non-target evaluator 38 is started.

12 shows the mode of operation of the non-target evaluator 38. The start 66 of the non-target evaluator is triggered by the EF controller 36 after a non-target signal vector 64 has been transferred. In the first step it is checked whether there are 10 entries in the non-target action memory 39 under the name of the elementary function. (As already described in FIG. 10, these entries are updated by the command starter 35 as information components of a command 43.) If there are no specifications 67 for the elementary function in the non-target action memory 39, only an error message 67a with the designation of the elementary function and the non-target is issued - Actual signal vector 64 with identification of the faulty signal to the higher control level - the command computer 3 - for evaluation. Then the block status monitor 37 is started again.

If there is a non-target signal vector for the elementary function 68 in the non-target action memory 39, the next step is to compare the non-target actual signal vector 64 for agreement with the stored signal vector 69. If there is no match 70, only a specific error message 67 is generated again and likewise the condition monitor 37 started again. If, however, there is a match between the signal vector and entries in the action memory 71, reaction commands 72 which have been set in this case are transferred to the command starter 35 for immediate execution. In parallel, a check 73 is carried out for the message to be generated to determine whether an event controller 74 is present. With an event control 74, the system moves within the normal functional range, a detected event calls up a corresponding action (for example the switching off of a pump when the upper fill level is reached). In this case, the corresponding message 75 identifies the event command of the elementary function 76 in a clear distinction from error states. If it is not an event control 77, a corresponding error message 78 is generated.

13 shows the mode of operation and features of the state monitor 37 block. If no other block activities are running, the state monitor continuously starts the comparison 80 of the desired signal vector 30 and the actual signal vector 31 of the system. This comparison always captures the entire system signal vector and is repeated continuously if the compared conditions match 81. If a deviation is detected, it is first checked whether the system is able to state and execute a new command. If this is the case 82, the command starter block 35 is started. In the other case, the deviating actual signal is entered 83 in the actual signal vector of the elementary function in question in the EF controller and there - as explained in relation to FIG. 11 - evaluated. A deviation can arise either by specifying a new target state when a new command is started and an entry is made in the target signal vector 30 of the system by the EF controller 36, or in another case by a changed sensor signal in the actual signal vector 31 of the system. After the deviating actual signal has been entered in the elementary function concerned in the EF controller, this reported actual state is entered 84 as a new comparison state in the target comparison vector. This ensures that each change is evaluated only once. The target comparison state of the system signal vector is thus defined as a comparison with “the last evaluated state” of the system 84. It is thus possible and useful to enter the detected event 85 in an event-time log 85, which is shown in FIG. 14 After the actions of the status monitor 37 mentioned, it starts the EF-Controler 36 block. After the evaluation has been carried out, the status monitor block is called up again, as described for the operation of the EF-Controler or command starter The target-actual comparison in the system signal vector continues with the signal that follows the last mismatched signal, thus ensuring that all signals of the system signal vector are compared in succession and that an oscillating signal cannot cause an endless loop conceivable with the signal just evaluated if this signal has its Z would change in time with the signal runtime.

14 is intended to illustrate the structure of an event-time protocol 85 in the form of a list. The first column contains the name of the elementary function affected by the event, column 2 the signal affected by the change, column 3 the changed signal state. These are copies of the information that the condition monitor passes on to the EF controller. If the current system time is entered in column 4 when the event is recognized, a process log can be used in many ways. In the example, the first and the last entry indicate that the elementary function Al 1 has reached the first state again with the signal El. The times assigned to the events could possibly serve as an exact measure for such a period. With this protocol it is also possible to recognize signal vibrations and, if necessary, to activate filters which, for example, determine the sampling frequency for the can reduce vibrating signal. Depending on the process and meaning of the information and the available memory, longer times can be recorded and saved, which can be used for diagnostic purposes with regard to long-term changes, or the last section is only available with a limited memory, for example for an accident evaluation.

FIG. 15 shows, for the example shown in FIGS. 4 to 6, the basis for forming the formal command names 86, which are derived from the functional structure 5 and can be used for a clear description of the elementary functions in usage commands.

In FIG. 16, the use example of FIGS. 4-6 shows the definition of usage commands and the setting of command locks 88 for the usage commands.

FIG. 17 shows, as an example, the lock directory 89 of the locking system system, which is kept in the control system, and is intended to illustrate the dynamic effect of the lock conditions defined in FIG. 16. 17 it must be emphasized that it is an auxiliary representation and that such a table does not exist in the control. There is always only one memory area in which different conditions are entered at different times (shown here with tl to t8) due to the commands that were active until then.

All commands of the system are listed in column 1. If an activated usage command contains a blocking condition for another command, the causing command is entered as a blocking condition for the other command. In this example, when it is activated at time t7, command EF2-B2 (lock) blocks command EF1-B1 (open door winder). As specified, the bolt should only be able to be inserted when the door is closed, which is why the lock is entered in EF2-B2 with the command "(open door) EF1-B1" at time t3.

For the mode of operation of the control, it is important that the command computer 3, after a usage command 32 has been transferred to the command buffer 34 of the execution computer 2 - which it can then execute autonomously as described - updates its state as it will occur after this command has been properly executed. For this state, the admissibility of the next command is checked while the previous command is being executed and, if necessary, released. In the example, during the "unlock bolt lock" execution at tl, the "open door" command is located in the command buffer, which will be started at time t3 and then at the same time the check of the "close door" command is activated for the time t5 according to the conditions from the time t4.

This ensures that the following command, which has already been checked, can start immediately when a command is completed or, similarly, it is recognized during the running time of a command that the next command prepared is not permitted for the upcoming system state. If an error occurs in the command running in the execution computer, the command computer is reset to the error state updated.

Fig. 18 (on sheet 12) is to show an example for the definition of error commands. It is assumed to be critical if, for whatever reason, the door hits an inserted bolt when closing. 18 shows the formulation of an error command as a component of the "close door winder" command set. From the state of the elementary function bolt lock El = 1, "bolt not free" is inferred and the "close door" "open in door" process is reversed as an error response in the non-target evaluator ,

Analyzes show that usually only a few error commands are required at a certain point in time. In principle, it is possible to react to any event with any command.

FIG. 19 is intended to show the possibilities of control for more complex tasks and different usage requirements of a system as a further example. The term “status” 90 is to be used for such different usage requirements and the resulting different command and blocking conditions in a system.

It is assumed that two door systems are to be controlled, which are individually the same as the previous example. There is also a system switch for the desired operating status: in status S1 the doors can be operated independently of one another, in S2 both are opened or closed synchronously and in S3 as a lock one of both doors always remains closed.

FIG. 20 shows the structure and name definitions as they are built up by the control here according to the information given in the editing level 19.

FIG. 21 shows all the information for the command library 92 of the command computer in order to solve the task. The specifications drawn up for the locking system of a door are used for the Immediate door control of a copy doubled when generating under the new system name. All definitions of the control status of both doors are implemented via newly defined status command sheets 91, which are selected via the status switch. With the status S3- * instruction sheet not an elementary function was used for the lock formulation but with "door x" a higher hierarchical level in the functional structure. This means that entire functional areas can be locked very effectively against changes in status or can be selected very effectively with the phrase "all except XXX" ,

FIG. 22 shows features of a small controller 94 in a technical device 95. The relatively small and fixed range of commands of the small controller 95 is arranged in a control hardware module which contains the functionality of the execution computer 2 and the command computer 3. The operation is carried out with conventional switching and display devices 96. A computer 98 can be coupled via an interface 97, with which all the functionality of the control for introducing the control software and comfortable communication and diagnosis are possible.

LIST OF REFERENCE NUMBERS

1 Structure of the ASS control

2 execution computers

3 command computers

4 application computers

5 functional structure

6 Functional unit overall system

7 functional unit subsystem

8 Functional elementary function

9 Data sheet on elementary functions

10 Name of elementary function

11 Functional sketch

12 actuators

13 sensors

14 state definitions

15 signal vectors

16 elementary commands

17 inspection time

18 Reference state

19 Editing level

20 Generating the elementary memory

21 elementary memory

22 Generating the EF controller

23 EF controller

24 Target state of the elementary functions Actual state of the elementary functions Generate the state monitor State monitor setpoint signal vector of the elementary function Actual signal vector of the elementary function Setpoint signal vector of the system Actual signal vector of the system Use command Command conditioner Command buffer B component Contents of a command Follow-up commands Parallel commands Command buffer for parallel commands Test result command buffer "no" Test result command buffer "yes" Activation EF-Controler activities Command starter on reaching "command-appropriate state" Start of EF-Controler activity Change target state in EF-Controller by command Change actual state in EF-Controller by sensor message Comparison of target and actual state in EF-Controller Change status in EF-Controller Alternative "Change status" Alternative "No change status" Call command starter from EF Controler alternatives in the event of a mismatch between the target and actual status in the EF controller Checking the change status in the event of a mismatch between the target and actual status in the EF controller. Activity in the event of a change and mismatch between the target and actual status in the EF controller Change "Alternative in the EF controller if the actual state is not equal to the target state and no change state. Non-target actual signal vector Evaluation memory Non-target evaluator Start Non-target evaluator Action if the non-target elementary function has no entry in the non-target action memory. Error message for the non-target elementary function Aktio n, if non-target elementary function has an entry in the non-target action memory. Compare non-target actual signal vector with stored non-target signal vector in the non-target evaluator action in the event of a mismatch of non-target actual signal vector with non-target signal vector in the non-target evaluator 71 Action in the event that the actual signal signal does not match the signal signal vector in the non-target evaluator

72 reaction commands in the non-target action memory

73 Check whether non-target actual signal vector belongs to event control

74 Event control

75 Event control message

76 Content of the event control message

77 Error message if no event control

78 Contents of the error message

79 Start of the condition monitor block

80 Comparison of the system's SoUsignalvector with the system's actual signal vector

81 Program loop for comparing the system's SoUsignalvector with the system's actual signal vector

82 Transfer of activity from the condition monitor to the command starter

83 Entry of the changed actual sensor signal from the status monitor in the EF controller

84 Comparison target vector "last evaluated state" in the state monitor

85 Event-time log

86 formal command names

87 Command locks

88 Lock directory in the command computer

89 Lock directory of the locking system example

90 Status of a plant

91 Status command sheets

92 Command library

93 usage programs

94 Small controls

95 Technical device with small control 96 switching and display devices

97 Interface for computer connection

98 Portable computer

Claims

claims

1. A method for controlling mechanisms or technical systems, characterized in that a) the mechanisms or technical systems to be controlled in their elementary functions (8) with their states defined in accordance with the command and the associated signal vectors (15) of the sensors (13) and actuators ( 12) are stored in the control system, starting from a defined reference state (18) at the beginning of the control activation, a constant comparison of the actual states reported by the technical system by the sensors (13) with the target states (24) stored in the control system for all elementary functions are carried out and so that any deviation in the system to be controlled from the commanded target state (24) is recognized, b) a new elementary command (16) which changes the state of the mechanisms or the technical system updates the target state (24) for the comparison with its start and on the basis of permissible control times also stored (17) monitors the time until the commanded new state is reported, c) sensor signals and comparable information are used only for the state identification of elementary functions (8), state changes are carried out exclusively via the start of elementary commands (16), to which the sensor and actuator signals are the target state are assigned and the usage commands (32) freely defined at the logical-functional language level are defined by corresponding assignment of elementary commands (16).

2. The method according to claim 1, characterized in that a) that in the control in a special program module, here referred to as EF controller (23), the states of all elementary functions (8) as commanded current target state (24) and as current actual state ( 25) with the associated actuators (12) and sensors (13), b) whereby each change in state of the technical system detected via the sensors (13) Stems of the elementary function (8) concerned can be assigned as the current actual state and compared and evaluated with the SoU state (24) carried out in the control.

3. The method according to claim 1 or 2, characterized in that a) at a recognized, not the target state (24) corresponding actual state (25) of an elementary function (8) of the signal state (15) describing the actual state to another special program block of the controller , referred to here as a non-target evaluator (38), b) wherein in this non-target evaluator (38) reaction commands (72) are stored for selected states of elementary functions (8) which are started in accordance with the state transferred for testing, c) and in all cases differentiated error messages are generated with details of the elementary function concerned and the deviating signal.

4. The method according to claim 1 to 3, characterized in that a) a use command (32) as a command set both the new target states (24) of the sensors (13) and actuators (12), the control times (17) for the new target state (24 ) and the reaction commands (72) to be started in the event of deviations, each differentiated into reaction commands (72) to be deleted and set before the start and after execution, to selected status messages, b) with another special program module of the controller, here referred to as the command starter (35), who takes over the necessary organization in the system and thus also enables the release of a next command in the case of command sequences after the fulfillment message of the previous one and the organization of parallel commands (45) by temporarily opening parallel processing sequences as required.

5. The method according to claim 1 to 4, characterized in that a) sensor signals (13) and further information to be checked in a further special program module, referred to here as a status monitor (37), are combined to form a complete data word, the signals being the address the associated elementary function (8) in the program block EF-Controller (36) remains assigned to the controller, b) for comparison, each actual signal (30) is compared with the actual signal (31) of the sensor message in the same structure, c) the program block condition monitor (37) if a deviation of an actual signal is detected, this is updated in the EF controller (36) as the new actual state of the elementary function (29), d) and after the update and transfer for evaluation in the EF controller (36) the changed signal as new comparison status is entered in the status monitor (37), with which a comparison in the status monitor (37) always relates to the last evaluated closure status has occurred and each change in status is only evaluated once, e) whereby the comparison of the target / actual signals (30, 31) is carried out in the status monitor (37) and after an interruption for evaluating a deviation, the comparison at that following the point of interruption Signal is continued, which ensures that every change of state that is sufficiently long in time can be detected and evaluated.

6. The method according to claim 1 to 5, characterized in that a) each detected change in state by the program module state monitor (37) can be entered in an event-time protocol (85) and stored there, b) making time-dependent process parameters easily accessible are so that signal vibrations can also be recognized and, if necessary, filtered out.

7. The method according to claim 1 to 6, characterized in that a) the sub-area execution computer (2) with the program blocks command starter (35), EF controller (36), non-target evaluator (38) and status monitor (37) after transfer of an elementary command ( 16) on the program module command starter (35) in the control does not contain a check for admissibility, b) the execution of a received command is carried out independently by the program blocks assigned to the execution computer (2), c) in the sub-area command computer (3) of the control Logical-functional command level to the mutually exclusive states of lock directories (88) are managed and managed, which assume the part of functional locks determined on the process and machine side, d) whereby a usage command (32) in addition to calling elementary functions (8) to be changed also contains the information for which other commands locks in the lock directory (88) to be set or canceled during or after the execution of this usage command (32).

8. The method according to claim 1 to 7, characterized in that the execution computer (2) and the command computer (3) work in time decoupled by one program step, a) the executing part of the controller, the execution computer (2), executes a received command independently , wherein a command-managing part of the controller, the command computer (3), the executing part execution computer (2) provides the next following checked command in a buffer as a command buffer (34), b) and after the provision of a command in the command buffer (34) of the Execution computer (2) the state in the command computer (3) is updated to the state that will occur after the execution of this command, and for this expected state the test of then the following command for admissibility is already carried out in the command computer (3) while the previous one is being processed, c) if the expected state does not occur due to an error, the checked command is reset from the command buffer (34) and the system is updated to the fault state.

9. The method according to claim 1 to 8, characterized in that usage commands (32) are worked out, a) by assigning the usage commands (32) to be defined linguistically and functionally close to the process from the previously defined elementary commands (16) individually, in parallel or as a sequence, b) the lock conditions at command level for the updates to be carried out when the user command (32) is called are defined in the lock directory in the command computer (88), c) the reaction commands (72) are set to selected deviations and suitable error messages, d) this information is stored in a command library (92) are stored, where the controller then retrieves the command content for usage commands (32).

10. The method according to claim 1 to 9, characterized in that a user program (93) for the operation of the technical system determines the sequence of defined user commands (32) which are to be processed one after the other or in parallel.

11. Process for creating control software, characterized in that the creation of the control software is supported by a development system with dialog guidance, a) whereby the description of the system to be controlled requires the specification of the hierarchical functional structure (5), b) the lower end of this structure is considered as an elementary function (8) and each Elementary function (8) is also to be defined in dialogue in their command states, c) these defined elementary commands (16) being the signals from the sensors (13), the actuators (12), the control times (17) for the transition between the command states and a reference state (18) can be assigned at the beginning, d) the integration of more complex subsystems can also take place as an elementary function (8) if the position in the functional structure (5) indicates such, e) using the dialog system as the basis for the description of the functionality of the technical system only the primary information on structure (5) and the elementary functions mentioned here ctions (9).

12. The method according to claim 11, characterized in that the dialog-guided development system for creating the control software after input of the primary information a) the system elementary instruction memory (21), b) the EF controller (36) and the c) SoUsignalvektor (30) as well as creates and generates the actual signal vector for the condition monitor (37) and thus the technical system has already been put into operation, checked for error-free signal definition in the reference condition (18) and controlled with the defined elementary commands (16) in a commissioning status and, if permissible, tested and checked with these individual commands can be.

13. The method according to claim 11 or 12, characterized in that changes to information on structure (5) and elementary functions (8) are only possible via the editing level (19) and the subsequent automatic generation ensures the consistency of the changed state.

14. The method according to claim 11 to 13, characterized in that the development system for the definition of usage commands (32) in specific dialogs a) offers the available elementary commands (16) of the system for assignment, b) queries locking conditions for the lock directory (88) , whereby the information for locks to be determined can be made graphically via selection in the function structure (5) and lock definitions in formulations "this elementary command", "this elementary function", "this branch of the function structure" or "all functions of this function branch except this elementary command", c ) Specifications for specific reaction commands (72) are queried for particular errors, d) all specifications are stored and arranged and managed in the command library (92).

15. The method according to claim 11 to 14, characterized in that a) that changes to elementary functions (8) remain locally limited for a control system constructed in this way, b) that new usage commands (32), locking conditions in the lock directory are also available at any time and with a manageable local effect (88) or error reactions can be expanded or changed by reaction commands (72), c) that differentiated by the assignment of status information (90) for the system without any effect on already defined programs, new definitions of usage commands (32) and command conditions can be made.

16. Device for controlling mechanisms or technical systems, characterized in that a) that different areas of the device are provided for the different tasks and that these are configured according to the most important task characteristics, in particular short reaction times to recognized events and safe program sequences being achieved, b ) that the program modules for all time-critical tasks of the control command starter (35), EF controller (36), non-target evaluator (38) and status monitor (37) are arranged in a part of the device referred to here as execution computer (2), c) the execution computer (2) with extensive programs with great program variability for these time-critical tasks has its own processor, d) that the execution computer (2) for communication with the device to be controlled via the sensors (13), the activation of actuators (12), the target-actual comparison, reactions au f deviations of the actual (25) from the target state (24) and the processing of a received command is self-sufficient, e) for the management of usage commands (32) in command libraries (92), the maintenance of lock lists (88), the processing of Usage programs (93) by stepwise transfer of commands to the execution computer (2) and for external communication from the area of the device referred to here as the command computer (3), a further processor is provided if the features of c) apply, f) for the tasks An application computer area (4) is provided for the process design, insofar as it does not relate to execution or command computers.

17. The device according to claim 16, characterized in that a) for small controllers (94) with a small command range and uncritical time requirements in a control hardware module (95), the modules of the execution computer (2) and the command computer (3) are introduced with fixed command sets , b) standard switching and display devices (96) are provided for operation and communication, c) an external computer (98) can be connected via an interface (97) for introducing the control software and, if necessary, for convenient communication and diagnosis.

17 sheets of drawings