WO2001075535A2 - Zustandssteuerung von technischen systemen - Google Patents

Zustandssteuerung von technischen systemen Download PDF

Info

Publication number
WO2001075535A2
WO2001075535A2 PCT/DE2001/001331 DE0101331W WO0175535A2 WO 2001075535 A2 WO2001075535 A2 WO 2001075535A2 DE 0101331 W DE0101331 W DE 0101331W WO 0175535 A2 WO0175535 A2 WO 0175535A2
Authority
WO
WIPO (PCT)
Prior art keywords
command
state
elementary
commands
computer
Prior art date
Application number
PCT/DE2001/001331
Other languages
English (en)
French (fr)
Other versions
WO2001075535A3 (de
Inventor
Volker MÖBIUS
Knut Grossmann
Original Assignee
Technische Universität Dresden
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 Technische Universität Dresden filed Critical Technische Universität Dresden
Priority to JP2001573150A priority Critical patent/JP2003529835A/ja
Priority to US10/009,010 priority patent/US7065413B2/en
Priority to EP01931411A priority patent/EP1226473A2/de
Publication of WO2001075535A2 publication Critical patent/WO2001075535A2/de
Publication of WO2001075535A3 publication Critical patent/WO2001075535A3/de

Links

Classifications

    • 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/056—Programming the PLC
    • 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/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • 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/1171—Detect only input variation, changing, transition state of variable
    • 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/13—Plc programming
    • G05B2219/13091—Use of precalculated and stored values to speed up calculations
    • 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/13—Plc programming
    • G05B2219/13099—Function block, OOP, various functions grouped, called by name as servo

Definitions

  • 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.
  • 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.
  • Standard programming languages ladder diagram, function diagram, STL, structured text known.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • Fig. 1 shows a basic structure of the areas of responsibility in the structure of the controller
  • Fig. 4 shows a simple technical system in a schematic representation
  • FIG. 5 shows a functional structure corresponding to FIG. 4
  • FIG. 6 shows a definition of the elementary commands corresponding to FIG. 4
  • FIG. 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
  • 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
  • Fig. 15 shows an example of a formal instruction name formation base
  • Figure 16 shows an example of defining usage commands
  • FIG. 17 shows an example of a lock directory maintained in a controller
  • FIG. 20 shows a structure and name definition according to FIG. 19
  • FIGS. 19 and 20 show 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.
  • the command computer 3 all control operations are managed on a logical-functional level.
  • device-oriented elementary commands become process-related usage commands as Single commands, defined as parallel or serial command sequences, filed and called.
  • 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.
  • 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.
  • the portion of the instruction computer 3 can be assigned to the execution computer 2 as a software area.
  • 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.
  • FIG. 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.
  • 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.
  • the EF controller 22 is generated.
  • the reference state of the system is set up in the EF controller 23 from the defined reference states 18 of all elementary functions.
  • 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.
  • 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.
  • the non-target action memory 39 the components of the command set "non-target commands and messages" are entered.
  • 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.
  • 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).
  • the command starter block 35 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.
  • 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
  • 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.
  • 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a detected event calls up a corresponding action (for example the switching off of a pump when the upper fill level is reached).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the command computer 3 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.

Landscapes

  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Programmable Controllers (AREA)

Abstract

Verfahren zum Steuern von Mechanismen oder technischen Systemen, wobei die zu steuernden Mechanismen oder technischen Systeme in ihren Elementarfunktionen (8) mit deren befehlsgemäss definierten Zuständen und den zugehörigen Signalbildern der Sensoren (13) und Aktoren (12) in einer Steuerung gespeichert werden, ein den Zustand der Mechanismen oder des technischen Systems verändernder neuer Befehl mit seinem Start den Sollzustand (24) für den Vergleich aktualisiert und auf der Grundlage ebenfalls gespeicherter zulässiger Übergangszeiten die Zeit bis zur Rückmeldung des befehlsgemäßen neuen Zustandes überwacht; und wobei Sensorsignale und vergleichbare Informationen ausschließlich der Zustandsidentifikation von Elementarfunktionen (8) dienen, Zustandsänderungen ausschließlich über den Start von Elementarbefehlen (16) erfolgen, denen die Sensor- und Aktor-Signale als Sollzustand zugeordnet sind und die auf logisch-funktionellem Sprachniveau frei definierten Nutzungsbefehle (32) durch entsprechende Zuordnung von Elementarbefehlen (16) definiert sind.

Description

Verfahren zum Steuern von Mechanismen und technischen Systemen, Einrichtung und Steuerungssoftware
Beschreibung
Die Erfindung bezieht sich auf ein Nerfahren zum Steuern von Mechanismen und technischen Systemen sowie auf die dafür zu gestaltenden Einrichtungen einer elektronischen Steuerung und ein Nerfahren zur Erstellung der Steuerungssoftware.
Aus der DE 44 07 334 AI ist ein Nerfahren zum Erstellen und Darstellen von Steuerungen bekannt, mit dem sich Steuerungen auf einfache Weise graphisch entwerfen lassen. Die gewünschte Funktion der Steuerung wird als ereignisgesteuertes Netzwerk von Symbolen mit frei wählbaren Verbindungen graphisch in einen Computer eingegeben oder von einem Computer dargestellt. Das Netzwerk in maschinenlesbarer Form umgewandelt kann von dem Computer oder einem separaten Steuerungsrechner als Steuerungsprogramm verwendet werden. Das Verfahren eignet sich für speicherprogrammierbare Steuerungen sowie DDC- Anlagen.
Aus der DE 195 13 801 AI ist ein Verfahren zur automatischen Erzeugung einer Steuerung für einen Prozess bekannt, bei dem ein nicht deterministischer Automat, der alle physikalisch möglichen Verhaltensweisen der Steuerung beschreibt, festgelegt wird, bei dem die erlaubten Zu- standsübergänge des von der Steuerung zu beeinflussenden Prozesses beschrieben werden, bei dem der Automat so eingestellt wird, dass er vorgegebene Sicherheitsbedingungen erfüllt, bei dem der Automat so eingestellt wird, dass er die Funktion des aus der Steuerung und Prozess bestehenden Systems erfüllt. Das Verfahren macht von der Programmiersprache CSLxt Gebrauch, um die Komponenten der Spezifikation des Systems zu beschreiben. Für die Spezifikation des Prozessmodells werden nicht die Zustandsübergänge detailliert beschrieben, sondern sogenannte vordefinierte qualitative Constraints verwendet, die zur automatisches Generierung der Steuerung dienen.
Nachteilig ist, dass die Beschreibung von Zustandsübergängen auf einem höheren Sprachniveau fehlerhaft sein kann, und eine nachträgliche Korrektur der Steuerung nicht ohne weiteres möglich ist.
Darüber hinaus sind Speicherprogrammierbare Steuerungen SPS
Hardware-SPS
Software-SPS
Programmiersysteme und Programmiersprachen
Simatic S7
Programmierung nach IEC 1131-3 Norm
Standardprogrammiersprachen: Kontaktplan, Funktionsplan, AWL, Structured Text bekannt.
Nachteilig bei dem Stand der Technik ist, dass im Prinzip mit Boolscher Algebra Bedingungen aus Eingängen (Sensoren) für das Setzen von Ausgängen (Aktoren) formuliert werden, die ständig zyklisch neu durchgerechnet werden. Dieser Programmieransatz ist historisch entstanden. Beleg oder Indiz für diesen Zustand ist die Tatsache, dass nach der allgemein akzeptierten Norm der „Konta tplan" noch als Programmiersprache verwendet werden kann.
Trotz aller CAE-Unterstützung durch Grafikoberflächen und Hochsprachen bleiben prinzipbedingte Grundmängel, wie die Unübersichtlichkeit des Programms und dessen individuelle Prägung vom Programmierer, nie vollständige Prüfbarkeit des Programms in seiner Funktionalität, da das Ergebnis der zyklischen Berechnungen von kombinatorischen und zeitlichen Zufälligkeiten beein- flusst werden kann und die schwierige Gestaltung von difFerenzierten Fehlerreaktionen.
Die Aufgabe der Erfindung besteht darin, eine Steuerung für Mechanismen oder technische Systeme anzugeben, die die Steuerungsaufgabe ohne den Einsatz Boolscher-Algebra-Bedingungen löst, wobei ein übersichtliches Programm, frei von individueller Prägung und mit vollständiger Prüfbarkeit vorliegen soll.
Erfindungsgemäß wird die Aufgabe durch ein Verfahren mit den im Anspruchs 1 genannten Merkmalen gelöst. Die Aufgabe wird weiterhin durch ein Verfahren zur Erstellung einer Steuerungssoftware mit den im Anspruch 11 und durch eine Einrichtung mit den im Anspruch 16 aufgeführten Merkmalen gelöst.
Vorteilhafte Ausgestaltungen und Weiterbildungen sind Gegenstand zugehöriger Unteransprüche. Das Wesen der Erfindung besteht darin, dass abgeleitet von der Funktionalität des zu steuernden Mechanismus oder technischen Systems, insbesondere mit dessen Entwicklung, mit technischen Mitteln die Funktionalität der zu steuernden Einrichtung in einem als Steuerung gestalteten Steuerungscomputer als ein vollständiges Abbild des befehlsgemäßen Sollzustand des Systems abgelegt, verwaltet und aktualisiert wird und ein Vergleich dieses Sollzustandes über die gemeldeten Sensorsignale mit dem Ist-Zustand der technischen Einrichtung erfolgt. Dieser Soll-Ist- Vergleich erfolgt ständig für alle Sensorsignale des zu steuernden Systems. Bei Abweichungen des Ist- Zustandes zum Sollzustand werden vorbereitete Algorithmen abgearbeitet und ebenso vorbereitete zweckmäßige Entscheidungen aktiviert. Jedes Sensorsignal wird damit nur mit genau einem Sollsignal verglichen und dieser Vergleich dient ausschließlich der Zustandsidentifikation des technischen Systems. Zustandsänderungen erfolgen ausschließlich über Befehle auf sprachlich- funktionellem Niveau. Diese Befehle werden in einem besonderen Bereich der Steuerung verwaltet, bei Start eines Befehls wird der Sollzustand im Abbild aktualisiert und die dem Befehl entsprechende Änderung des Ist-Zustandes des technischen Systems innerhalb einer vorgegebenen Zeit kontrolliert.
Die zu steuernden Einrichtungen sind in ihren Elementarfunktionen mit deren befehlsgemäß definierten Zuständen und den zugehörigen Signalbildern der Sensoren und Aktoren in der Steuerung gespeichert, wobei ausgehend von einem definierten Referenzzustand zu Beginn der Steuerungsaktivierung ein ständiger Vergleich der von der technischen Anlage durch die Sensoren gemeldeten Ist-Zustände mit dem in der Steuerung gespeicherten Sollzustand für alle Elementarfunktionen erfolgt und damit jede Abweichung im zu steuernden System vom befehlsgemäßen Sollzustand erkannt wird, wobei ein den Zustand des technischen Systems verändernder neuer Befehl mit seinem Start den Sollzustand für den Vergleich aktualisiert und auf der Grundlage ebenfalls gespeicherter zulässiger Übergangszeiten die Zeit bis zur Rückmeldung des befehlsgemäßen neuen Zu- standes überwacht, wobei Sensorsignale und vergleichbare Informationen ausschließlich der Zustandsidentifikation dienen und Zustandsänderungen ausschließlich über den Start von dafür auf logisch-funktionellem Sprachniveau frei definierten Befehlen erfolgt, denen die mit Sensor- und Aktor-Signalen definierten Elementarbefehle zugeordnet sind.
Vorteilhaft werden in einem als EF-Cόntroler bezeichneten Programmbaustein die Zustände aller Elementarfunktionen als aktueller Sollzustand mit den zugehörigen Aktoren und Sensoren geführt und damit jede über die Sensoren erkannte Zustandsänderung des technischen Systems auf Übereinstimmung mit dem in der Steuerung geführten Sollzustand bewertet.
Ein nicht dem Soll entsprechender Zustand einer Elementarfunktion des zustandsbeschreibenden Signalbildes wird vorteilhaft an einen als „Nichtsollbewerter" bezeichneten Programmbaustein übergeben, in dem für ausgewählte Zustände von Elementarfunktionen Reaktionsbefehle gespeichert sind, die bei Übereinstimmung mit dem zur Prüfung übergebenen Zustand gestartet werden, wobei in allen Fällen differenzierte Fehlermeldungen erzeugt werden.
Einem Befehl als Befehlssatz werden sowohl die neuen Sollzustände der Sensoren und Aktoren, die Übergangszeiten zum neuen Sollzustand als auch die bei Abweichungen zu startenden Reaktionsbefehle, jeweils unterschieden in vor dem Start und nach erfolgter Ausführung zu löschende und zu setzende Reaktionsbefehle auf ausgewählte Zustandsmeldungen zugeordnet, wobei vorteilhaft ein als „Befehlsaufbereiter" bezeichneter Programmbaustein die dafür erforderliche Organisation im System übernimmt und in diesem Programmbaustein auch die Freigabe eines nächsten Befehls bei Befehlsfolgen nach Erfüllungsmeldung des vorhergehenden sowie die Organisation von Parallelbefehlen durch je nach Bedarf temporäres Eröffnen von parallelen Abarbeitsfolgen realisiert wird.
Vorteilhaft werden dem organisierten Steuerungssystem Sensorsignale und weitere zu kontrollierende Informationen in einem hier als „Zustandsüberwacher" bezeichneten Programmbaustein zu einem lückenlosen Datenwort zusammengezogen, wobei den Signalen die Adresse der zugehörigen Elementarfunktion im EF-Controler zugeordnet bleibt und für den Vergleich jedem Sollsignal das Ist-Signal in gleicher Struktur gegenübersteht, was einen programmtechnisch sehr effektiven Soll-Ist- Vergleich ermöglicht, wobei eine aufgetretene Abweichung eines Signals nach der Übergabe zur Auswertung als neuer Vergleichszustand eingetragen wird und damit ein Vergleich immer zum letzten ausgewerteten Zustand erfolgt und jede Zustandsänderung damit nur einmal ausgewertet wird, wobei der Vergleich der Soll-Ist-Signale gerichtet erfolgt und nach einer Unterbrechung für die Auswertung einer Abweichung der Vergleich bei dem der Unterbrechungsstelle folgenden Signal fortgesetzt wird, wodurch gesichert ist, dass jede zeitlich hinreichend lange Zustandsänderung erfasst und ausgewertet werden kann.
Bei einem so organisierten Steuerungssystem wird jede im Programmbaustein Zustandsüberwacher erfasste Zustandsänderung in einem Ereignis-Zeit-Protokoll gespeichert, wodurch auf ein- fachstem Weg damit beschriebene Prozessparameter zugänglich werden, damit auch beispielsweise Signalschwingungen erkannt und gegebenenfalls ausgefiltert werden können.
Die den Echtzeitforderungen unterliegenden Programmbausteine Befehlsaufbereiter, EF- Controler, Zustandsüberwacher und Nichtsollbewerter werden vorteilhaft zu einer Funktionseinheit zusammengefasst, die als „Ausführungsrechner" bezeichnet wird, wozu ein spezieller Prozessor eingesetzt wird, während die nur auf logisch-fünktionellem Sprachniveau formulierten Befehle der eigentlichen Nutzungsprogramme in einer zweiten, nicht Echtzeitforderungen unterliegenden Funktionseinheit, die als „Befehlsrechner" bezeichnet wird, organisiert werden, wobei der Befehlsrechner zweckmäßigerweise bei größerem und variablen Befehlsumfang über einen eigenen Prozessor verfügt und hier auch die Kommunikation komfortabel gestaltet werden kann.
Vom Befehlsrechner an den Ausführungsrechner übergebene Befehle werden dort vorteilhaft ohne Prüfung ausgeführt, wobei der Ausführungsrechner jeweils die auszuführende Aktion autark realisiert. Deshalb werden im Befehlsrechner auf logisch-funktionellen Befehlsniveau zu den sich ausschließenden Zuständen Sperrenverzeichnisse geführt und verwaltet, die den prozess- und raa- schinenseitig determinierten Anteil von Verriegelungen übernehmen, wobei hier im Befehlsrechner mit einem Nutzungs-Prozessbefehl außer den Informationen, welche Befehle dem Ausführungsrechner zu übergeben sind, auch festgelegt wird, für welche anderen Nutzungsbefehle Sperren während oder nach der Ausführung zu setzen oder aufzuheben sind.
Der Ausführungsrechner kann einen erhaltenen Befehl autark ausführen, wobei der Befehlsrechner dem Ausführungsrechner den nächstfolgenden geprüften Befehl in einem Befehlspuffer als Zwischenspeicher bereitstellt und nach dem Bereitstellen den Zustand im Befehlsrechner auf den Stand aktualisiert, der nach der Ausführung dieses bereitgestellten Befehls eintreten wird und damit eine Prüfung des nachfolgenden Befehls im Befehlsrechner bereits während Befehlsausführung des vorhergehenden Befehls im Ausführungsrechner erfolgt und damit in der Regel ein schnellerer Programmablauf realisiert werden kann. Nicht verträgliche Befehle werden bereits im Befehlsrechner als nicht zulässig erkannt und ausgewiesen und es erfolgt kein Start eines solchen Befehls. Ist der vorbereitete Befehl zulässig, tritt bei fehlerfreier Ausführung der für die Prüfung des Befehls im Befehlsrechner erwartete Zustand ein und der Ablauf wird fortgesetzt, während bei einem Fehler ein Rücksetzen auf den Zustand zum laufenden Befehl als Fehlerzustand vorgenommen wird. Der Anwender dieser Steuerung wird bei der Erstellung eines Steuerungsprogramms vorteilhaft durch ein Entwicklungsprogramm dialoggeführt unterstützt, wobei die erste Beschreibung des zu steuernden Systems die Angabe der hierarchischen Funktionsstruktur des Systems verlangt, das jeweils untere Ende dieser Struktur als Elementarfünktion betrachtet wird und jede Elementarfunktion ebenfalls im Dialog in ihren Befehlszuständen zu definieren ist und diesen definierten Befehlen die Sensorsignale, die Aktoren, die Kontrollzeiten für den Übergang zwischen den befehlsgemäßen Zuständen und ein Referenzzustand für den Beginn zuzuordnen sind, gleichermaßen die Definition der Einbindung komplexerer Teilsysteme erfolgen kann, wobei der Anwender des Steuerungssystems nur die hier genannten primären Angaben macht und das Steuerungs- Entwicklungsprogramm daraus den System-Elementarfünktionsspeicher, den EF-Controler und den Signal- Vektor für den Zustandsüberwacher generiert und damit das technische System bereits inbetriebgenommen. auf fehlerfreie Signaldefinition im Referenzzustand überprüft, mit den definierten Elementarfunktionen gesteuert und soweit zulässig in Einzelbefehlen getestet und geprüft werden kann.
Für ein solches dialoggestütztes System werden die Nutzungsbefehle vorteilhaft derart erarbeitet, indem in einer Befehlsbibliothek prozessnah zu definierenden Nutzungsbefehlen aus den vorher definierten Elementarbefehlen solche einzeln, parallel oder als Folge zugeordnet werden, dazu die Sperrbedingungen auf Befehlsniveau im Befehlsrechner und für den an den Ausführungsrechner zu übergebenden Befehlssatz auch die in den Nichtsollbewerter einzutragenden Reaktionsbefehle auf ausgewählte Abweichungen, verbunden mit geeigneten Fehlermeldungen, festgelegt werden.
Für ein so aufgebautes Steuerungssystem bleiben Änderungen an Elementarfunktionen lokal begrenzt. Es können jederzeit und ebenfalls mit überschaubarer lokaler Wirkung neue Nutzungsbefehle, Sperrbedingungen oder Fehlerreaktionen erweitert oder geändert werden oder ohne jede Rückwirkung auf schon definierte Programme, dazu unterschieden durch die Vergabe von Statu- sinformationen für das System, eine neue Zuordnung von Befehlen und Befehlsbedingungen erfolgen.
Jedes so erstellte Programm ist in seiner logisch-fünktionellen Struktur vollständig prüfbar. Über das Ereignis-Zeit-Protokoll werden wichtige zusätzliche Prozessinformationen zugänglich, zu jeder Störung ist ohne zusätzliche Maßnahmen stets eine eindeutige Ursache diagnostiziert, der Systemzustand kann zu jeder Zeit vollständig und definiert ausgewiesen werden, eine gleichermaßen zum Zustand des zu steuernden Systems aussagefähige Kopie kann an einem zur Anlage ver- netzten externen Steuerungscomputer geführt werden, die Elementarfunktionen und die definierten Befehle können direkt als funktioneile Basis für eine Visualisierung der zu steuernden Systeme und Prozesse dienen und in einfacher Weise kann die Kommunikation des Steuerprogramms mit anderen intelligenten Programmmodulen, wie beispielsweise Simulationen zur Prozessoptimierung, organisiert werden.
Für Kleinsteuerungen mit einem begrenzten Befehlsumfang können bei grundsätzlich gleichem Aufbau und gleicher Arbeitsweise der Steuerung in einem Steuerungs-Hardwarebaustein die Module des Ausführungsrechners und des Befehlsrechners mit festen Befehlssätzen eingebracht werden, die mit einfachen Bedienelementen aufgerufen werden, wobei über eine geeignete Schnittstelle ein externer Computer angekoppelt werden kann, womit das Einbringen der Steuerungssoftware und im Bedarfsfall auch eine komfortable Kommunikation und Diagnose realisierbar sind und damit vergleichbare Steuerungseigenschaften und vergleichbarer Komfort bei geringen Kosten erreicht werden.
Die erfindungsgemäße Lösung vermeidet die Mängel nach dem Stand der Technik durch einen bisher unüblichen Programmieransatz, der von der gestalteten und damit eingeprägten Funktionalität des Systems Gebrauch macht. Eine Signalverknüpfung mit Boolscher Algebra in Bedingungsgleichungen für das Setzen von Ausgängen wird vollständig durch neue Mittel ersetzt.
Nachfolgend wird die Erfindung an Hand von Ausführungsbeispielen näher erläutert. In den Zeichnungen zeigen:
Fig. 1 eine Darstellung einer grundlegenden Gliederung der Aufgabenbereiche in der Struktur der Steuerung
Fig. 2 eine hierarchisch gegliederte Funktionsstruktur eines technischen Systems
Fig. 3 für die Elementarfunktionen festzulegende Informationen an einem allgemeinen Beispiel
Fig. 4 eine einfache technische Anlage in schematischer Darstellung
Fig. 5 eine der Fig. 4 entsprechende Funktionsstruktur
Fig. 6 eine der Fig. 4 entsprechende Definition der Elementarbefehle
Fig. 7 eine Darstellung von Eingabe und Aufbau eines Datengerüsts zur Realisierung der Steuerung Fig. 8 einen Aufbau eines Ausführungsrechners
Fig. 9 einen Inhalt eines Befehls als Befehlssatz für den Befehlspuffer
Fig. 10 eine Darstellung der Arbeitsweise eines Befehlsstarters
Fig. 11 eine Darstellung der Arbeitsweise eines EF-Controlers
Fig. 12 eine Darstellung der Arbeitsweise eines Nichtsoll-Bewerters
Fig. 13 eine Darstellung der Arbeitsweise eines Zustandsüberwachers
Fig. 14 einen Aufbau eines Ereignis-Zeit-Protokolls
Fig. 15 ein Beispiel einer Bildungsgrundlage formaler Befehlsnamen
Fig. 16 ein Beispiel für das Definieren von Nutzungsbefehlen
Fig. 17 ein Beispiel eines in einer Steuerung geführten Sperrenverzeichnisses
Fig. 18 ein Beispiel zur Festlegung von Fehlerbefehlen
Fig. 19 ein Beispiel einer Steuerung mit komplexeren Aufgaben
Fig. 20 eine Struktur und Namensdefinition nach Fig. 19
Fig. 21 alle Angaben für eine Befehlsbibliothek eines Befehlsrechner nach Fig. 19 und 20
Fig. 22 Merkmale einer Ausführung als Kleinsteuerung
Fig. 1 zeigt die grundlegende Gliederung der Aufgabenbereiche in der Struktur 1 der neuen Steuerung. Dem Ausführungsrechner 2 sind die zeitkritischen Aufgaben Soll-Ist- Vergleich, Reaktionen auf Abweichungen des Ist- zum Soll-Zustand und der befehlsgemäße Aufruf von zustand- sändernden Aktoren zugeordnet. Vom Befehlsrechner 3 erhaltene Befehle werden vom Ausführungsrechner 2 ohne Prüfung umgesetzt, wobei die Ausführung eines Befehls und die Reaktion auf Abweichungen des Soll-Ist-Zustandes autark vom Ausführungsrechner 2 realisiert werden. Es ist zweckmäßig bzw. für kürzeste Reaktionszeiten der Steuerung bei komplexeren Systemen zwingend, dem Ausführungsrechner 2 eine eigene Hardware mit einem eigenen Prozessor zuzuordnen.
Im Befehlsrechner 3 werden alle Steuerungsoperationen auf logisch-funktionellem Niveau verwaltet. Hier werden aus geräteorientierten Elementarbefehlen prozessnahe Nutzungsbefehle als Einzelbefehle, als parallele oder serielle Befehlsfolgen definiert, abgelegt und aufgerufen. Hier erfolgt auch auf logischem Befehlsniveau die Verwaltung von Sperren für sich gegenseitig ausschließende Zustände als Alternative zu bisherigen Verriegelungen und Bedingungsformulierungen über Boolsche Signalverknüpfungen. Dem Anwendungsrechner 4 obüegen in diesem Steuerungskonzept alle Aufgaben, die nicht dem Ausführungs- oder dem Befehlsrechner zugeordnet sind. Das betrifft vor allem prozessnahe Probleme, wie sie beispielsweise im Bereich der Werkstückprogrammierung einer CNC-Steuerung vorliegen.
Die Steuerung kann dabei für unterschiedlichen Umfang und unterschiedliche Aufgabenkomplexität angemessen konfiguriert werden, wobei für alle Konfigurationen gleiche Prinzipien im Entwicklungssystem gelten. Bei sehr geringem Umfang an Befehlen kann der Anteil des Befehlsrechners 3 dem Ausführungsrechner 2 als Softwarebereich zugeordnet sein. Bei heute typischen SPS- Aufgaben kämen Ausführungs- und Befehlsrechner mit eigenen Prozessoren zur Anwendung, wobei die Systembedienung sowohl über Bedien- und Signalelemente bis zur Monitorausstattung erfolgen kann. In allen Ausführungen ist es darüber hinaus möglich, über eine einfach zu gestal- tende Schnittstelle ein komfortables Kommunikationssystem - beispielsweise einen transportablen Computer - anzukoppeln und damit Programmierung und Inbetriebnahme oder Diagnose im Fehlerfall auszuführen.
Fig. 2 zeigt beispielhaft die hierarchisch gegliederte Funktionsstruktur 5 eines technischen Systems. Es ist entwicklungsmethodisch begründet, dass eine solche Systemstruktur von der Funktionseinheit für das Gesamtsystem 6 über unterschiedliche Funktionseinheiten der Teilsysteme 7 bis zu den Funktionseinheiten Elementarfunktionen 8 spezifisch für jedes technische System aufgestellt werden kann. Die Endzweige dieser Baumstruktur stellen im Sinne der neuen Steuerung Elementarfunktionen dar, die dadurch charakterisiert sind, dass diese Funktionseinheiten unterschiedliche Zustände einnehmen können und sich nicht zweckmäßig weiter untergliedern lassen, deren steuerungsseitig interessierende Funktionszustände also nicht mehr eine Repräsentation kombinierter Zustände anderer elementarer und zu steuernder Funktionsgruppen sind, wie es für übergeordnete nicht elementare Funktionseinheiten 6 und 7 in der Struktur charakteristisch ist. Entscheidend ist dabei die Stellung im zu steuernden System, so dass auch ein durch wenige elementare Befehle eingebundenes intelligentes Teilsystem als Elementarfünktion eingeordnet wird. Fig. 3 beschreibt an einem allgemeinen Beispiel die für Elementarfunktionen festzulegenden Informationen in einem „Datenblatt zu Elementarfunktionen" 9. In 10 wird der Name für die Ele- mentarfünktion festgelegt, der diese Elementarfünktion identifiziert. Zweckmäßigerweise zeigt eine Funktionsskizze 11 die Merkmale der Zustände der Elementarfunktion mit der Zuordnung von Aktoren 12 und Sensoren 13. In dem gekennzeichneten Bereich für die Zustandsdefinitionen 14 werden die für die Steuerung notwendigen Informationen datenverarbeitungsgerecht systematisiert und definiert. Die Zustandsdefinitionen 14 zeigen die Zustände, die die Elementarfünktion einnehmen kann und die Definition der den Zuständen zugeordneten Signalvektoren 15 für die Aktoren 12 und Sensoren 13. Gleichermaßen werden hier die Befehle 16 definiert, die einen Übergang in einen bestimmten Zustand auslösen. Für jeden dieser Übergänge wird eine Kontrollzeit 17 vorgegeben, die in der Regel ein mehrfaches der wahrscheinlichen Funktionszeit sein kann und nur für das Erkennen von Ausführungsfehlern bei Nichterreichen des befohlenen Zustandes verwendet wird. Mit der Markierung wird von den möglichen Zuständen einer als Referenzzustand 18 festgelegt.
Fig. 4 zeigt eine einfache technische Anlage, für die in Fig. 5 die Funktionsstruktur und in Fig. 6 die Definition der Elementarbefehle dargestellt sind.
Die hier beschriebene hierarchische Funktionsstruktur und die Definition der zugehörigen Elementarfunktionen sind vom Wesen her primäre Entwicklungsinhalte, die mit nur geringem zusätzlichem Aufwand und bereits in einer relativ frühen Phase bei der Produktentwicklung dokumentiert werden können.
Fig. 7 zeigt Eingabe und Aufbau des Datengerüsts bei der Anwendung der neuen Steuerung. Die Editierebene 19 beinhaltet die beiden Hauptbestandteile hierarchische Funktionsstruktur 5 und die Datenblätter der Elementarfunktionen 9. Jede Funktionseinheit Elementarfunktion 8 in der Struktur muss mit einem entsprechenden Datenblatt zu Elementarfunktionen 9 beschrieben sein. Diese Vollständigkeit der Angaben und deren formale Korrektheit wird in der Editierebene automatisch geprüft. Bei positivem Prüfergebnis und Bestätigung des Nutzers für den Abschluss der Systembeschreibung wird die Eingabe geschlossen und aus den vorliegenden Angaben die Datenbasis der Steuerung für das beschriebene System generiert. Als erster Schritt erfolgt das Generieren des Elementarfünktions-Speichers 20. Dieser Elementarfünktions-Speicher 21 enthält alle Elementarbefehle des Systems, alle Systemzustände und die dazu festgelegten Informationen, wie sie mit Fig. 3 beschrieben wurden. Die formalen Namen der Elementarfunktionen werden aus der Struktur abgeleitet, so dass Elementarfunktionen auch bei Verwendung eines gleichen Datenblattes einen unverwechselbaren Namen erhalten. Im zweiten Schritt erfolgt das Generieren des EF- Controlers 22. Dazu wird im EF-Controler 23 der Referenzzustand des Systems aus den festgelegten Referenzzuständen 18 aller Elementarfunktionen aufgebaut. Für den hier ebenfalls geführten Istzustand der Elementarfunktionen wird durch Doppeln der Datenstruktur des Soll-Zustandes der Elementarfunktionen 24 die Datenstruktur zum Speichern des Istzustandes der Elementarfunktionen 25 angelegt. Es wäre damit hier bereits möglich, beim Betreiben der Steuerung einen Vergleich zwischen dem Soll- und dem Ist-Zustand der Sensoren der Elementarfunktionen vorzunehmen. Größere Effektivität ermöglicht aber der mit 26 gekennzeichnete dritte Schritt zum Generieren des (ebenfalls später noch genauer beschriebenen) Zustandsüberwachers 27. Dabei werden aus den Soll-Signalvektoren der Elementarfunktionen 28 und gleichermaßen aus den Ist- Signalvektoren der Elementarfunktionen 29 der Sollsignalvektor des Systems 30 und der Istsignalvektor des Systems 31 gebildet. Jedem Sensor im System-Signalvektor bleibt seine Herkunftsadresse als Name der Elementarfünktion 10 im EF-Controler 23 zugeordnet.
Fig. 8 zeigt den Aufbau des Ausführungsrechners 2 und das Zusammenwirken mit dem Befehlsrechner 3. Der Ausführungsrechner 2 erhält vom Befehlsrechner 3 einen auszuführenden Nutzungsbefehl 32. Dieser wird in einem Baustein Befehlsaufbereiter 33 decodiert. Dabei werden Nutzungsbefehle in ihre entsprechenden Elementarbefehle überführt und diesen wird aus dem Elementarfunktions-Speicher 21 der vollständige zugeordnete Informationsinhalt des Befehlssatzes übergeben. Dieser Befehlssatz wird in dem Befehlspuffer 34 des Ausführungsrechners eingetragen. Nach Quittung, dass der vorhergehende Befehl abgeschlossen wurde, startet der Baustein Befehlsstarter 35 den im Befehlspuffer 34 wartenden Befehl und führt alle damit verbundenen Aktivitäten aus. Das betrifft das Aktualisieren im Baustein EF-Controler 36, im Baustein Zustandsüberwacher 37 und im Baustein Nichtsoll-Bewerter 38. Vom Baustein Befehlsstarter 35 wird im Baustein EF-Controler 36 für die betreffende Elementarfunktion der neue Sollzustand für die Sensoren eingetragen und durch das befehlsgemäße Setzen der Ausgänge der entsprechende Aktorbefehl gestartet. Ebenso wird die der Befehlsausführung zugeordnete Kontrollzeit 17 gestartet. Im Nichtsoll-Aktionsspeicher 39 werden die Bestandteile des Befehlssatzes „Nichtsoll- Befehle und -Meldungen" eingetragen. Nach Ausführung der Start-Aktivitäten vom Befehlsstarter 35 übernimmt der Baustein Zustandsüberwacher 37 wieder den Vergleich des Soll-Signalvektors des Systems 30 mit dem Ist- Signalvektor des Systems 31. Bei einer in diesem Vergleich erkannten Abweichung zwischen Soll und Ist wird im EF-Controler 36 der Ist-Zustand des abweichenden Signals im Ist-Signalvektor der Elementarfunktion 29 aktualisiert. Im EF-Controler 36 erfolgt die Bewertung der Abweichung (in Fig. 11 näher beschrieben), entweder a) ohne weitere Reaktion durch den über das laufende Zeitglied erkannten Status „beim Ändern" und damit Rückgabe der Aktivitäten an den Baustein Zustandsüberwacher 37, b) über das Erkennen eines ausgeführten Befehls bei Übereinstimmung von Sollsignalvektor der Elementarfunktion 28 und Ist -Signalvektor der Elementarfunktion 29 im EF-Controler 36 und damit Aufruf des Bausteines Befehlstarter 35, oder - wenn beides nicht zutrifft - c) die Übergabe des Ist-Signalvektors der Elementarfunktion 29 an den Baustein Nichtsoll-Bewerter 38. Dort wird dieser Ist-Signalvektor 29 mit den im Nichtsoll-Aktionsspeicher 39 stehenden Signal vektoren verglichen und bei Übereinstimmung der diesem Fall zugeordnete Nichtsoll-Befehl 40 über den Baustein Befehlsstarter 35 gestartet. Gibt es keine Übereinstimmung, erfolgt eine Rückkehr zum Zustandsüberwacher 37. In allen Fällen wird eine entsprechende Meldung 41 erzeugt. Der mit 42 gekennzeichnete Bereich markiert die zeitkritischen Aktivitäten.
Fig. 9 zeigt den Inhalt eines Befehls 43, wie er als Befehlssatz in den Befehlspuffer 34 des Ausführungsrechners 2 eingetragen wird. Zeile (1) enthält die Bezeichnung der zur Änderung angewiesenen Elementarfunktion 10, Zeile (2) und Zeile (3) beinhalten den neuen Sollzustand der Sensoren bzw. der Aktoren und damit den Soll-Signalvektor der Elementarfünktion 28, Zeile (4) gibt die Kontrollzeit 17 vor, in der die Änderung des Zustandes auf die neue Vorgabe erfolgt sein muss, Zeile (5) beinhaltet die Angaben zur Aktualisierung der ab Start des Befehls geltenden Einträge im Nichtsoll-Aktionsspeicher 39 für Reaktionen mit Nichtsoll-Befehlen 40, und Zeile (6) beinhaltet gleiches für die Aktualisierung nach erfolgreicher Befehlsausführung. Die Angaben der Zeilen (1) bis (4) entsprechen dabei direkt den Definitionen aus der Editierebene 19 zu den Elementarfunktionen 8. Die Zeilen (5) und (6) können darüber hinaus Nichtsoll-Befehle 40 aus Festlegungen zu prozessbezogenen Vorgaben über die Nutzungsbefehle 32 beinhalten.
Fig. 10 beschreibt die Arbeitsweise des Bausteins Befehlsstarter 35 und die Behandlung von Folgebefehlen 44 sowie von Parallelbefehlen 45. Der Befehlspuffer 34 wird vom Befehlsrechner 3 immer mit dem der laufenden Befehlsausführung folgenden Befehl geladen. Definierte Befehlsfol- gen (=Folgebefehle 44) unterscheiden sich dabei nicht von einzeln definierten, voneinander unabhängigen Befehlen.
Parallelbefehle 45 sind dadurch charakterisiert, dass sie fünktionell wie zeitlich voneinander unabhängig ausgefiihrt werden können und für einen zeitlich optimalen Ablauf auch parallel ausgeführt werden müssen. Für jeden als parallel definierten Befehl wird deshalb ein eigener Befehlspuffer 46 an der Schnittstelle zwischen Befehlsrechner 3 und Ausführungsrechner 2 definiert, aus dem voneinander unabhängige parallele Befehlsfolgen 45 abgearbeitet werden können. Stehen nach Abarbeitung von Parallelbefehlen 45 keine solchen mehr an, werden die eröffneten Speicherbereiche wieder geschlossen, so dass nur aktuell benötigte Pufferspeicher 46 geführt werden. Fig. 10 zeigt ein Beispiel für drei eröffnete Parallelbefehle 45, aus denen nacheinander die eingetragenen Befehle 43 gestartet werden. Sollte die Prüfung 47 zeigen, dass kein weiterer Befehl im Speicherpuffer ansteht, wird der entsprechende Parallel-Befehlspuffer 46 geschlossen und der Baustein Zustandsüberwacher 37 aufgerufen. Bei positivem Prüfergebnis 48 wird entsprechend Befehlsinhalt 43 aktualisiert und gestartet. Nach Abschluss dieser Operationen wird der Baustein EF- Controler 36 aktiviert 49. Nach dem Erreichen des befehlsgemäßen Zustandes 50 werden vom Befehlsstarter 35 die dafür im Befehlssatz 43 festgelegten Aktualisierungen ausgeführt und danach der nächste Befehl ermittelt und gestartet.
Fig. 11 zeigt die Arbeitsweise des Bausteins EF-Controler 36. Der Start 51 für eine Aktivität des EF-Controlers wird stets von einer aktuellen Änderung angestoßen. Das ist entweder ein neuer Sollsignalvektor einer Elementarfünktion 28, den der Baustein Befehlsstarter 35 bei einem neuen Befehl einträgt 52, oder eine vom Baustein Zustandsüberwacher vorgenommene Aktualisierung 53 des vorliegenden Ist-Zustandes 29. Die erste Prüfung 54 vergleicht den Soll- mit dem Ist- Zustand. Bei Übereinstimmung wird geprüft, ob der Änderungsstatus 55 gesetzt war. Ist das der Fall 56, wurde ein laufender Befehl abgeschlossen, andernfalls 57 wurde der befohlene Zustand nach einer fehlerhaften Abweichung wieder erreicht. In beiden Fällen wird eine entsprechende Meldung erzeugt und der Baustein Befehlsstarter 35 gestartet 58 - Stimmen Ist- und Sollzustand nicht überein, wird der Zweig 59 abgearbeitet. Wieder wird der Änderungsstatus geprüft 60. Liegt der Änderungsstatus bei dieser Elementarfunktion vor 61, wird die Meldung „EF beim Ändern" 62 erzeugt und der Baustein Zustandsüberwacher 37 gestartet. Liegt jedoch kein Änderungsstatus vor 63, werden der Name und der vorliegende Nichtsoll-Istsignalvektor 64 der Elementarfünkti- on in den Auswertungsspeicher des Nichtsoll-Bewerters 65 eingetragen und der Nichtsoll- Bewerter 38 wird gestartet.
Fig. 12 zeigt die Arbeitsweise des Nichtsoll-Bewerters 38. Der Start 66 des Nichtsoll-Bewerters wird durch den EF-Controler 36 nach Übergabe eines Nichtsoll-Signalvektors 64 ausgelöst. Im ersten Schritt wird geprüft, ob unter dem Namen der Elementarfünktion 10 Eintragungen im Nichtsoll-Aktionsspeicher 39 vorhanden sind. (Wie schon bei Fig. 10 beschrieben, werden diese Einträge vom Befehlsstarter 35 als Informationsbestandteile eines Befehls 43 aktualisiert.) Sind für die Elementarfunktion keine Festlegungen im Nichtsoll-Aktionsspeicher 39 enthalten 67, wird nur eine Fehlermeldung 67a mit der Bezeichnung der Elementarfünktion und dem Nichtsoll- Istsignalvektor 64 mit Kennzeichnung des fehlerhaften Signals an die übergeordnete Steuerungsebene - dem Befehlsrechner 3 - zur Auswertung übergeben. Dann wird der Baustein Zustandsüberwacher 37 wieder gestartet.
Liegt im Nichtsoll-Aktionsspeicher 39 ein NichtsoU-Signalvektor zu der Elementarfünktion vor 68, wird als nächster Schritt der Nichtsoll-Istsignalvektor 64 auf Übereinstimmung mit dem gespeicherten Signalvektor verglichen 69. Liegt keine Übereinstimmung vor 70, wird wieder nur eine konkrete Fehlermeldung 67 erzeugt und ebenso der Zustandsüberwacher 37 wieder gestartet. - Liegt jedoch eine Übereinstimmung des Signalvektors mit Eintragungen im Aktionsspeicher vor 71, werden für diesen Fall festgelegten Reaktionsbefehle 72 dem Befehlsstarter 35 zur sofortigen Ausführung übergeben. Parallel dazu wird für die zu erzeugenden Meldung geprüft 73, ob eine Ereignissteuerung 74 vorliegt. Bei einer Ereignissteuerung 74 bewegt sich das System in dem normalen fünktionellen Rahmen, ein erkanntes Ereignis ruft eine entsprechende Aktion auf (beispielsweise das Abschalten einer Pumpe bei Erreichen des oberen Füllstandes). In diesem Fall weist die entsprechende Meldung 75 den Ereignisbefehl der Elementarfunktion 76 in deutlicher Unterscheidung zu Fehlerzuständen aus. Handelt es sich nicht um eine Ereignissteuerung 77, wird eine entsprechende Fehlermeldung 78 erzeugt.
Fig. 13 zeigt Arbeitsweise und Merkmale des Bausteins Zustandsüberwacher 37. Wenn keine anderen Baustein- Aktivitäten laufen, startet der Zustandsüberwacher ständig den Vergleich 80 des Sollsignalvektors 30 und des Istsignalvektors 31 des Systems. Dieser Vergleich erfasst immer den gesamten System-Signalvektor und wird bei Übereinstimmung der verglichenen Zustände ständig wiederholt 81. Bei einer erkannten Abweichung wird zunächst geprüft, ob das System den Warte- zustand verlassen und einen neuen Befehl ausführen soll. Ist das der Fall 82, wird der Baustein Befehlsstarter 35 gestartet. Im anderen Fall wird das abweichende Ist-Signal in den Ist- Signalvektor der betreffenden Elementarfünktion im EF-Controler eingetragen 83 und dort - wie zu Fig. 11 erläutert - ausgewertet. Entstehen kann eine Abweichung entweder durch Vorgabe eines neuen Sollzustandes bei Start eines neuen Befehls und erfolgtem Eintrag in den Sollsignalvektor 30 des Systems durch den EF-Controler 36, oder im anderen Fall durch ein geändertes Sensorsignal im Istsignalvektor 31 des Systems. Nach dem Eintrag des abweichenden Ist-Signals in der betroffenen Elementarfünktion im EF-Controler wird dieser gemeldete Ist-Zustand als neuer Vergleichszustand in dem Soll- Vergleichsvektor eingetragen 84. Damit wird erreicht, dass jede Veränderung nur einmal ausgewertet wird. Der Soll- Vergleichszustand des System-Signalvektors ist damit als Vergleich mit „dem letzten ausgewerteten Zustand" des Systems 84 definiert. Damit ist es möglich und sinnvoll, das erkannte Ereignis in ein Ereignis-Zeit-Protokoll einzutragen 85, auf das in Fig. 14 näher eingegangen wird. Nach den genannten Aktionen des Zustandsüberwa- chers 37 startet dieser den Baustein EF-Controler 36. Nach erfolgter Auswertung wird wieder - wie bei der Arbeitsweise von EF-Controler bzw. Befehlsstarter beschrieben - der Baustein Zustandsüberwacher aufgerufen. Dieser setzt dann den Soll-Ist- Vergleich im Systemsignalvektor bei dem Signal fort, das dem zuletzt nicht übereinstimmenden Signal folgt. Damit wird gesichert, dass nacheinander alle Signale des Systemsignalvektors verglichen werden und nicht ein schwingendes Signal eine Endlosschleife verursachen kann. Ein solches Phänomen wäre bei Wiederaufnahme des Vergleiches bei dem gerade ausgewerteten Signal denkbar, wenn dieses Signal seinen Zustand im Takt der Signallaufzeit ändern würde.
Fig. 14 soll den Aufbau eines Ereignis-Zeit-Protokolls 85 in Form einer Liste verdeutlichen. Die erste Spalte nimmt die Bezeichnung der vom Ereignis betroffenen Elementarfünktion auf, die Spalte 2 das von der Änderung betroffenen Signal, die Spalte 3 den geänderten Signalzustand. Das sind Kopien der Informationen, die der Zustandsüberwacher dem EF-Controler übergibt. Wird in Spalte 4 die aktuelle Systemzeit beim Erkennen des Ereignisses eingetragen, entsteht ein in vielfacher Hinsicht nutzbares Ablaufprotokoll. Im Beispiel ist mit dem ersten und dem letzten Eintrag markiert, dass die Elementarfünktion Al l mit dem Signal El wieder den ersten Zustand erreicht hat. Die den Ereignissen zugeordneten Zeiten könnten gegebenenfalls als genaues Maß für eine solche Periode dienen. Mit diesem Protokoll ist es auch möglich, Signalschwingungen zu erkennen und im Bedarfsfall Filter zu aktivieren, die beispielsweise die Abtasthäufigkeit für das schwingende Signal verringern können. Je nach Prozess und Bedeutung der Informationen sowie zur Verfügung stehendem Speicher können längere Zeiten erfasst und gespeichert werden, was für Diagnosezwecke hinsichtlich Langzeitveränderungen genutzt werden kann, oder nur mit fest begrenztem Speicher der jeweils letzte Abschnitt beispielsweise für eine Havarieauswertung zur Verfügung stehen.
Fig. 15 zeigt für das in Fig. 4 bis 6 ausgeführte Beispiel die Bildungsgrundlage der formalen Befehlsnamen 86, die aus der Funktionsstruktur 5 abgeleitet werden und für eine eindeutige Bezeichnung der Elementarfunktionen in Nutzungsbefehlen verwendet werden können.
In Fig. 16. ist an dem Anwendungsbeispiel von Fig. 4 - 6 das Definieren von Nutzungsbefehlen und das Festlegen von Befehlssperren 88 zu den Nutzungsbefehlen dargestellt.
Fig. 17 zeigt als Beispiel das in der Steuerung geführte Sperrenverzeichnis 89 des Systems Schließanlage und soll das dynamische Wirken der in Fig. 16 festgelegten Sperrbedingungen deutlich machen. Bei der Fig. 17 muss betont werden, dass es eine Hilfs-Darstellung ist und eine solche Tabelle in der Steuerung nicht existiert. Vorhanden ist immer nur ein Speicherbereich, in den zu unterschiedlichen Zeiten (hier mit tl bis t8 ausgewiesen) durch die bis dahin wirkenden Befehle unterschiedliche Bedingungen eingetragen sind.
In der Spalte 1 sind alle Befehle des Systems aufgelistet. Enthält ein aktivierter Nutzungsbefehl eine Sperrbedingung für einen anderen Befehl, wird der verursachende Befehl als Sperrbedingung bei dem anderen Befehl eingetragen. Hier im Beispiel sperrt mit seiner Aktivierung zur Zeit t7 der Befehl EF2-B2 (verriegeln) den Befehl EF1-B1 (Türbeweger öffnen). Der Riegel soll - wie festgelegt - nur bei geschlossener Tür eingelegt werden können, deshalb der Eintrag der Sperre bei EF2-B2 mit Erteilen des Befehls „(Tür öffnen) EF1-B1" zur Zeit t3.
Für die Wirkungsweise der Steuerung ist wichtig, dass der Befehlsrechner 3 nach Übergabe eines Nutzungsbefehls 32 in den Befehlspuffer 34 des Ausführungsrechner 2 - den dieser dann wie beschrieben autark ausführen kann - seinen Zustand so aktualisiert, wie er nach ordnungsgemäßer Ausführung dieses Befehls eintreten wird. Für diesen Zustand wird die Zulässigkeit des nächsten Befehls noch während der Ausführung des vorhergehenden Befehls geprüft und ggf. freigegeben. Im Beispiel befindet sich während der Ausführung „Riegelschloss entriegeln" zu tl im Befehlspuffer, der Befehl „Tür öffnen", der zum Zeitpunkt t3 gestartet werden wird und dann gleichzeitig die Prüfung des Befehls „Tür schließen" für den Zeitpunkt t5 nach den Bedingungen vom Zeitpunkt t4 aktiviert.
Damit wird zeitoptimal erreicht, dass mit dem Abschluss eines Befehls sofort der schon geprüfte Folgebefehl starten kann oder gleichermaßen noch während der Laufzeit eines Befehls erkannt wird, dass der nächste vorbereitete Befehl für den kommenden Systemzustand nicht zulässig ist. Wenn ein Fehler bei dem im Ausführungsrechner laufenden Befehl auftritt, wird der Befehlsrechner auf den Fehlerzustand aktualisiert zurückgesetzt.
Fig. 18 (auf Blatt 12) soll ein Beispiel zur Festlegung von Fehlerbefehlen zeigen. Es sei als kritisch angenommen, wenn die Tür beim Schließen - aus welchen Gründen auch immer - auf einen eingelegten Riegel trifft. Fig. 18 zeigt die Formulierung eines Fehlerbefehls als Bestandteil des Befehlssatzes „Türbeweger schließen". Aus dem Zustand der Elementarfünktion Riegelschloss El=l wird „Riegel nicht frei" geschlussfolgert und als Fehlerreaktion im Nichtsollbewerter der Vorgang „Tür schließen" „in Tür öffnen" umgesteuert.
Analysen zeigen, dass in der Regel zu einem bestimmten Zeitpunkt nur wenige Fehlerbefehle benötigt werden. Grundsätzlich ist es möglich, auf ein beliebiges Ereignis mit jedem Befehl zu reagieren.
Fig. 19 soll als weiteres Beispiel die Möglichkeiten der Steuerung bei komplexeren Aufgaben und unterschiedlichen Nutzungsanforderungen einer -Anlage zeigen. Für solche unterschiedlichen Nutzungsanforderungen und daraus resultierende unterschiedliche Befehls- und Sperrbedingungen in einer Anlage soll der Begriff „Status" 90 verwendet werden.
Es sei angenommen, dass zwei Türanlagen gesteuert werden sollen, die einzeln dem bisherigen Beispiel gleich sind. Hinzu kommt ein Anlagenschalter für den jeweils gewünschten Betriebsstatus: im Status Sl können die Türen unabhängig voneinander bedient werden, in S2 werden beide synchron geöffnet oder geschlossen und in S3 als Schleuse bleibt immer eine von beiden Türen geschlossen.
Figur 20 zeigt die Struktur und Namensdefinitionen, wie sie die Steuerung hier nach den in der Editierebene 19 gemachten Angaben aufbaut.
Figur 21 zeigt alle Angaben für die Befehlsbibliothek 92 des Befehlsrechners, um die gestellte Aufgabe zu lösen. Die für die Schließanlage einer Tür erarbeiteten Festlegungen werden für die unmittelbare Türsteuerung eines Exemplars beim Generieren unter dem neuen Systemnamen gedoppelt. Alle Festlegungen zum Steuerungs-Status beider Türen werden über neu definierte Statusbefehlsblätter 91 realisiert, die über den Statusschalter ausgewählt werden. Bei dem Status S3-* Befehlsblatt wurde für die Sperrenformulierung nicht eine Elementarfünktion sondern mit „Tür x" eine höhere Hierarchieebene in der Funktionsstruktur benutzt. Damit können sehr effektiv ganze Funktionsbereiche gegen Zustandsveränderungen gesperrt oder auch mit Formulierungen „alle außer XXX" sehr effektiv selektiert werden.
Figur 22 zeigt Merkmale einer Kleinsteuerung 94 bei einem technischen Gerät 95. Der relativ kleine und feste Befehlsumfang der Kleinsteuerung 95 ist in einem Steuerungs-Hardwarebaustein angeordnet, der die Funktionalität des Ausführungsrechners 2 und des Befehlsrechners 3 beinhaltet. Die Bedienung erfolgt mit üblichen Schalt- und Anzeigegeräten 96. Über eine Schnittstelle 97 kann ein Computer 98 angekoppelt werden, womit alle Funktionalität der Steuerung zum Einbringen der Steuerungssoftware und komfortable Kommunikation und Diagnose möglich sind.
Bezugszeichenliste
1 Struktur der Steuerung ASS
2 Ausführungsrechner
3 Befehlsrechner
4 Anwendungsrechner
5 Funktionsstruktur
6 Funktionseinheit Gesamtsystem
7 Funktionseinheit Teilsystem
8 Funktionseinheit Elementarfünktion
9 Datenblatt zu Elementarfunktionen
10 Name der Elementarfünktion
11 Funktionsskizze
12 Aktoren
13 Sensoren
14 Zustandsdefinitionen
15 Signalvektoren
16 Elementarbefehle
17 Kontrollzeit
18 Referenzzustand
19 Editierebene
20 Generieren des Elementarfünktions-Speichers
21 Elementarfünktions-Speicher
22 Generieren des EF-Controlers
23 EF-Controler
24 Soll-Zustand der Elementarfunktionen Ist-Zustand der Elementarfunktionen Generieren des Zustandsüberwachers Zustandsüberwacher Soll-Signalvektor der Elementarfünktion Ist-Signalvektor der Elementarfunktion Sollsignal vektor des Systems Istsignalvektor des Systems Nutzungsbefehl Befehlsaufbereiter Befehlspuffer B austein B efehlsstarter Baustein EF-Controler Baustein Zustandsüberwacher Baustein Nichtsollbewerter Nichtsoll-Aktionsspeicher Nichtsoll-Befehl Zustandsmeldung Zeitkritischer Funktionsbereich Inhalt eines Befehls Folgebefehle Parallelbefehle Befehlspuffer für Parallelbefehle Prüfungsergebnis Befehlspuffer "nein" Prüfungsergebnis Befehlspuffer "ja" Aktivierung EF-Controler Aktivitäten Befehlsstarter bei Erreichen "befehlsgemäßer Zustand" Aktivitätsstart EF-Controler Änderung Sollzustand im EF-Controler durch Befehl Änderung Istzustand im EF-Controler durch Sensormeldung Vergleich Soll- und Ist-Zustand im EF-Controler Änderungsstatus im EF-Controler Alternative " Änderungsstatus" Alternative "Kein Änderungsstatus" Aufruf Befehlsstarter vom EF-Controler Alternativen bei Nichtübereinstimmung Soll- und Istzustand im EF-Controler Prüfung Änderungszustand bei Nichtübereinstimmung Soll- und Istzustand im EF- Controler Aktivität bei Änderungszustand und Nichtübereinstimmung Soll- und Istzustand im EF- Controler Meldung vom EF-Controler "Elementarfunktion (Name der Elementarfunktion) beim Ändern" Alternative im EF-Controler bei Ist-Zustand ungleich Sollzustand und keinem Änderungszustand Nichtsoll-Istsignalvektor Auswertungsspeicher Nichtsoll-Bewerter Start Nichtsollbewerter Aktion, wenn Nichtsoll-Elementarfunktion keinen Eintrag im Nichtsoll-Aktionsspeicher hat Fehlermeldung zu Nichtsoll-Elementarfünktion Aktion, wenn Nichtsoll-Elementarfünktion einen Eintrag im Nichtsoll-Aktionsspeicher hat Vergleich Nichtsoll-Istsignalvektor mit gespeichertem NichtsoU-Signalvektor im Nichtsollbewerter Aktion bei fehlender Übereinstimmung Nichtsoll-Istsignalvektor mit NichtsoU- Signalvektor im Nichtsoll-Bewerter 71 Aktion bei Übereinstimmung NichtsoU-Istsignalyektor mit NichtsoU-Signalvektor im Nichtsoll-Bewerter
72 Reaktionsbefehle im Nichtsoll-Aktionsspeicher
73 Prüfung, ob Nichtsoll-Istsignalvektor zu einer Ereignissteuerung gehört
74 Ereignissteuerung
75 Meldung Ereignissteuerung
76 Inhalt der Meldung Ereignissteuerung
77 Fehlermeldung, wenn keine Ereignissteuerung
78 Inhalt der Fehlermeldung
79 Start des Bausteins Zustandsüberwacher
80 Vergleich SoUsignalvektor des Systems mit dem Istsignalvektor des Systems
81 Programmschleife zum Vergleich SoUsignalvektor des Systems mit dem Istsignalvektor des Systems
82 Übergabe der Aktivität vom Zustandsüberwacher an Befehlsstarter
83 Eintrag geändertes Ist- Sensorsignal vom Zustandsüberwacher im EF-Controler
84 Vergleichs- Sollvektor "letzter ausgewerteter Zustand" im Zustandsüberwacher
85 Ereignis-Zeit-Protokoll
86 formale Befehlsnamen
87 Befehlssperren
88 Sperrenverzeichnis im Befehlsrechner
89 Sperrenverzeichnis des Beispiels Schließanlage
90 Status einer Anlage
91 Status-Befehlsblätter
92 Befehlsbibliothek
93 Nutzungsprogramme
94 Kleinsteuerung
95 Technisches Gerät mit Kleinsteuerung 96 Schalt- und Anzeigegeräte
97 Schnittstelle für Computeranschluss
98 Transportabler Computer

Claims

Patentansprüche
1. Verfahren zum Steuern von Mechanismen oder technischen Systemen, dadurch gekennzeichnet, dass a) die zu steuernden Mechanismen oder technischen Systeme in ihren Elementarfunktionen (8) mit deren befehlsgemäß definierten Zuständen und den zugehörigen Signalvektoren (15) der Sensoren (13) und Aktoren (12) in der Steuerung gespeichert werden, wobei ausgehend von einem definierten Referenzzustand (18) zu Beginn der Steuerungsaktivierung ein ständiger Vergleich der von der technischen Anlage durch die Sensoren (13) gemeldeten Ist-Zustände mit den in der Steuerung gespeicherten Sollzuständen (24) für alle Elementarfunktionen erfolgt und damit jede Abweichung im zu steuernden System vom befehlsgemäßen Sollzustand (24) erkannt wird, b) ein den Zustand der Mechanismen oder des technischen Systems verändernder neuer Elementarbefehl (16) mit seinem Start den Sollzustand (24) für den Vergleich aktualisiert und auf der Grundlage ebenfalls gespeicherter zulässiger Kontrollzeiten (17) die Zeit bis zur Rückmeldung des befehlsgemäßen neuen Zustandes überwacht, c) wobei Sensorsignale und vergleichbare Informationen ausschließlich der Zustandsidentifikation von Elementarfunktionen (8) dienen, Zustandsänderungen ausschließlich über den Start von Elementarbefehlen (16) erfolgen, denen die Sensor- und Aktor-Signale als Sollzustand zugeordnet sind und die auf logisch-fünktionellem Sprachniveau frei definierten Nutzungsbefehle (32) durch entsprechende Zuordnung von Elementarbefehlen (16) definiert sind.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, a) dass in der Steuerung in einem speziellen Programmbaustein, hier als EF-Controler (23) bezeichnet, die Zustände aller Elementarfunktionen (8) als befehlsgemäß aktueller Sollzustand (24) und als aktueller Istzustand (25) mit den zugehörigen Aktoren (12) und Sensoren (13) geführt werden, b) wobei damit jede über die Sensoren (13) erkannte Zustandsänderung des technischen Sy- stems der betroffenen Elementarfünktion (8) als aktueller Istzustand zugeordnet und mit dem in der Steuerung geführten SoUzustand (24) verglichen und bewertet werden kann.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass a) bei einem erkannten, nicht dem Sollzustand (24) entsprechendem Istzustand (25) einer Elementarfünktion (8) der den Istzustand beschreibende Signalvektor (15) an einen anderen speziellen Programmbaustein der Steuerung, hier als Nichtsollbewerter (38) bezeichnet, übergeben wird, b) wobei in diesem Nichtsollbewerter (38) für ausgewählte Zustände von Elementarfunktionen (8) Reaktionsbefehle (72) gespeichert sind, die bei Übereinstimmung mit dem zur Prüfung übergebenen Zustand gestartet werden, c) und in allen Fällen differenzierte Fehlermeldungen mit Angabe der betroffenen Elementarfünktion und des abweichenden Signales erzeugt werden.
4. Verfahren nach Anspruch 1 bis 3, dadurch gekennzeichnet, dass a) einem Nutzungsbefehl (32) als Befehlssatz sowohl die neuen Sollzustände (24) der Sensoren (13) und Aktoren (12), die Kontrollzeiten (17) zum neuen Sollzustand (24) als auch die bei Abweichungen zu startenden Reaktionsbefehle (72), jeweils unterschieden in vor dem Start und nach erfolgter Ausführung zu löschende und zu setzende Reaktionsbefehle (72) auf ausgewählte Zustandsmeldungen, zugeordnet werden, b) wobei ein weiterer spezieller Programmbaustein der Steuerung, hier als Befehlsstarter (35) bezeichnet, die dafür erforderliche Organisation im System übernimmt und damit auch die Freigabe eines nächsten Befehls bei Befehlsfolgen nach Erfüllungsmeldung des vorhergehenden sowie die Organisation von Parallelbefehlen (45) durch je nach Bedarf temporäres Eröffnen von parallelen Abarbeitsfolgen realisiert wird.
5. Verfahren nach Anspruch 1 bis 4, dadurch gekennzeichnet, dass a) Sensorsignale (13) und weitere zu kontrollierende Informationen in einem weiteren speziellen Programmbaustein, hier als Zustandsüberwacher (37) bezeichnet, zu einem lückenlosen Datenwort zusammengezogen werden, wobei den Signalen die Adresse der zugehörigen Elementarfunktion (8) in dem Programmbaustein EF-Controler (36) der Steuerung zugeordnet bleibt, b) für den Vergleich jedem Sollsignal (30) das Ist-Signal (31) der Sensormeldung in gleicher Struktur gegenübersteht, c) wobei der Programmbaustein Zustandsüberwacher (37) bei einer erkannten Abweichung eines Ist-Signals dieses im EF-Controler (36) als neuen Istzustand der Elementarfünktion (29) aktualisiert, d) und nach der Aktualisierung und Übergabe zur Auswertung im EF-Controler (36) das geänderte Signal als neuer Vergleichszustand im Zustandsüberwacher (37) eingetragen wird, womit ein Vergleich im Zustandsüberwacher (37) immer zum letzten ausgewerteten Zustand erfolgt und jede Zustandsänderung damit nur einmal ausgewertet wird, e) wobei der Vergleich der Soll-Ist-Signale (30,31) im Zustandsüberwacher (37) gerichtet erfolgt und nach einer Unterbrechung für die Auswertung einer Abweichung der Vergleich bei dem der Unterbrechungsstelle folgenden Signal fortgesetzt wird, wodurch gesichert ist, dass jede zeitlich hinreichend lange Zustandsänderung erfasst und ausgewertet werden kann.
6. Verfahren nach Anspruch 1 bis 5, dadurch gekennzeichnet, dass a) jede erfasste Zustandsänderung vom Programmbaustein Zustandsüberwacher (37) in einem Ereignis-Zeit-Protokoll (85) eingetragen und dort gespeichert werden kann, b) wodurch auf einfachstem Weg zeitabhängige Prozessparameter zugängig werden, damit auch Signalschwingungen erkannt und gegebenenfalls ausgefiltert werden können.
7. Verfahren nach Anspruch 1 bis 6, dadurch gekennzeichnet, dass a) der Teilbereich Ausführungsrechner (2) mit den Programmbausteinen Befehlsstarter (35), EF-Controler (36), Nichtsollbewerter (38) und Zustandsüberwacher (37) nach Übergabe eines Elementarbefehls (16) an den Programmbaustein Befehlsstarter (35) in der Steuerung keine Prüfung auf Zulässigkeit enthält, b) die Ausführung eines erhaltenen Befehls von den dem Ausführungsrechner (2) zugeordneten Programmbausteinen jeweils autark realisiert wird, c) im Teilbereich Befehlsrechner (3) der Steuerung auf logisch-funktionellen Befehlsniveau zu den sich ausschließenden Zuständen Sperrenverzeichnisse (88) geführt und verwaltet werden, die den prozess- und maschinenseitig determinierten Anteil von fünktionellen Verriegelungen übernehmen, d) wobei ein Nutzungsbefehl (32) neben dem Aufruf von zu ändernden Elementarfunktionen (8) auch die Informationen enthält, für welche anderen Befehle Sperren im Sperrenverzeichnis (88) während oder nach der Ausführung dieses Nutzungsbefehls (32) zu setzen oder aufzuheben sind.
8. Verfahren nach Anspruch 1 bis 7, dadurch gekennzeichnet, dass der Ausführungsrechner (2) und der Befehlsrechner (3) zeitlich um einen Programmschritt entkoppelt arbeiten, a) der ausführende Teil der Steuerung, der Ausführungsrechner (2), einen erhaltenen Befehl autark ausführt, wobei ein Befehle verwaltender Teil der Steuerung, der Befehlsrechner (3), dem ausführenden Teil Ausführungsrechner (2) den nächstfolgenden geprüften Befehl in einem Zwischenspeicher als Befehlspuffer (34) bereitstellt, b) und nach dem Bereitstellen eines Befehls im Befehlspuffer (34) des Ausführungsrechners (2) der Zustand im Befehlsrechner (3) auf den Stand aktualisiert wird, der nach der Ausführung dieses Befehls eintreten wird, und zu diesem erwarteten Zustand die Prüfung des dann nachfolgenden Befehls auf Zulässigkeit im Befehlsrechner (3) bereits während der Abarbeitung des vorhergehenden erfolgt, c) wenn wegen eines Fehlers der erwartete Zustand nicht eintritt, wird der geprüfte Befehl aus dem Befehlspuffer (34) zurückgesetzt und das System auf den Fehlerzustand aktualisiert.
9. Verfahren nach Anspruch 1 bis 8, dadurch gekennzeichnet, dass Nutzungsbefehle (32) erarbeitet werden, a) indem den sprachlich fünktionell prozessnah zu definierenden Nutzungsbefehlen (32) aus den vorher definierten Elementarbefehlen (16) solche einzeln, parallel oder als Folge zugeordnet, b) dazu die Sperrbedingungen auf Befehlsniveau für die mit Aufruf des Nutzungsbefehls (32) vorzunehmenden Aktualisierungen in dem Sperrenverzeichnis im Befehlsrechner (88) definiert, c) die Reaktionsbefehle (72) auf ausgewählte Abweichungen sowie geeignete Fehlermeldungen festgelegt, d) diese Informationen in einer Befehlsbibliothek (92) abgelegt werden, wo die Steuerung dann die Befehlsinhalte für Nutzungsbefehle (32) abruft.
10. Verfahren nach Anspruch 1 bis 9, dadurch gekennzeichnet, dass ein Nutzungsprogramm (93) für das Betreiben des technischen Systems die Reihenfolge von definierten Nutzungsbefehlen (32) festlegt, die jeweils nacheinander oder parallel abgearbeitet werden sollen.
11. Verfahren zur Erstellung von Steuerungssoftware, dadurch gekennzeichnet, dass die Erstellung der Steuerungssoftware durch ein Entwicklungssystem mit Dialogführung unterstützt wird, a) wobei für die Beschreibung des zu steuernden Systems die Angabe der hierarchischen Funktionsstruktur (5) abgefragt wird, b) das jeweils untere Ende dieser Struktur als Elementarfunktion (8) betrachtet wird und jede Elementarfunktion (8) ebenfalls im Dialog in ihren Befehlszuständen zu definieren ist, c) wobei diesen definierten Elementarbefehlen (16) die Signale der Sensoren (13), der Aktoren (12), die Kontrollzeiten (17) für den Übergang zwischen den befehlsgemäßen Zuständen und ein Referenzzustand (18) für den Beginn zuzuordnen sind, d) die Einbindung komplexerer Teilsysteme ebenso als Elementarfünktion (8) erfolgen kann, wenn die Stellung in der Funktionsstruktur (5) solches ausweist, e) wobei das Dialogsystem als Grundlage für die Beschreibung der Funktionalität des technischen Systems nur die hier genannten primären Angaben zu Struktur (5) und zu den Elementarfunktionen (9) verlangt.
12. Verfahren nach Anspruch 11, dadurch gekennzeichnet, dass das dialoggeführte Entwicklungssystem zur Erstellung der Steuerungssoftware nach Eingabe der primären Angaben a) den System-Elementarbefehlsspeicher (21 ), b) den EF-Controler (36) und den c) SoUsignalvektor (30) sowie den Istsignalvektor für den Zustandsüberwacher (37) anlegt und generiert und damit das technische System bereits inbetriebgenommen, auf fehlerfreie Signaldefinition im Referenzzustand (18) überprüft und mit den definierten Elementarbefehlen (16) in einem Inbetriebnahmestatus gesteuert und soweit zulässig mit diesen Einzelbefehlen getestet und geprüft werden kann.
13. Verfahren nach Anspruch 11 oder 12, dadurch gekennzeichnet, dass Änderungen von Informationen zu Struktur (5) und Elementarfunktionen (8) nur über die Editierebene (19) möglich sind und die nachfolgende automatische Generierung die Konsistenz des geänderten Zustandes sichert.
14. Verfahren nach Anspruch 11 bis 13, dadurch gekennzeichnet, dass das Entwicklungssystem für die Definition von Nutzungsbefehlen (32) in spezifischen Dialogen a) die verfügbaren Elementarbefehle (16) des Systems zur Zuordnung anbietet, b) Sperrbedingungen für das Sperrenverzeichnis (88) abfragt, wobei die Angaben für festzulegende Sperren grafisch über Auswahl in der Funktionsstruktur (5) und Sperrfestlegungen in Formulierungen „dieser Elementarbefehl", „diese Elementarfunktion", „dieser Zweig der Funktionsstruktur" oder „alle Funktionen dieses Funktionszweiges außer diesem Elementarbefehl" erfolgen können, c) Festlegungen zu spezifischen Reaktionsbefehlen (72) auf besondere Fehler abgefragt werden, d) alle Festlegungen gespeichert und in der Befehlsbibliothek (92) eingeordnet und verwaltet werden.
15. Verfahren nach Anspruch 11 bis 14, dadurch gekennzeichnet, a) dass für ein so aufgebautes Steuerungssystem Änderungen an Elementarfunktionen (8) lokal begrenzt bleiben, b) dass jederzeit und ebenfalls mit überschaubarer lokaler Wirkung neue Nutzungsbefehle (32), Sperrbedingungen in dem Sperrenverzeichnis (88) oder Fehlerreaktionen durch Reaktionsbefehle (72) erweitert oder geändert werden können, c) dass unterschieden durch die Vergabe von Statusinformationen (90) für das System ohne jede Rückwirkung auf schon definierte Programme neue Definitionen von Nutzungsbefehlen (32) und Befehlsbedingungen erfolgen können.
16. Einrichtung zum Steuern von Mechanismen oder technischen Systemen, dadurch gekennzeichnet, a) dass für die unterschiedlichen Aufgaben unterschiedliche Bereiche der Einrichtung vorgesehen sind und diese nach den wichtigsten Aufgabenmerkmalen konfiguriert werden, wobei insbesondere kurze Reaktionszeiten auf erkannte Ereignisse und sichere Programmabläufe erreicht werden, b) dass die Programmbausteine für alle zeitkritischen Aufgaben der Steuerung Befehlsstarter (35), EF-Controler (36), Nichtsollbewerter (38) und Zustandsüberwacher (37) in einem hier als Ausführungsrechner (2) bezeichneten Teil der Einrichtung angeordnet sind, c) der Ausführungsrechner (2) bei umfangreichen Programmen mit großer Programmvariabilität für diese zeitkritischen Aufgaben über einen eigenen Prozessor verfügt, d) dass der Ausführungsrechner (2) für die Kommunikation mit der zu steuernden Einrichtung über die Sensoren (13), die Aktivierung von Aktoren (12), den Soll-Ist- Vergleich, Reaktionen auf Abweichungen des Ist- (25) zum Soll-Zustand (24) und die Abarbeitung eines erhaltenen Befehls autark ist, e) zur Verwaltung von Nutzungsbefehlen (32) in Befehlsbibliotheken (92), das Führen von Sperrenverzeichnissen (88), die Abarbeitung von Nutzungsprogrammen (93) durch schrittweise Übergabe von Befehlen an den Ausführungsrechner (2) sowie zur äußeren Kommunikation von dem hier als Befehlsrechner (3) bezeichneten Bereich der Einrichtung ein weiterer Prozessor vorgesehen ist, wenn die Merkmale von c) zutreffen, f) für die Aufgaben der Prozessgestaltung, soweit sie nicht Ausführungs- oder Befehlsrechner betreffen, ein Bereich Anwendungsrechner (4) vorgesehen ist.
17. Einrichtung nach Anspruch 16, dadurch gekennzeichnet, dass a) für Kleinsteuerungen (94) mit geringem Befehlsumfang und unkritischen Zeitforderungen in einem Steuerungs-Hardwarebaustein (95) die Module des Ausführungsrechners (2) und des Befehlsrechners (3) mit festen Befehlssätzen eingebracht sind, b) zur Bedienung und Kommunikation übliche Schalt- und Anzeigegeräte (96) vorgesehen sind, c) über eine Schnittstelle (97) ein externer Computer (98) für das Einbringen der Steuerungssoftware sowie im Bedarfsfall für eine komfortable Kommunikation und Diagnose ankoppelbar ist.
Hierzu 17 Blatt Zeichnungen
PCT/DE2001/001331 2000-04-04 2001-04-03 Zustandssteuerung von technischen systemen WO2001075535A2 (de)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2001573150A JP2003529835A (ja) 2000-04-04 2001-04-03 機構および技術システムの制御方法、制御装置および制御ソフトウェア
US10/009,010 US7065413B2 (en) 2000-04-04 2001-04-03 Method for producing software for controlling mechanisms and technical systems
EP01931411A EP1226473A2 (de) 2000-04-04 2001-04-03 Zustandssteuerung von technischen systemen

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE10017708.5 2000-04-04
DE10017708A DE10017708B4 (de) 2000-04-04 2000-04-04 Verfahren zum Steuern von Mechanismen und technischen Systemen, Einrichtung und Steuerungssoftware

Publications (2)

Publication Number Publication Date
WO2001075535A2 true WO2001075535A2 (de) 2001-10-11
WO2001075535A3 WO2001075535A3 (de) 2002-05-10

Family

ID=7638184

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/DE2001/001331 WO2001075535A2 (de) 2000-04-04 2001-04-03 Zustandssteuerung von technischen systemen

Country Status (5)

Country Link
US (1) US7065413B2 (de)
EP (1) EP1226473A2 (de)
JP (1) JP2003529835A (de)
DE (1) DE10017708B4 (de)
WO (1) WO2001075535A2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1460541A2 (de) * 2003-01-16 2004-09-22 Siemens Aktiengesellschaft Verfahren zur Überwachung von Funktionskomponenten in Baumstrukturen

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6885975B2 (en) * 2000-11-14 2005-04-26 Rajagopalan Srinivasan Method and apparatus for managing process transitions
US7006880B2 (en) * 2002-04-19 2006-02-28 Phred, Llc Method for controlling a device with a control system
US8291382B2 (en) * 2008-07-22 2012-10-16 International Business Machines Corporation Maintenance assessment management
US9389603B2 (en) 2010-06-24 2016-07-12 Siemens Aktiengesellschaft Method for controlling an electric machine and control device

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE3743438A1 (de) * 1987-12-21 1989-06-29 Siemens Ag Verfahren und einrichtung zum steuern des uebergangs eines endlichen automaten von einem momentanzustand in einen folgezustand
EP0424869A1 (de) * 1989-10-23 1991-05-02 Komatsu Ltd. Vorrichtung zur Fehlerprädiktion
DE4124542A1 (de) * 1990-07-24 1992-02-06 Mitsubishi Electric Corp Fehlerdiagnoseeinrichtung
EP0487117A2 (de) * 1985-07-19 1992-05-27 Rodger T. Lovrenich Steuerungssystem mit verteilter Logik
WO1994012914A1 (de) * 1992-11-25 1994-06-09 Siemens Aktiengesellschaft Verfahren zum erstellen der anwendungsabhängigen logik eines freiprogrammierbaren schaltwerkes, einrichtung zur durchführung dieses verfahres und einrichtung zum betrieb eines steuerungssystems unter verwendung eines so erstellten programms
DE4407334A1 (de) * 1994-03-02 1995-09-14 Reinhard Dipl Ing Lange Verfahren zum Erstellen und Darstellen von Steuerungen
DE19513801A1 (de) * 1995-04-11 1996-10-17 Siemens Ag Verfahren zur automatischen Erzeugung einer Steuerung
WO1998040796A1 (de) * 1997-03-11 1998-09-17 Siemens Aktiengesellschaft Verfahren zur rechnergestützten fehleranalyse von sensoren und/oder aktoren in einem technischen system

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US424869A (en) * 1890-04-01 Elevator
US487117A (en) * 1892-11-29 Step for shelves
US3743438A (en) * 1972-02-17 1973-07-03 Plessey Co Ltd Transfer pumps
US4124542A (en) * 1977-08-25 1978-11-07 Devine Michael J Spot cleaning composition for carpets and the like
US4407334A (en) * 1979-08-06 1983-10-04 Leesona Corporation Method and apparatus for positively removing weft from air insertion guidance tube
US4858101A (en) * 1987-08-26 1989-08-15 Allen-Bradley Company, Inc. Programmable controller with parallel processors
US5193189A (en) * 1987-10-07 1993-03-09 Allen-Bradley Company, Inc. Programmable controller with multiple priority level task processing
US5168441A (en) * 1990-05-30 1992-12-01 Allen-Bradley Company, Inc. Methods for set up and programming of machine and process controllers
US5545962A (en) * 1992-08-18 1996-08-13 Canon Kabushiki Kaisha Positioning system
AU3477397A (en) * 1996-06-04 1998-01-05 Paul J. Werbos 3-brain architecture for an intelligent decision and control system
DE19741959C2 (de) * 1997-09-23 2000-03-02 Siemens Ag System zur Verarbeitung von Ereignissen in technischen Prozessen mit einem verteilten Datenverarbeitungssystem

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0487117A2 (de) * 1985-07-19 1992-05-27 Rodger T. Lovrenich Steuerungssystem mit verteilter Logik
DE3743438A1 (de) * 1987-12-21 1989-06-29 Siemens Ag Verfahren und einrichtung zum steuern des uebergangs eines endlichen automaten von einem momentanzustand in einen folgezustand
EP0424869A1 (de) * 1989-10-23 1991-05-02 Komatsu Ltd. Vorrichtung zur Fehlerprädiktion
DE4124542A1 (de) * 1990-07-24 1992-02-06 Mitsubishi Electric Corp Fehlerdiagnoseeinrichtung
WO1994012914A1 (de) * 1992-11-25 1994-06-09 Siemens Aktiengesellschaft Verfahren zum erstellen der anwendungsabhängigen logik eines freiprogrammierbaren schaltwerkes, einrichtung zur durchführung dieses verfahres und einrichtung zum betrieb eines steuerungssystems unter verwendung eines so erstellten programms
DE4407334A1 (de) * 1994-03-02 1995-09-14 Reinhard Dipl Ing Lange Verfahren zum Erstellen und Darstellen von Steuerungen
DE19513801A1 (de) * 1995-04-11 1996-10-17 Siemens Ag Verfahren zur automatischen Erzeugung einer Steuerung
WO1998040796A1 (de) * 1997-03-11 1998-09-17 Siemens Aktiengesellschaft Verfahren zur rechnergestützten fehleranalyse von sensoren und/oder aktoren in einem technischen system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP1460541A2 (de) * 2003-01-16 2004-09-22 Siemens Aktiengesellschaft Verfahren zur Überwachung von Funktionskomponenten in Baumstrukturen
EP1460541A3 (de) * 2003-01-16 2008-07-23 Siemens Aktiengesellschaft Verfahren zur Überwachung von Funktionskomponenten in Baumstrukturen

Also Published As

Publication number Publication date
US7065413B2 (en) 2006-06-20
US20030040814A1 (en) 2003-02-27
JP2003529835A (ja) 2003-10-07
EP1226473A2 (de) 2002-07-31
WO2001075535A3 (de) 2002-05-10
DE10017708B4 (de) 2008-02-14
DE10017708A1 (de) 2001-10-18

Similar Documents

Publication Publication Date Title
DE102004042550B4 (de) Zustandsautomat-Funktionsblock mit durch den Nutzer veränderlicher Konfigurationsdatenbank für Zustandsübergänge
EP0653078A1 (de) Verfahren und leittechnisches system zum steuern, überwachen und regeln insbesondere von komplexen industriellen prozessen, wie z.b. in einem kernkraftwerk
EP0753168B1 (de) Verfahren zur automatischen diagnose von störungsfällen
DE19639424A1 (de) Entwurfsverfahren für die Anlagentechnik und rechnergestütztes Projektierungssystem zur Verwendung bei diesem Verfahren
EP0553621B1 (de) Programmierbare Computersteuerung für eine Werkzeugmaschine
AT412131B (de) Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu
EP2098928A1 (de) Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
EP2496993B1 (de) Verfahren zur absicherung von end-user programmänderungen durch formale kontrakte und programmverifikation in der automatisierungstechnik
EP1226473A2 (de) Zustandssteuerung von technischen systemen
EP3567441B1 (de) Prozessleitsystem mit einem engineering-, einem operator- und einem archiv-system
WO2010028760A1 (de) Automatisierungssystem mit frameworkbasierter steuerung
DE4325860A1 (de) Verfahren und leittechnisches System zum Steuern, Überwachen und Regeln insbesondere von komplexen industriellen Prozessen, wie z. B. in einem Kernkraftwerk
DE19707107A1 (de) Einrichtung zur Programmierung eines SPS
EP1506474A2 (de) Verfahren zur generierung eines automatisierungsprogramms
DE4212370C2 (de) Automatisierungsverfahren für eine verfahrenstechnische Anlage mit einem "Wegenetz", Automatisierungsgerät zur Durchführung des Verfahrens und bevorzugte Verwendungen desselben
DE68905848T2 (de) Speicherprogrammierbare steuerung mit strukturierter programmiersprache.
DE102018204952A1 (de) Testverfahren eines mechatronischen Systems
WO2002101543A2 (de) Programmierwerkzeug und programmierverfahren
EP1998240B1 (de) Zyklisch arbeitende Steuerung sowie Verfahren zum Einketten von Software-Bausteinen in den Funktionsablauf einer Steuerung
EP3948449B1 (de) Verfahren und engineering-system zur änderung eines programms einer industriellen automatisierungskomponente
EP3717975A1 (de) Verfahren und vorrichtung zur projektierung einer spezifi-schen verfahrenstechnischen anlage
AT522186B1 (de) Computerimplementiertes Verfahren zur rechnergestützten Erzeugung eines ausführbaren Steuerungsprogramms zur Steuerung und/oder Regelung eines technischen Prozesses
WO1994012914A1 (de) Verfahren zum erstellen der anwendungsabhängigen logik eines freiprogrammierbaren schaltwerkes, einrichtung zur durchführung dieses verfahres und einrichtung zum betrieb eines steuerungssystems unter verwendung eines so erstellten programms
DE19838469A1 (de) Prozeßsteuer- und Regelsystem mit verteilter Verarbeitung
EP1184760B1 (de) Verfahren zur Steuerung und/oder Regelung eines technischen Prozesses

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CN JP RU US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

ENP Entry into the national phase

Ref country code: JP

Ref document number: 2001 573150

Kind code of ref document: A

Format of ref document f/p: F

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 2001931411

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 10009010

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2001931411

Country of ref document: EP