WO2010060575A1 - Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung - Google Patents

Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung Download PDF

Info

Publication number
WO2010060575A1
WO2010060575A1 PCT/EP2009/008279 EP2009008279W WO2010060575A1 WO 2010060575 A1 WO2010060575 A1 WO 2010060575A1 EP 2009008279 W EP2009008279 W EP 2009008279W WO 2010060575 A1 WO2010060575 A1 WO 2010060575A1
Authority
WO
WIPO (PCT)
Prior art keywords
component
software
software components
block
components
Prior art date
Application number
PCT/EP2009/008279
Other languages
English (en)
French (fr)
Inventor
Matthias Reusch
Stefan Woehrle
Ralf Bauer
Matthias Holzaepfel
Maurice Gilmore
Original Assignee
Pilz Gmbh & Co. Kg
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Pilz Gmbh & Co. Kg filed Critical Pilz Gmbh & Co. Kg
Priority to CN200980155248.2A priority Critical patent/CN102292680B/zh
Priority to EP09796615A priority patent/EP2353051A1/de
Priority to JP2011536786A priority patent/JP2012510099A/ja
Publication of WO2010060575A1 publication Critical patent/WO2010060575A1/de
Priority to US13/111,144 priority patent/US8832667B2/en

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/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence

Definitions

  • the present invention relates to a method and apparatus for creating a user program for a safety controller that is configured to control a system with a plurality of hardware components, the plurality of hardware components each including at least one sensor and at least one actuator ,
  • a safety controller in the sense of the present invention is a device which receives input signals supplied by sensors and generates output signals therefrom by logic operations and possibly further signal or data processing steps. The output signals can be supplied to actuators, which cause actions or reactions in a controlled system depending on the input signals.
  • a safety controller must comply with prescribed safety standards, which are laid down, for example, in the European standard EN 954-1 or a comparable standard, for example the IEC 61508 standard or the EN ISO 13849-1 standard. In contrast to a controller for so-called standard applications, a safety controller thereby ensures at least one single-fault safety within the meaning of categories 3 or 4 of the European standard EN 954-1 or its Safety Integrity Level (SIL) reaches at least stage 2 according to the cited standard IEC 61508.
  • SIL Safety Integrity Level
  • a preferred field of application for such safety controls is the monitoring of emergency stop buttons, two-hand controls, safety gates or light curtains in the field of machine safety.
  • sensors are used to protect a machine or equipment that poses danger to people or material goods during operation.
  • a signal is generated which receives the safety control as an input signal.
  • the safety controller shuts down the dangerous part of the machine or system with the help of an actuator.
  • a programmable safety controller offers the user the option of individually defining the logic operations and, if necessary, further signal or data processing steps with the aid of a software called the user program. This results in a great deal of flexibility compared to previous solutions, in which the logic operations were generated by a defined wiring between different safety relays.
  • An example of a method for programming a safety control is described in DE 101 08 962 A1.
  • a problem with the programming of a safety controller is that the user program can become very complex and unclear when monitoring a large machine system with many safety devices. For example, large plants, such as a cement plant, can contain several thousand sensors.
  • the user program to be created is itself a safety-critical element, since an error in the user program can cause an uncontrolled situation and thus a dangerous state in the monitored machine or system.
  • the method according to DE 101 08 962 A1 places some restrictions on the user. In particular, he can only access ready-made, certified program modules and combine them only individually. However, according to the method of DE 101 08 962 A1, the user can not change the individual program modules and can not create independent program modules. As a result, the method of DE 101 08 962 A1 is limited to safety controllers for smaller and medium-sized applications. For very large systems, the method according to DE 101 08 962 A1 does not offer sufficient flexibility.
  • the international standard IEC / EN 61131 defines various methods for programming industrial controls, partly using graphics editors.
  • graphic elements are provided according to the functionality of the machine or system to be controlled in the form of so-called function blocks.
  • Each hardware component contained in the machine or system can correspond to a graphical element which represents the functionality of the associated hardware component.
  • the graphical elements can be interconnected by logical links.
  • hierarchy can be used, i. the graphical elements can be assigned to the structure of the machine or plant to be controlled according to different hierarchy levels. When creating the user program, you can then proceed on a level-by-level basis.
  • the known methods and devices can help to increase the clarity in creating a user program for a safety controller. However, they are not yet optimal in terms of very complex applications with a large number of safety-related and non-safety-relevant sensors and actuators.
  • This object is achieved by a method for creating a user program for a safety controller, which is designed to control a system with a plurality of hardware components, the plurality of hardware components each including at least one sensor and at least one actuator following steps:
  • each of these aspect blocks being associated with one of a plurality of mutually different control aspects; each of these control aspects representing an independent sub-aspect of the safety control, each of these aspect blocks having a number of signal inputs and a number of signal outputs, wherein a number of input signals can be supplied to the respective aspect block via its number of signal inputs, and that aspect block is input via its number of signal outputs can output a number of output signals, and wherein the output signals are determined at least in dependence on the input signals,
  • an aspect subprogram for at least one control aspect wherein for at least one aspect block included in the plurality of software components, at least a portion of the signal inputs are assigned sensors whose sensor signals are processed in the respective aspect block, and wherein at least a portion of the signal outputs Actuators are assigned, which are controlled by the output signals determined in the respective aspect block, Assembling the component subprogram and the aspect subprogram to the user program.
  • a device of the type mentioned above comprising the following units: first units for providing a plurality of software components for the plurality of hardware components, the plurality of software components each having at least one logic input and at least one Logic output and at least one aspect block, each of these aspect blocks being associated with one of a plurality of mutually different control aspects, each of these control aspects representing a self-contained safety control subaspect, and wherein each of these aspect blocks has a number of signal inputs and a number of signal outputs; each aspect block can be supplied via its number of signal inputs, a number of input signals and this aspect block can output a number of output signals via its number of signal outputs, wherein the Output signals are determined at least in response to the input signals, second units for creating a component subprogram by logically combining the plurality of software components, wherein at least a part of the logic inputs and at least a part of the logic outputs of the software components are interconnected, third units for creating an aspect subprogram for at least one
  • Each aspect block represents one of several mutually different control aspects, each of these control aspects representing an independent subfunction of a safety controller.
  • this approach provides an additional classification tool that reduces the complexity of creating a safety control application program.
  • user program When the term user program is used below or when the term user program is used, it is intended to be a control program for a specific control application, such as the concrete control program for a production line for defined workpieces.
  • the creation of a user program thus corresponds to the realization of a total functionality for the plant to be controlled.
  • various aspects such as the definition of the actual manufacturing process, the safety-related protection of the system, the generation and provision of diagnostic information u.a. summarized.
  • the new aspect blocks now make it possible to subdivide the creation of the complex user program into the individual sub-aspects.
  • the new method and apparatus include a matrix-like organization of the programming tasks involved, namely, on the one hand subdivided into software components, each associated with specific hardware components, and, on the other hand, broken down into aspect blocks, which allow a programming grouped by functional aspects aspects.
  • the latter is preferably independent of the individual hardware components, as will be explained below with reference to some embodiments.
  • one of several different views of the overall functionality and the user program to be created can be taken.
  • the user can create subprograms directed at individual aspects, which are later merged into the user program.
  • the aspect subprograms are used in addition to a component subprogram, which has a Linking software components that contain aspect blocks.
  • the aspect subprograms can be created independently.
  • the user program can be created separately according to independent sub-aspects by creating a large number of independent aspect programs.
  • the new approach corresponds to a vertical subdivision of the overall functionality that is to be realized for the plant to be controlled.
  • the independent sub-aspects preferably occur in all hierarchical levels into which a plant to be controlled can be structured.
  • the overall functionality to be realized can be subdivided vertically.
  • the plurality of software components correspond to the plurality of hardware components.
  • a software component is provided that also represents the functionality that the respective hardware component has. This measure contributes to the clarity in the creation of the user program and thus improves the error safety.
  • at least one software component is selected from a set of predefined software components.
  • This embodiment of the invention has the advantage that uniform software components are used within a user program. This ensures that identical software components are provided to each other for identical hardware components contained in the system to be controlled, with the appropriate selection.
  • predefined, i. prefabricated software components is thus excluded that identical hardware components are represented by software components that have a different program behavior with each other. This applies not only to a single user program but also to a large number of user programs, if they were created with the aid of a computer program using the same database containing the predefined software components. Overall, the clarity is increased by this measure and improves the error safety.
  • predefined software components offer another advantage. As mentioned earlier, safety controllers require special approval from the relevant regulatory authorities prior to their use. This also includes the user program. If predefined software components are used, it is sufficient to have them approved by a regulatory authority. This is usually done together with the removal of the computer program that can be used to create user programs. If software components are then provided by selecting from a set of predefined software components when creating a user program by means of correspondingly secure measures, no further acceptance is required for that part of a user program which contains exclusively such provided software components. This increases the efficiency of creating a user program.
  • the predefined software components each represent one of a plurality of mutually different hardware component types, each of these hardware component types having a functionality that is characteristic of this hardware component type as such, and each of the Hardware component associated with this type of hardware component, wherein the predefined software components each contain those aspect blocks that are associated with the control aspects relevant to the hardware component type that represents the predefined software component.
  • This measure has the advantage that in a predefined software component all relevant aspects are summarized which are of importance for the hardware component type which represents the predefined software component.
  • the hardware component type is fully described in terms of the aspects of safety control by the software component representing it. It is therefore perfectly sufficient for the programmer of a user program to provide a software component for a hardware component located in the plant to be controlled, by selecting that predefined software component that represents the hardware component type to which the hardware component Component belongs. The programmer thus needs to provide only a single software component for the particular hardware component, rather than providing multiple software components or additional aspect blocks.
  • the functionality exhibited by the hardware component type may be mechanical, electrical or electromechanical functionality. These functionalities justify a multiplicity of distinguishing features, so that the hardware component types can be, for example, motors or adjusting cylinders, which are designed, for example, pneumatically.
  • a hardware component type can also be used for a complex assembly, such as process stations, test stations, or module stand. The enumeration of elementary components and complex assemblies is not exhaustive.
  • a predefined software component corresponds to a placeholder that represents a hardware component type. If the attachment contains a hardware component belonging to a particular hardware component type, then when the user program is created, a software component is provided by selecting the appropriate predefined software component, with the provided software component of the existing physical component Hardware component corresponds.
  • This approach can be compared with the approach underlying object-oriented programming. Transferring the laws of object-oriented programming to the new method, the predefined software component corresponds to a class, i. the entirety of all objects of the same kind.
  • the provided software component corresponds to an instance, i. an object of a certain class.
  • a copy is created by the selected predefined software component, which is then provided as a software component.
  • This measure has the advantage that a predefined software component can be used at different locations in a user program to be created. It is thus reusable, it is reusable. In this case, all copies of the predefined software component, ie all provided software components that go back to the same predefined software component, have the same properties that are predefined by the predefined software component.
  • the provided software components are only parameterizable. That is, their functionality is basically determined by the predefined software components, but can be easily modified within certain limits. This ensures that existing in a system to be controlled identical hardware components through Software components are presented, which basically have an identical functionality. Overall, an efficient creation of a user program is made possible.
  • the fact that the provided software components each correspond to a copy of a predefined software component ensures that identical hardware components present in the system to be controlled are represented by identical software components. This improves the error safety.
  • the creation of a copy of a predefined software component corresponds to instancing.
  • At least one new software component is created when providing the plurality of software components.
  • This measure has the advantage, if necessary, i. according to the conditions of the system to be controlled to generate new required software components. This ensures a high degree of variability, for example in the event that the predefined software components present in the computer program with which the user program is created are insufficient to represent the overall functionality of the system to be controlled.
  • the predefined software components and / or the newly created software components are each formed either as a group component or as an elementary component, wherein a group component contains at least one aspect block and at least one software component, wherein the software component contained itself in turn may be formed as an elemental component or as a group component, and wherein an elementary component only contains at least one aspect block.
  • a corresponding software component can be created, regardless of the complexity of the hardware component.
  • a software component designed as an elementary component and, for a complex hardware component, a software component designed as a group component can be created.
  • the creation of a new elementary component comprises the following steps, the new elementary component having a number of logic inputs and a number of logic outputs:
  • the number of aspect blocks each having as inputs in addition to the number of signal inputs additionally a number of logic inputs and / or a number of parameter inputs and outputs in addition to the number of signal outputs in addition a number of logic outputs and / or a number of parameterization outputs, wherein the number of aspect blocks in each case on the number of logic inputs, a number of logic variables or a number of intermediate sizes are each determined in a different aspect block, and a number of parameters can be supplied via the number of parameter inputs, and wherein the number of aspect blocks in each case via the number of logic outputs, a number of logic variables or a number of Zwis size, which are each required by another aspect block, and can output a number of parameters via the number of parameter outputs,
  • the respective function program Creating a respective function program for at least a part of the number of aspect blocks, the respective function program determining aspect properties of the hardware component for the control aspect to which the respective aspect block is assigned.
  • the creation of a new elementary component according to the individual steps described above has the advantage that the new elementary component contains all the information in the program in order to fully describe the functionality of the hardware component corresponding to the newly created elementary component.
  • the newly created elementary component is transformed into an encapsulated accessory. was transferred, in which state no changes can be made to the newly created elementary component.
  • the encapsulation of the newly created elementary component causes its component properties to be hidden. This means that direct access to the inner data structure of the newly created elementary component is prevented. Access to the newly created elementary component is only possible via defined interfaces, namely their inputs and / or outputs.
  • the component properties are determined by the aspect blocks provided, which are stored in these stored function programs, the logical connection of the aspect blocks, and the fixed quantities and / or signals to be supplied to and output from the newly created elementary component.
  • the encapsulation of the newly created elementary component improves the error safety because the newly created elementary component can only be changed unchanged, i. while retaining their properties, they can be used as often as required in a user program. It is usually envisaged that the person who has created the encapsulated new elementary component may make changes to it at a later time. Whereas the user, who only provides an encapsulated new elementary component when creating a user program, can not make any changes to it.
  • the creation of a new group component comprises the following steps, the new group component having a number of logic inputs and a number of logic outputs:
  • the creation of a new group component has the advantage that the new group component contains all information technically in order to fully describe or map the functionality of the hardware component corresponding to the newly created group component.
  • one of several stored functionalities can be activated or selected in a group component via a functionality parameter.
  • these functionalities are stored in a software component contained in the group component and define the functionality of this software component.
  • Each of these functionalities is assigned a defined functionality parameter value.
  • one of the stored functionalities can preferably be activated or selected.
  • a software component is given that represents an emergency stop button. Emergency stop buttons are available in a wide variety of configurations and thus functionalities, for example with or without an acknowledge input.
  • the functionality parameter value is in an aspect block associated with the standard control aspect or the safety control aspect.
  • the stored functionalities relate solely to the software component
  • the stored functionalities relate to the entire group component and thus influence the respective functionalities of a plurality of software components contained in the group component.
  • an elementary component is provided with a functionality parameter, for example a software component that represents an independent emergency stop button.
  • the newly created group component is converted into an encapsulated state in a further step, wherein in this state no changes can be made to the newly created group component.
  • the component properties of the newly created group component are to be fed to the newly created group component by the aspect blocks provided, the function programs stored in them, the logical connection of the aspect blocks, the provided elementary components and / or group components and their logical binding and the specified sizes and / or signals are or are issued by this, set.
  • the component properties of the newly created group component thus also include the component properties of the elementary components and / or group components contained in it.
  • a copy of the newly created software component is created, which is then provided as a software component.
  • the predefined software components and / or the newly created software component are in each case encapsulated software components to which no changes can be made.
  • the encapsulated software components can be transferred into a processing mode, wherein in this processing mode Changes to the encapsulated software components can be made.
  • an encapsulated software component can be edited and thus fundamental changes can be made to it. These changes are taken into account for all copies created by this predefined software component and provided in a user program as a software component. These changes go beyond the modifications that can be made to a software component by setting parameter values. With these changes, for example, the functionality of a software component should be able to be adapted to the control task.
  • the described measure has the following advantage: For example, during the creation of a user program, it is determined that a predefined software component does not completely cover the functionality of that hardware component that corresponds to the predefined software component, for example due to changes in the manufacturing process by the manufacturer the hardware component, the predefined software component can be edited to fully encompass the functionality. Also, this measure can be used to create a new software component using a predefined software component. For this purpose, the predefined software component is transferred into the processing state and at least partially changed. This makes it possible to modify a predefined software component that does not comprehensively describe the properties of a hardware component such that the new software component generated therefrom comprehensively describes these properties. As this relies on an already existing predefined software component, this saves time when creating the new software component. Overall, the embodiment described above achieves the greatest possible flexibility when creating an application program. In a further embodiment of the aforementioned measure, the function programs stored in the assigned aspect blocks can be changed in the processing mode for at least some of the control aspects.
  • control aspect that represents the sub-aspect of safety control can not be changed for the control function stored in the assigned aspect blocks.
  • This measure ensures that the functionality for the safety control, once defined and accepted by a supervisory authority, is retained. This contributes to improving the error safety.
  • the relevant functionality for the safety control can not be fundamentally changed. It can only be modified by parameters within certain limits, for example by specifying appropriate intervals.
  • a function program is stored which defines aspects of the hardware component for that control aspect to which the respective aspect block is assigned be processed, wherein parameter values can be specified for the parameters, wherein a change in the parameter values causes a modification of the aspect properties.
  • a change in the parameter values leads to a modification of the aspect properties.
  • the aspect properties can thus be easily adapted to the properties of the plant to be controlled within the limits specified by the parameter values.
  • the functionality of the software remains with a modification of the aspect properties Component basically received.
  • the parameter values are specified in the creation of an aspect subprogram for the aspect blocks considered in this case.
  • a function program is respectively stored in the aspect blocks, which defines aspect properties of a hardware component for the control aspect to which the respective aspect block is assigned, which is the hardware component corresponding to the software component. which contains the respective aspect block, wherein at least one of the several mutually different control aspects and thus the aspect properties defined for them concern the hardware component as such.
  • This measure has the advantage that the functionalities and thus properties can be specified in a specific manner for the respective software component in terms of aspect, ie with respect to the individual sub-aspect of a safety control.
  • the user program can be created precisely and the overall functionality of the system to be controlled can be precisely determined.
  • it is ensured that all data or information required for the description of the functionality of a hardware component is contained in a single software component. Overall, the error safety is improved by this measure.
  • At least part of the provided plurality of software components additionally contains, in addition to a number of aspect blocks, a number of elementary components and / or a number of group components, wherein a group component contains at least one aspect block and at least one software component the contained software component itself may in turn be embodied as an elemental component or as a group component, and wherein an elementary component only contains at least one aspect block, wherein in the number of aspect blocks a respective function program is stored which defines aspect properties for the control aspect to which the respective aspect block is assigned is, wherein at least one of the plurality of mutually different control aspects and thus the aspect properties determined for this the interaction of at least a part of the number of elementary components and / or at least part of the number of group components.
  • a control aspect relates to the interaction of several hardware components, which in turn are arranged in a hardware component, has the following advantage: If an installation to be controlled contains a hardware component that includes several hardware components, then the Providing the software component that corresponds to this hardware component at the same time provided the functionality that specifies the interaction of the included hardware components. This reduces the complexity of creating reduces the number of user programs and thus improves the error safety.
  • a partial aspect of a safety controller, which concerns the interaction of several hardware components, is, for example, the partial aspect of the interlock.
  • control aspects may be any number of the following control aspects: a standard control aspect having the sub-aspect standard control, i. represents the operation of the plant required for a particular application; a safety control aspect that represents all accident prevention measures; a diagnostic aspect representing the collection and processing of diagnostic information; a visualization aspect that includes all the program steps required to visualize system states; a drive control aspect representing the details of one or more drive controls within the plant; a cooling aspect, representing all measures necessary for cooling; an access entitlement aspect that includes all actions involving an access privilege; a maintenance aspect representing all program steps required for regular maintenance; a lock aspect representing the sub-aspect lock; a manual operation aspect representing the manual operation sub-aspect; a data management aspect that represents the subaspect data management.
  • control aspects listed above can be subdivided into technology-related and application-related control aspects.
  • the technology-related aspects include, for example, the safety control aspect, the standard control aspect, the diagnostic aspect, and the visualization aspect.
  • the application-related control aspects include, for example, the locking aspect and the manual operating aspect.
  • the standard control sub-aspect relates to the scope of a safety controller in which standard variables are processed, and thus need not be designed to be safe.
  • the sub-aspect safety control concerns the extent of a safety control in which safe variables are processed, and thus must be designed securely.
  • the sub-aspect diagnosis relates to the extent of a safety control, which are designed to detect errors or causes of errors.
  • the sub-aspect visualization refers to those peripheries of a safety controller that are designed for the representation of data or states of hardware components. Also included are the ranges that allow interaction of the operator of the system with the safety control.
  • the partial aspect of drive control relates to those peripheries of a safety control which are designed to control a drive in the sense of setting, for example, a rotational speed or a speed or a force.
  • the partial aspect of cooling relates to those peripheries of a safety control which are designed for the cooling of hardware components contained in the system to be controlled.
  • the sub-aspect access authorization relates to those peripheries of a safety controller which are designed to switch the system to be controlled, for example, from an automatic mode in which the user program is executed to a mode set-up mode in which adjustments can be made to the system to be controlled.
  • the sub-aspect maintenance relates to the extent of a safety control, which are directed to measures to maintain the functionality of the system to be controlled.
  • the sub-aspect locking concerns those peripheries of a safety control, which are designed so that a system to be controlled can not be started until certain conditions have been met, For example, a protective door is locked. Additionally or alternatively, the sub-aspect locking also relates to those peripheries that are designed so that a hardware component contained in the system can only assume a certain state when another hardware component with which it interacts assumes a predefined state.
  • the partial aspect manual operation relates to those peripheries of a safety controller, which are designed to switch the system to be controlled from an automatic mode to a manual mode in which the individual steps of the user program can be progressively executed.
  • the sub-aspect data management concerns the scope of a security control, which are designed to collect and store data (in the sense of SCADA, Supervisory Control and Data Acquisition).
  • a control aspect simulation can be provided.
  • the software component in which this aspect block is contained can be checked.
  • the behavior or function of the software component can be tested.
  • An aspect block associated with this control aspect serves to assist the one who is creating a user program.
  • information about the software component is stored, in which the respective aspect block is included. This can be the following information: description of the software component, description of the interfaces of the software component, description of the parameters used in the software component, description of the functionality and the possible use of the software component.
  • an aspect block for the operator of the system controlled by the safety control system. This may be, for example, the following information: Operating instructions for the hardware component that corresponds to the software component in which the aspect block is contained, the area of application of the hardware component.
  • an aspect block is provided by selecting a particular aspect block contained in a set of selectable and thus predefined aspect blocks.
  • the one who creates a user program can create additional aspect blocks application-specific, which can then be added advantageously to the already existing selectable aspect blocks.
  • the creation of further aspect blocks makes it possible, for example, for a machine tool manufacturer to define and thus use company-specific uniform aspect blocks with regard to their profile and / or their structure.
  • aspect blocks can provide aspect blocks by selecting or creating according to the software component approach.
  • Creating a new aspect block essentially requires the following steps: defining a block; Giving a name to the new aspect block; Defining the content of the aspect block and thus defining a new sub-aspect.
  • the partial aspect of drive control not only includes control tasks usually associated with non-secure standard control, i. can be executed using non-secure standard variables and are therefore to be assigned to the standard control aspect. Rather, the sub-aspect of drive control should also include control tasks that are safety-relevant and therefore attributable to the safety control aspect and thus have to be performed using secure variables.
  • control tasks to be assigned to the safety control aspect are the control tasks to be executed in the course of a "safe brake curve monitoring” or the control tasks to be executed within the scope of a “safe reduced speed”.
  • the "safe brake curve monitoring” refers to the controlled deceleration of a motor.According to a parameterized braking curve, the motor should come to a standstill the parameterization can be specified, how steep the brake curve should fall off.
  • the parameterized braking curve predetermines the rotational speed of the motor for different times, which are within a predetermined time interval, which it is allowed to take up to a maximum.
  • actuators designed as contactors for example, with which the motor is connected to the power supply, are driven to the motor disconnect from the power supply.
  • the "safe reduced speed” preferably refers to the operation of a robot in maintenance mode, while maintenance may allow the robot to perform movements, but to minimize the risk of injury to maintenance personnel During the maintenance work, the current achieved movement speed of the robot is detected and compared with the specified value. If the specified value is exceeded, the contactors with which the robot becomes active will be detected is connected to the power supply, controlled to disconnect the robot from the power supply.
  • a number of aspect blocks are provided in addition to the plurality of software components, wherein these number of aspect blocks are taken into account when creating an aspect subprogram.
  • the user program is hierarchically structured, wherein the hierarchy level defined by the provided plurality of software components is that which is the highest hierarchical level and by at least one software component which is included in one of those software components. Components belonging to the provided plurality of software components, another, below the top hierarchical level hierarchical level is determined.
  • This embodiment of the invention represents a measure with which the complexity in creating a user program can be reduced.
  • a second measure to reduce complexity is available.
  • the measure which is justified by the new approach, achieves a vertical subdivision of the overall functionality of the plant to be controlled.
  • the measure of hierarchization effects a subdivision of the overall functionality in the horizontal direction.
  • the two measures thus have different order or arrangement directions, which is why they do not adversely affect each other when used simultaneously.
  • these two measures or structuring approaches can be easily combined, which is why their combination is particularly consistent.
  • the complexity can be greatly reduced and thus greatly improve the clarity, which ultimately leads to a very strong improvement of the error safety.
  • a number of aspect blocks are provided in addition to the plurality of software components, wherein at least a portion of the plurality of software components and at least a portion of the number of aspect blocks can be combined to form a new software component , whereby a new uppermost hierarchical level is determined, below which the previous highest hierarchical level as second-highest hierarchical level.
  • This measure has the advantage that, at any stage in the creation of an application program within the top hierarchical level, a part of the plurality of software components can be combined into a new software component, taking into account the required aspect blocks, thereby ensuring that in the highest hierarchical level to reduce complexity.
  • this measure can also be applied in a corresponding manner to an already existing further hierarchical level lying below the uppermost hierarchical level.
  • a measure is available with which the complexity achieved in this hierarchical level can be reduced for any hierarchical level.
  • the user program is structured into a plurality of hierarchy levels, one of which can be selected, wherein, when creating an aspect subprogram, only those aspect blocks that are contained in the selected hierarchy level are considered further.
  • This measure has the advantage that the number of aspect blocks to be considered when creating an aspect subprogram can be reduced. This further reduces the complexity of creating a user program and further improves error security.
  • one of the hierarchy levels can be defined as a reference hierarchy level, with an independent aspect subprogram being created both for the reference hierarchy level and for those hierarchy levels that are above the reference hierarchy level in the hierarchy, wherein when creating the respective independent aspect subprogram only those aspect blocks that are contained in the respective hierarchy level are taken into account, and an aspect subprogram is created for the hierarchy levels that lie below the reference hierarchy level, whereby all aspect blocks contained in these hierarchy levels are taken into account when the aspect subprogram is created.
  • the reference hierarchy level can be set so that only those hierarchy levels are subjected to a single consideration, for which this leads to a noticeable reduction in complexity. In contrast, those hierarchy levels are considered together for which the number of aspect blocks to be taken into account is manageable.
  • the reference hierarchy level can be determined by the programmer of the user program and thus adapted to his needs.
  • At least part of the aspect blocks have at least the following units, each of the aspect blocks having a number of inputs through which input signals can be supplied to the respective aspect block, and having a number of outputs over which the respective aspect block can output output signals:
  • an identification unit in which an identifier is deposited, which determines the control aspect to which the aspect block is assigned, a functional unit, in which a function program is stored, with which an aspect property of the hardware component is defined, which corresponds to the software component in which the aspect block is contained,
  • an interface unit that combines the number of inputs and the number of outputs of the aspect block.
  • this structured structure of the aspect blocks enables an efficient creation of a user program.
  • the division into the functional unit, the parameter unit and the interface unit ensures an optimized user program with regard to speed and storage space requirements.
  • the structure of the aspect blocks it is conceivable that these in any case have an identification unit, a functional unit and an interface unit.
  • the parameter unit can only be used on demand, i. if parameters are provided in the function program, be present. This procedure is advantageous in terms of the storage space required for the created user program.
  • At least part of the software components have at least the following units, each of the software components having a number of inputs via which input signals can be supplied to the respective software component, and a number of outputs has, via which the respective software component output signals can output:
  • a group component includes at least one aspect block and at least one software component, wherein the contained software component itself may be formed as elemental component or as a group component, and wherein an elementary component only contains at least one aspect block .
  • an interface unit that combines the number of inputs and the number of outputs of the software component.
  • the uniform structure of the software components ensures compatibility between the software components. This enables a particularly efficient creation of a user program. At the same time, error sources are eliminated with regard to the logical linking of the software components, which contributes to improving the error safety. Preferably, all software components have this structure.
  • the inputs are a number of signal inputs and / or a number of logic inputs and / or a number of parameter inputs, and at the outputs by a number of signal outputs and / or by a number of Logic outputs and / or by a number of Parameterierausêtn, wherein on the number of signal inputs, a number of input signals and the number of logic inputs, a number of logic variables and the number of parameter inputs a number of parameters can be supplied, and wherein the number of Signal outputs a number of output signals and on the number of logic outputs a number of logic variables and the number of parameterizing outputs a number of parameters can be output.
  • the interface units respectively contained in the aspect blocks and the interface units respectively contained in the software components are functionally identical.
  • a function program is respectively stored in the aspect blocks, which defines aspect properties of a hardware component for the control aspect to which the respective aspect block is assigned, which is the hardware component corresponding to the software component. which contains the respective aspect block, wherein the individual function programs are created using a programming language, which is selected from a variety of different programming languages.
  • This measure ensures that the most suitable programming language is used to create the individual function programs. It can be provided that by the computer program, with which the new method can be carried out, which is determined according to objective criteria, the most appropriate language is selected or specified. This can be for single aspects, such as the sub-aspect of the visualization or the sub-aspect of the diagnosis of advantage. Alternatively or additionally, it is provided that the programmer who creates a user program can select the most suitable programming language according to subjective criteria. For example, the languages Instruction List, Ladder Diagram, Function Block Diagram, Sequential Function Chart and Structured Text listed in the European Standard IEC / EN 61131 under Part 3 can be used as a large number of different programming languages from which to select. Another language that can be used is the continious function chart language.
  • any programming language that complies with the IEC / EN 61499 standard is also possible, for example the programming language Java.
  • the programming language OBST can be used for the sub-aspect visualization.
  • the diagnostic conditions can be programmed using any of the programming languages mentioned in the IEC / EN 61131 standard.
  • the scopes required to display the diagnostic messages can be programmed in a different programming language. Choosing the most appropriate programming language also ensures that the most suitable editor is used.
  • the software components and / or the aspect blocks are displayed on a user interface by means of graphic symbols.
  • a drag-and-drop function is already known per se from graphical user interfaces of commercially available PCs.
  • an element is marked with an input device, for example by means of a so-called mouse, and then moved or copied with the aid of the input device to a desired location.
  • Such a way of choosing is very easy and comfortable for the programmer. As a result, operating errors and resulting errors in programming are further significantly reduced.
  • connection of inputs and outputs of the software components and / or the connection of inputs and outputs of the aspect blocks is done by dragging graphical lines.
  • This measure represents a simple and thus less error-prone handle. This improves the error safety.
  • one aspect subprogram is created for a plurality of mutually different control aspects, wherein the individual aspect subprograms are created separately.
  • the creation of the individual aspect subprograms can advantageously take place separately in time, so that the individual aspect subprograms are created one after the other in chronological order.
  • a spatial separation may be provided.
  • the individual aspect subprograms are each created using a separate graphical user interface. This makes it possible, among other things, to create several aspect subprograms in parallel at one time, if the individual ones graphical user interfaces are displayed on a monitor. This enables a particularly efficient creation of a user program.
  • This measure ensures a uniform handling within a control aspect and thus contributes to improving the error safety.
  • the new method and the new device have the following additional advantages: Previously, the use of various computer programs or tools for creating a user program required - usually had to be used for each sub-aspect of another - so you get out now with a single. This avoids compatibility issues that can occur when creating the application program using multiple computer programs or tools. It is not several computer programs or tools to master, it is enough to work in one. When creating a user program, all sub-aspects can be taken into account holistically.
  • FIG. 1 is a schematic representation of an embodiment of the new
  • FIG. 2 is a simplified representation of a first graphical user interface for
  • Fig. 3 is a simplified representation of a second graphical interface
  • FIG. 4 shows a schematic representation of a system to be controlled by the user program to be created
  • 5a shows a schematic representation of the software components and aspect blocks provided for the plant to be controlled in a top hierarchical level of the user program, according to a cascaded linkage approach and a first scope of control
  • FIG. 5b shows a schematic representation of the software components and aspect blocks provided for the plant to be controlled in a top hierarchical level of the user program, according to a cascaded linkage approach and a second control scope, FIG.
  • 5 c shows a schematic representation of the software components and aspect blocks provided for the system to be controlled in an uppermost hierarchical level of the user program, according to a non-cascaded linkage approach
  • Fig. 6 is a schematic representation of a sub-component to be controlled
  • Investment, 7 a shows a schematic representation of the software components and aspect blocks provided for the subcomponent, according to a cascaded linkage approach and a first scope of control
  • FIG. 7b shows a schematic representation of the software components and aspect blocks provided for the subcomponent, according to a cascaded linkage approach and a second control scope
  • FIG. 7c shows a schematic representation of the software components and aspect blocks provided for the subcomponent, according to a non-cascaded linkage approach
  • FIG. 8 shows a schematic representation of a subcomponent contained in the subcomponent and its individual components
  • 9a shows a schematic representation of the software components and aspect blocks provided for the subcomponent, according to a cascaded linkage approach and a first scope of control
  • FIG. 9b shows a schematic representation of the software components and aspect blocks provided for the subcomponent, according to a cascaded linkage approach and a second control scope
  • FIG. 9c is a schematic representation of the software components and aspect blocks provided for the subcomponent, according to a non-cascaded linkage approach.
  • 10 is a schematic representation of the aspect blocks provided for a single component included in the subcomponent
  • 11 is a schematic representation of the aspect blocks provided for an emergency stop button
  • FIG. 13 is a schematic representation of the basic structure of a
  • Fig. 1 an embodiment of the new device is designated in its entirety by the reference numeral 10.
  • the device 10 includes a conventional PC 12 with a monitor 14 on which a computer program 16 is executed.
  • the computer program 16 allows the creation of a user program 38 for a safety control. It is therefore often referred to in technical terminology as a programming tool.
  • the safety control to be programmed for which a user program is to be created is designated by the reference numeral 18 in FIG. It has a dual-channel redundancy structure to achieve the required fault tolerance for controlling safety-critical processes.
  • two separate processors 20, 22 are shown in FIG. 1, which are connected to one another via a bidirectional communication interface 24 in order to be able to control each other and exchange data.
  • the two channels of the safety controller 18 and the two processors 20, 22 are diverse, ie constructed differently from each other to largely rule out systematic errors.
  • Reference numeral 26 denotes an input / output unit which is in communication with each of the two processors 20, 22.
  • the input / output unit receives input signals 28 from external sensors 30 and forwards them in an adapted data format to each of the two processors 20, 22. Furthermore, the input / input unit generates output signals 32 in response to the processors 20, 22, with which actuators 34 are actuated.
  • the sensors 30 are, for example, emergency stop buttons, two-hand buttons, safety door switches, speed monitoring devices, light barriers, safety switches, limit switches or other sensors for recording safety-relevant variables.
  • the sensors 30 may also include sensors that are commonly used in standard controls and with which then a variable to be controlled can be detected within the drive control. For example, they may be sensors for receiving forces or speeds or angles of rotation. The above lists are not intended to be exhaustive.
  • the actuators 34 are, for example, contactors with which the power supply of a drive or a complete machine can be switched off.
  • the actuators 34 may also be actuators for realizing a movement, for example motors or cylinders, in particular pneumatically formed cylinders, as used, for example, for a linear movement.
  • the reference numeral 36 denotes a chip card on which a user program 38 is stored here.
  • the user program 38 is created with the aid of the device 10 and determines the control tasks to be performed by the safety controller 18. These control tasks in turn determine the overall functionality of the plant to be controlled by the safety controller.
  • the use of a chip card 36 as a storage medium allows a simple exchange of the user program 38 even without direct connection to the Vorrich- tion 10.
  • the user program 38 can be loaded via a data interface in a memory of the safety controller 18.
  • the computer program 16 provides user interfaces explained in greater detail below on the monitor 14.
  • the user interfaces provide software components and aspect blocks to a programmer, and enable him to create a component subprogram and aspect subprograms, assembling the component subprogram and the aspect subprograms into the user program 38.
  • a function block 40 The provision of the software components and the aspect blocks and the creation of the component subprogram and the aspect subprograms are symbolized in FIG. 1 by a function block 40.
  • a memory 42 of the PC Preferably, it is additionally secured there with at least one CRC (Cyclic Redundancy Check) checksum.
  • CRC Cyclic Redundancy Check
  • the user program 38 contains here both control tasks, which are usually carried out according to the prior art with a non-secure standard control and insofar are assigned to a standard control aspect, as well as control tasks that are safety-relevant and are therefore assigned to the safety control aspect.
  • the safety controller 18 has a bus system, via which the entire data exchange between individual components of the safety controller 18 runs, which occurs during the processing of the user program 38. This means that data is exchanged via this bus system both in the event that control tasks are assigned to the standard control aspect are as well as control tasks that are assigned to the safety control aspect, processed.
  • a first graphical user interface that provides the computer program 16 to the programmer on the monitor 14 is designated in its entirety by the reference numeral 50.
  • the first graphical user interface 50 includes a software component panel 52 that contains a set 54 of pre-defined software components in the form of graphical symbols, wherein the individual predefined software components are designated by the reference numerals 56, 58, 60, 62.
  • the predefined software components 56 to 62 were created by the provider of the computer program 16, with which the new method for creating a user program 38 can be performed, and are stored in a database or library contained in this computer program 16.
  • SK 1, SK 2, SK 3 and SK n given in FIG. 2 for the predefined software components 56 to 62, it is indicated that the set 54 of predefined software components is more than the predefined software components shown in FIG. Components 52 to 62 may include.
  • the software component field 52 contains a set 64 of newly created software components in the form of graphical symbols, wherein the individual newly created software components are designated by the reference numerals 66, 68, 70.
  • the newly created software components 66 through 70 are those software components that are provided by the programmer when creating the user program 38 for hardware components contained in the asset to be controlled, for which there is no corresponding predefined software component in the database or Library of the computer program 16 are included, were created and then encapsulated.
  • the predefined software components 56 to 62 are also encapsulated. The encapsulation ensures that the properties or the functionality of the predefined software components 56 to 62 and the newly created software components 66 to 70 can not be changed once they have been created.
  • the labels SK n + 1, SK n + 2 and SK n + 3 used for the newly created software components 66 to 70 indicate that the database or library contained in the computer program 16 is extended by these software components. Thus, these software components can be used at a later time, for example when a further user program is to be created, in addition to the software components 56 to 62 predefined by the manufacturer.
  • the predefined software components 56 to 62 are shown in solid lines and the newly created software components 66 to 70 are shown in dashed lines. Further, in the software component field 52, software components executed as so-called elementary components are represented with a small block, while software components executed as group components are represented with a large block. These forms of representation are valid for the entire FIG. 2. It should also be noted that both the predefined software components 56 to 62 and the newly created software components 66 to 70 can each be selected.
  • the first graphical user interface 50 includes an aspect block field 72 containing a set 74 of selectable aspect blocks in the form of graphical symbols, the individual aspect blocks being designated herein by the reference numerals 76, 78, 80, 82, 84, 86.
  • Each of the aspect blocks 76-86 is associated with one of a plurality of mutually different control aspects, each of these control aspects representing an independent sub-aspect of the safety control.
  • the designations Ab 1, Ab 2, Ab 3, Ab 4, Ab 5, and Ab n used for the aspect blocks 76 to 86 are intended to indicate that in the computer program 16 more than the indications shown in FIG. presented aspect blocks can be available.
  • the aspect blocks 76 to 86 are stored in a database or library contained in the computer program 16.
  • the first graphical user interface 50 further includes a workspace 88. With the aid of this workfield 88, new software components can be created by the programmer when creating an application program 38.
  • Numeral 90 designates a first new software component to be created, which is executed as an elementary component.
  • a number 92 of aspect blocks are provided for the first new software component 90 to be created.
  • the provision of an aspect block is accomplished by adding the appropriate aspect block 76-86 included in the aspect block field 72 to the new software component to be created using a drag-and-drop function, as exemplified by arrow 94.
  • a copy 96 of the selected aspect block 80 is created.
  • a memory area is provided in this process, in which the functionality or the properties are set, which specifies the selected aspect block 80. It should be noted at this point that this program-technical relationship also applies in a corresponding manner to subsequent statements with regard to the creation of a copy of an aspect block and / or the creation of a copy of a software component.
  • those logic quantities and / or intermediate values and / or those parameters and / or those signals are to be supplied to the respective aspect block for processing via associated inputs or those determined by the respective aspect block and from there via corresponding ones Outputs are output.
  • This setting can be done, for example, by assignments entered in an input field 98 using a textual programming language.
  • the sizes and / or parameters and / or signals are merely grounded.
  • the definition of the specific sensors and / or Actuators that are to be connected to the respective aspect block takes place in a later, to be described step.
  • Each aspect block contains logic inputs and logic outputs. At least a portion of these logic inputs and at least a portion of these logic outputs are interconnected and / or with logic inputs and / or logic outputs having the first new software component 90. This is indicated by way of example with a connection 100. For example, these links can be created graphically by dragging lines. That no connections between an aspect block and the first new software component 90 is shown is not intended to be limiting. For reasons of clarity, the representation of the logic inputs is dispensed with.
  • a function program is to be created in each case. Using any of the languages described in the European standard IEC / EN 61131, this can be done by entering appropriate instructions in programming field 98.
  • this software component is encapsulated and a newly created software component 66 is created in the software component field 52, indicated by an arrow 102. This can then be provided in a provision field 104 to be described, which is indicated by an arrow 106. In the deployment field 104, a copy 108 of the newly created software component 66 is created. Programmatically, this means that a memory area is reserved, in which the functionality or the properties are stored, which are predetermined by the newly created software component 66.
  • the created first new software component 90 directly in the deployment field 104 is provided and not first in the software component field 52 is transmitted or created in this.
  • a newly created software component 66 can then be created in the software component field 52 if the programmer of the user program so desires.
  • the reference numeral 110 designates a second new software component to be created, which is executed as a group component.
  • a number 112 of aspect blocks are provided for the second new software component 110 to be created. This is exemplified by an arrow 114.
  • the procedure corresponds to that which has already been described in connection with the first new software component 90. In this case, a copy 116 of the aspect block 86 is created.
  • a number 118 of elementary components are provided for the second new software component 110. This is indicated by an arrow 120.
  • a copy 122 of the predefined software component 60 is created. In terms of program technology, this means that a memory area is provided in which the functionality or the properties predefined by the predefined software component 60 are stored. Additionally or alternatively, a number 124 of group components are provided for the second new software component 110.
  • connections for the second new software component 110 are subsequently created.
  • At least a portion of the logic inputs and at least a portion of the logic outputs of the number 118 of elementary components and / or the number 124 of group components are inter-related and / or with at least a portion of the logic inputs and / or at least a portion of the logic outputs of the second new software component.
  • Component 110 connected.
  • Correspondingly created connections are designated by the reference numeral 126.
  • these links can be created graphically by dragging lines. That no connections between an aspect block or a software component and the second new software component 110 and no connections between an elementary component and a group component is shown is not intended to be limiting.
  • a function program is created in each case. This is done in a corresponding manner, as described in connection with the first new software component 90.
  • a newly created software component 70 is created in the software component field 52, as indicated by an arrow 128.
  • the newly created software component 70 may then be provided, as indicated by an arrow 130, in the creation of a user program in the deployment panel 104. In this case, a copy 132 of the newly created software component 70 is created.
  • the alternative procedure set forth in connection with the first new software component 90 can also be used.
  • the workspace 88 includes a third new software component 134.
  • This is formed as an elemental component containing a number 136 of aspect blocks.
  • the predefined software component 62 is assumed.
  • the predefined software component 62 is an encapsulated software component. This is transferred to a processing mode and in the working field 88, the third new software component 134 is created.
  • the individual aspect blocks contained in the number 136 of aspect blocks, the connections between these feature blocks with each other, and / or the third new software component 134 are the same as those in the predefined software component 62.
  • the transfer of the predefined software component 62 into a processing mode and the application of the third new software component 134 are indicated by an arrow 138.
  • a newly created software component 68 is created in the software component field 52, as indicated by an arrow 140.
  • the newly created software component 68 may then be provided when creating a user program, wherein a copy 142 of the newly created software component 68 is placed in the deployment field 104, as indicated by an arrow 144.
  • the alternative sequence described in connection with the first new software component 90 may also be considered.
  • the representation chosen in FIG. 2, according to which the third new software component 134 is designed as an elementary component, is not intended to have any restrictive effect.
  • a new software component can be created based on an already existing predefined software component that is executed as a group component.
  • a plurality 146 of software components are provided. As already described and indicated by the arrows 106, 130, 144, in this case newly created software components 66 to 70 can be provided. Additionally or alternatively, predefined software components 56 to 62 can also be provided, as indicated by an arrow 148. In this case, a copy 150 of the predefined software component 56 is created in the deployment field 104. In addition, a number 152 of aspect blocks are provided, exemplified by an arrow 154. In the deployment field 104, a copy 156 of the aspect block 76 is created.
  • the user program 38 is hierarchically structured.
  • the provided plurality 146 of software components define an uppermost hierarchical level. If the provided plurality 146 of software components include a software component which is designed as a group component, the number of software components contained in this software component will result in a further hierarchical level below the upper hierarchical level established. This is the case for copy 132, for example.
  • a part of the plurality 146 of software components and a part of the number 152 of aspect blocks can be combined to form a new software component 158.
  • This is a measure to reduce the complexity achieved in the considered hierarchical level. If such a summarized software component 158 is created in the uppermost hierarchical level, this establishes a new uppermost hierarchical level, below which the previous hierarchy level lies as the second highest hierarchical level. That the creation of a summarized software component is described in connection with the highest hierarchical level is not intended to have any restrictive effect. For example, a summarized software component can also be created in a hierarchical level below the highest hierarchical level.
  • the deployment field 104 does not contain the software components and aspect blocks of the top hierarchy level, but those of the considered hierarchical level.
  • a user program 38 can be created both according to the "top-down” concept and according to the "bot-up” concept. Due to the design of the new method and the new device, when creating a user program these two concepts can also be mixed.
  • an aspect block can be added on any hierarchical level. For example, this is required when creating a pooled software component. This may be, for example, an aspect block that is assigned to the control aspect that represents the sub-aspect locking. Not only an aspect block, but also a software component can be inserted at any hierarchical level of the user program to achieve a reduction in complexity.
  • each of these fields can also be arranged individually in a separate graphical user interface in a separate graphical user interface or any subcombination.
  • the newly created software components 66 to 70 are contained in a separate software component field.
  • the representation chosen for the working field 88, according to which three new software components 90, 110, 134 are processed in parallel, is not intended to have any restrictive effect.
  • these three new software components can also be created one after the other and thus individually by means of the working field 88.
  • a second graphical user interface is designated in its entirety by the reference numeral 170.
  • the second graphical user interface 170 includes a component panel 172 in which a provided plurality 174 of software components are arranged. These are the software components of the highest hierarchical level.
  • a component subprogram is created. For this purpose, at least a part of the logic inputs and at least part of the logic outputs of the software components are interconnected, which is represented by a plurality 176 of connections. Due to the internal logical links contained in each of the software components, the elementary components and / or group components arranged in these software components are automatically linked with each other. Consequently, when creating the component subprogram, it is sufficient to logically link the software components contained in the highest hierarchical level.
  • the logical links for the aspect blocks contained in the topmost hierarchical level can be made in the deployment field 104, for example. Alternatively, this can also be done in a separate, independent field, wherein the representation of such a field has been omitted for reasons of clarity.
  • the creation of the component subprogram also includes the above-described logical linking of the aspect blocks.
  • logical connections between logic inputs and logic outputs of software components are also realized, in particular by linking logic inputs and / or logic outputs of aspect blocks on the one hand with logic inputs and / or logic outputs of software components, and consequently Logic inputs and logic outputs of software components interconnected.
  • a plurality of software components for the plurality of hardware components does not mean that only software components are provided that correspond to hardware components that each include at least one sensor and at least one actuator. It is also possible to provide software components which do not simultaneously contain at least one sensor and at least one actuator. For example, software components are provided which correspond to a safety-relevant sensor, in particular an emergency stop button.
  • the second graphical user interface 170 further includes a first aspect panel 178.
  • a plurality 180 of aspect blocks are arranged. Each of these aspect blocks is associated with the same control aspect. In the exemplary embodiment, it should be the standard control aspect that represents the sub-aspect standard control.
  • the plurality 180 of aspect blocks include the aspect blocks included in all hierarchical levels of the user program 38 that are associated with the standard control aspect, regardless of whether they are contained in one of the hierarchy levels, on their own or as part of a software component.
  • the second graphical user interface 170 further includes a sensor array 182. Arranged in this sensor array 182 is a plurality 184 of graphical sensor symbols. For each sensor included in the equipment to be controlled, the sensor array 182 includes an associated graphical sensor symbol. The plurality 184 of graphical sensor symbols represent both the sensors included with respect to the safety control aspect and the standard control aspect in the equipment to be controlled. As another field, the second graphical user interface 170 contains an actuator field 186. In this actuator field 186, a plurality 188 of graphic actuator symbols are arranged. For each actor contained in the plant to be controlled, the actuator field 186 contains an associated graphical nice actuator symbol. The plurality 188 of graphical actor symbols include both the actuators with respect to the safety control aspect as well as those regarding the standard control aspect in the equipment to be controlled.
  • an aspect subprogram is created.
  • a so-called I / O mapping is performed both for their inputs and for their outputs.
  • at least a part of the signal outputs are assigned actuators which are controlled by the output signals determined in the respective aspect block. This is exemplified by an arrow 192.
  • the I / O mapping can also be made by textual entries in an input field 194.
  • it is conceivable to realize the I / O mapping also by drawing lines between individual aspect blocks and individual graphical sensor symbols or graphic actuator symbols.
  • the parameterization of the aspect blocks can also be performed at the same time.
  • parameter values for those parameters which are used in the respective function programs that are contained in the respective aspect blocks can be specified for individual aspect blocks.
  • the parameter values can be specified by textual entries in the input field 194.
  • the second graphical user interface 170 further includes a second aspect panel 196.
  • a plurality 198 of aspect blocks are arranged.
  • these aspect blocks are assigned to a safety control aspect, which represents the sub-aspect safety control.
  • An aspect subprogram is also created for these aspect blocks. That is, I / O mapping is performed for these aspect blocks, as exemplified by arrows 200, 202.
  • the comments on the first Aspect field 178 are taken. With regard to the parameterization of the aspect blocks, which may be necessary, reference is made to the comments on the first aspect field 178.
  • FIG. 4 an example of a plant to be controlled is designated in its entirety by the reference numeral 210.
  • the plant 210 to be controlled consists of three subareas, namely a handling station 212, a process station 214 and a test station 216.
  • the handling station 212 is used to fill the process station 214 with workpieces. These workpieces are processed in the process station 214. Subsequently, the processed workpieces are forwarded by the handling station 212 to the test station 216, in which it is checked whether the machined workpiece fulfills corresponding test criteria. If these tests are passed, the process station 214 can be filled again with a new workpiece to be machined.
  • the system 210 to be controlled has an emergency stop button 218, with which the device 210 can be switched off and transferred to a safe state.
  • FIG. 4 shows a display unit 220 with which, for example, diagnostic data or information about the state of the system 210 to be controlled can be displayed.
  • the system 210 is controlled by the safety controller 18.
  • FIG. 5 a shows those software components and aspect blocks for the plant 210 to be controlled, which are contained in the uppermost hierarchical level.
  • a plurality 230 of software components for the plant 210 to be controlled are provided, which are in detail the following software components: a first software component 232, which corresponds to the emergency stop button 218 and is designed as a single component , A second software component 234 corresponding to the handling station 212. A third software component 236 corresponding to the process station 214. A fourth software component 238 corresponding to the test station 316. Wherein the software components 234, 236, 238 are each formed as a group component. As well as a fifth software component 240, which is associated with the display unit 220 and which is formed as an elementary component. Each of the provided software components 234, 236, 238 represents a real mechatronic component present in the plant to be controlled.
  • the first software component 232 is connected via a first logic connection 242 to the second software component 234, to the third software component 236 and to the fourth software component 238. As long as the emergency stop button 218 is not actuated, the first software component 232 outputs an enable signal, which is supplied via the first logic connection 242 to the connected software components 234, 236, 238. By means of this enable signal, these software components are enabled and operation of the system 210 to be controlled is possible.
  • the software components 234, 236, 238 are interconnected by second logic connections 244. Via the second logic connections 244, signals controlling the sequence are exchanged between the software components 234, 236, 238.
  • the second software component 234 generates a signal which is supplied to the third software component 236. With this signal, the process station 214 is displayed that the operations of the handling station 212 are completed and thus started with the processing of the steps of the process station 214 can be.
  • the third software component 236 generates a signal which is supplied to the fourth software component 238. With this signal, the test station 216 is indicated that the work steps of the process station 214 are completed and thus can be started with the processing of the steps of the test station 216.
  • the fourth software component 238 generates a signal which is supplied to the third software component 236.
  • the result of the process station 214 determined in the test station 216 during a test procedure of the machined workpiece is communicated.
  • the third software component 236 generates a signal which is supplied to the second software component 234. With this signal, the handling station 212 is informed whether there is an error in the process station 214.
  • a number 246 of aspect blocks are also shown. Specifically, this is a first aspect block 248 associated with a standard control aspect, a second aspect block 250 associated with a safety control aspect, a third aspect block 252 associated with a diagnostic aspect, a fourth aspect block 254, the one Associated with a visualization aspect, a fifth aspect block 256 associated with a drive control aspect and a sixth aspect block 258 associated with a locking aspect.
  • the fourth aspect block 254 is connected to the fifth software component 240.
  • at least a portion of the diagnostic messages generated by the third aspect block 252 may be displayed with the fifth software component 240.
  • the sub-component process station is designated in its entirety by the reference numeral 214.
  • the following explanations also apply correspondingly to the handling station 212 and the test station 216.
  • the process station 214 comprises a rotary table 270, a test module 272, a drilling module 274 and an ejection module 276.
  • the rotary table 270 all workpieces between the individual modules 272, 274, 276 can be transported in the process station 214.
  • the test module 272 to be machined workpieces are checked for the presence of predetermined properties.
  • the drilling module 274 processes the workpieces located in the process station 214.
  • the ejection module 276 the machined workpieces are removed and forwarded to the test station 216. Alternatively, the machined workpieces can also be transferred to the handling station 212.
  • the process station 214 is associated with an emergency stop button 278.
  • FIG. 7 a shows the software components and aspect blocks contained in the third software component 236.
  • the reference numeral 280 denotes a sixth software component which corresponds to the emergency stop button 278 and which is designed as an elementary component.
  • Reference numeral 282 designates a seventh software component which corresponds to the corresponds to table 270.
  • Reference numeral 284 denotes an eighth software component corresponding to the test module 272.
  • Reference numeral 286 denotes a ninth software component corresponding to the drilling module 274.
  • Reference numeral 288 denotes a tenth software component corresponding to the ejection module 276.
  • the software components 282, 284, 286, 288 are designed as group components.
  • the software components 282, 284, 286, 288 are supplied with an enable signal generated in the sixth software component 280. Details of the enable signal can be correspondingly extracted from the description of FIG. 5a.
  • the software components 282, 284, 286, 288 are interconnected via fourth logic connections 292. Through appropriate signals, which are exchanged via the fourth logic connections 292 between the software components 282, 284, 286, 288, a sequence control is realized.
  • three signals are generated, of which in each case one of the eighth software component 284, the ninth software component 286 and the tenth software component 288 is supplied. These signals indicate to the respective hardware component corresponding to the respective software component that the rotary table 270 occupies a defined position in each case.
  • a further signal is generated, which is also supplied to the seventh software component 282. This signal represents the result of the test performed in the test module 272. Depending on this result, the operation of the rotary table 270 can be influenced.
  • the third software component 236 has several aspect blocks.
  • a seventh aspect block 294 associated with the standard control aspect an eighth aspect block 296 associated with the safety control aspect, a new aspect block 298 associated with the diagnostic aspect, a tenth Aspect block 300 associated with the visualization aspect, an eleventh aspect block 302 associated with the drive control aspect, and a twelfth aspect block 304 associated with the locking aspect.
  • the cooperation of the rotary table 270 and the drilling module 274 can be coordinated in a simple manner.
  • a signal that is generated in the ninth software component 286 is evaluated. It is the signal indicating that the drilling module 274 is in a home position in which the motor 310 is at such a height that the rotary table 270 can rotate freely.
  • the aspect block 304 only generates an enable signal specific to the rotary table 270 when this home position signal is present. This ensures that during a rotary movement of the rotary table 270, the drilling module 274 can not be damaged.
  • the drilling module is designated in its entirety by the reference numeral 274.
  • the drilling module 274 has as individual components with a mechanical or electrical or electromechanical function a motor 310, a transfer cylinder 312 and a drill cylinder 314. With the two cylinders 312, 314, the motor 310 can be moved along a guide unit relative to the workpiece to be machined, with the drill cylinder 314 in the vertical direction and with the transfer cylinder 312 in the horizontal direction.
  • the drilling module 274 is associated with an emergency stop button 316.
  • FIG. 9 a shows the software components and aspect blocks contained in the new software component 286.
  • This is an eleventh software component 320 that corresponds to the emergency stop button 316.
  • a twelfth software component 322 corresponding to the drill cylinder 314, a thirteenth software component 324 corresponding to the transfer cylinder 312, and a fourteenth software component 326 corresponding to the motor 310.
  • the software components 320, 322, 324, 326 are designed as elementary components.
  • the Software components 322, 324, 326 are supplied via a fifth logic connection 328 to an enable signal generated in the eleventh software component 320. Details of the enable signal can be correspondingly extracted from the description of FIG. 5a.
  • the ninth software component 286 includes a thirteenth aspect block 330 associated with the standard control aspect, a fourteenth aspect block 332 associated with the safety control aspect, a fifteenth aspect block 334 associated with the diagnostic aspect, a sixteenth aspect block 336 associated with the visualization aspect , a seventeenth aspect block 338 associated with the drive control aspect and an eighteenth aspect block 340 associated with the lock aspect.
  • the fourteenth aspect block 332 is supplied with the enable signal via the fifth logic connection 328.
  • the aspect blocks 330, 332 and the software components 322, 324, 326 are interconnected via sixth logic connections 342.
  • a signal representing the state of the drill cylinder 314 is generated.
  • This signal is applied to both the thirteenth aspect block 330 and the fourteenth aspect block 332.
  • the fourteenth aspect block 332 In response to the signals applied to it, the fourteenth aspect block 332 generates a signal which is supplied to the fourteenth software component 326. With this signal, the motor 310 can be switched on and off.
  • the thirteenth software component 324 generates a signal representing the state of the transfer cylinder 312. This signal is fed to the thirteenth aspect block 330.
  • the fourteenth software component 326 generates a signal representing a state of the motor 310. This signal is fed to the thirteenth aspect block 330.
  • the thirteenth aspect block 330 depending on the signals supplied to it, these are the three signals described above and a signal indicating that in the recording of the rotary table 270 located below the drilling module 274, a work piece is to be machined. piece and a parameter representing the maximum bore diameter generates three signals, from each of which one of the twelfth software component 322, the thirteenth software component 324 and the fourteenth software component 326 is supplied.
  • the drill cylinder 214 With the signal supplied to the twelfth software component 322, the drill cylinder 214 is activated.
  • the transfer cylinder 312 With the signal supplied to the fourteenth software component 326, the motor 310 is activated.
  • FIG. 10 shows those aspect blocks which are contained in a software component which corresponds to a cylinder contained in the plant 210 to be controlled.
  • this is, for example, the twelfth software component 322.
  • this should not have any restrictive effect; the following explanations also apply to the thirteenth software component 324.
  • the twelfth software component 322 includes a nineteenth aspect block 350 associated with the standard control aspect, a twentieth aspect block 352 associated with the safety control aspect, a twenty-first aspect block 354 associated with the diagnostic aspect, and a twenty-second aspect block 356 associated with the visualization aspect ,
  • the twelfth software component may also include a twenty-third aspect block 358 associated with the drive control aspect, as long as a corresponding actuation of the drill cylinder 314 is to occur. This option is indicated by the dashed lines.
  • no aspect block is provided which is assigned to the drive control aspect.
  • the control tasks that provide the drive control aspect are usually taken over by the aspect block contained in the next higher hierarchical level, which is assigned to the drive control aspect.
  • the aspect blocks 350, 352, 354, 356 are seventeenths one below the other and with an input and an output having the twelfth software component 322 Logic connections 360 connected.
  • the nineteenth aspect block 350 is activated via a signal which is supplied to it from the input of the twelfth software component 322.
  • the twentieth aspect block 352 is supplied with a release signal via an unillustrated connection.
  • the nineteenth aspect block 350 is associated with two end position sensors, which are preferably designed as limit switches. With a first end position sensor that position of the piston is detected, in which the piston rod is maximally extended from the cylinder housing. With a second end position sensor that end position of the piston is detected, in which the piston rod is minimally extended from the cylinder housing.
  • a quantity representing the state of the drill cylinder 314 is generated therein. This variable is supplied to the output of the twelfth software component 322. On the other hand, this size is fed to the twenty-second aspect block 356. Depending on this size, a size is generated in the twenty-second aspect block 356 representing the stroke set by the drill cylinder. This size can be supplied, for example, to the display unit 220, with which the operator of the system 210 to be controlled can be displayed with corresponding information.
  • a size is generated with which the drill cylinder 314 is driven such that its piston moves to the end position in which the piston rod minimally protrudes from the cylinder housing.
  • a second quantity is generated, with which the drilling cylinder 314 is controlled in such a way that the piston moves into the end position in which the piston rod looks out of the cylinder housing to the maximum.
  • the twentieth aspect block 352 two quantities are generated. A first magnitude indicating that the inward movement of the piston into the cylinder housing is enabled for the drill cylinder 314. A second size that indicates that the drill hole cylinder 314 the outward movement of the piston is released from the cylinder housing out. These two quantities are each provided at an output of the twentieth aspect block 352.
  • the sizes provided by the nineteenth aspect block and the twentieth aspect block, respectively, are linked in pairs according to a logical AND function. These linked quantities are available at respective outputs of the twelfth software component 322 and are supplied to the drill cylinder 314 for driving it.
  • the dashed connection between the two aspect blocks 350 and 354 represents a data exchange occurring between these two aspect blocks. It can be output data or internal data. Also between individual aspect blocks, which are contained in figures already described above or to be described below, such a data exchange can take place. However, a corresponding representation in these figures has been omitted for reasons of clarity.
  • FIG. 11 shows those aspect blocks that are contained in a software component that corresponds to an emergency stop button.
  • a software component that corresponds to an emergency stop button.
  • the eleventh software component 320 has a twenty-fourth aspect block 370 associated with the safety control aspect. Further, this software component has a twenty-fifth aspect block 372 associated with the diagnostic aspect. In the twenty-fourth aspect block 370, a release signal which is supplied to an output of the eleventh software component 320 is determined as a function of the quantities supplied to it.
  • a signal representing the state of the emergency stop button 316 is generated.
  • This signal is fed to the twenty-fifth aspect block 372 and is thus available for diagnostic purposes.
  • the twenty-fifth aspect block 372 may also be supplied with the enable signal generated by the twenty-fourth aspect block 370.
  • the following system states of the emergency stop button 316 may be recognized: the emergency stop button is depressed; the contacts of the emergency stop button are glued; the two input signals of the emergency stop button are synchronized.
  • the software component 320 is provided with a functionality parameter deposited in the twenty-fourth aspect block 370.
  • this functionality parameter one of several stored functionalities can now be activated. If the emergency stop button 316 has an acknowledge input, a functionality can be activated by defining a corresponding functionality parameter value, which maps an acknowledge input. In this case, an acknowledge input is evaluated and thus an acknowledge signal applied to it is recorded for further evaluation. On the other hand, if the emergency stop button 316 does not have an acknowledge input, then by setting a corresponding functionality parameter value, a functionality can be activated in which no acknowledge input is mapped. In this case, the evaluation of an acknowledge input is omitted.
  • FIGS. 10 and 11 At least part of the software components and / or aspect blocks contained in a software component embodied as a group component are provided with inputs and / or Outputs of this software component connected.
  • FIGS. 7a, 7bj-7c, 9a, 9b and 9c have omitted the description of corresponding compounds, which, however, should have no restrictive effect.
  • FIG. 12 there is shown the schematic structure of an aspect block, designated in its entirety by the reference numeral 380.
  • the aspect block 380 has an identification unit 382 in which an identifier is stored, which defines the control aspect to which the aspect block is assigned.
  • the aspect block 380 further includes an interface unit 384 that combines a number 386 of inputs and a number 388 of outputs.
  • the number 386 of inputs includes three different types of inputs.
  • a first type of inputs through which aspect sizes 380 and / or intermediate sizes may be applied to aspect block 380.
  • the number 388 of outputs includes three types of outputs.
  • a first type of outputs over which aspect sizes 380 and / or intermediate sizes may be output from the aspect block 380.
  • the aspect block 380 includes a functional unit 390, in which a function program is stored, with which an aspect property of that hardware component is defined, which corresponds to the software component in which the aspect block is contained.
  • the aspect block 380 includes a parameter unit 392 in which parameter values are stored for parameters that are processed in the function program.
  • the linking of the blocks contained in the aspect block 380 has been omitted for the sake of clarity.
  • the function program, which is stored in an aspect block, which is assigned to the diagnostic aspect contains the diagnostic conditions to be evaluated.
  • this function program contains those texts that are to be displayed as messages and remedies depending on the result that is obtained when evaluating the diagnostic conditions.
  • the function program stored in an aspect block associated with the visualization aspect contains those peripheries of the user program that determine the control of a graphical user interface.
  • a graphical user interface for example, data determined during the execution of the user program or arising states of hardware components are displayed using a monitor or display.
  • the function program deposited in an aspect block associated with the standard control aspect determines those control tasks to be executed under standard control for the hardware component corresponding to the software component in which the aspect block is contained. Accordingly, in the function program which is stored in an aspect block which is assigned to the safety control aspect, the control tasks which are to be executed in the context of the safety control are defined.
  • the output signals determined as a function of the input signals are not necessarily output signals in the control-technical sense, output signals being understood to mean output signals in a control-engineering sense, with which an actuator, for example an engine, a cylinder or a contactor is activated.
  • the output signals of an aspect block assigned to the visualization aspect are not output signals in the context of control technology.
  • these output signals determine what an image displayed on a graphical user interface looks like or how information is displayed.
  • the output signals of an aspect block assigned to the diagnostic aspect are not output signals in the context of control technology.
  • the output signals of an aspect block assigned to the standard control aspect or the output signals of a Control aspect associated aspect block to output signals in the control sense.
  • parameter values 392 are stored in the parameterization unit 392.
  • the parameterization to be carried out for this purpose usually takes place at the time of configuration, ie when the user program is created.
  • the input can be fed via the aspect block a parameter and thus the parameter basically determined.
  • the value of the parameter is also set.
  • the parameter value remains unchanged during execution of the user program.
  • no output must be provided in the interface unit via which the parameter can be output.
  • the following approach is also conceivable, in which an interface unit is used which has outputs via which parameters can be output: In a user program, several recipes are stored, which are usually created at the time of configuration.
  • These recipes differ from one another in that at least some of the parameters used in the user program are assigned different values in the individual recipes. Consequently, different parameter values can be stored in a parameterization unit of an aspect block for one and the same parameter.
  • the user program contains a number of test conditions that are used to determine which of the stored recipes should currently be processed. If it is determined during execution of the user program that such a test condition is fulfilled, then switching between individual recipes takes place. A currently processed recipe will be replaced by a recipe to be processed in the future. Accordingly, the parameter value currently assigned to a parameter is replaced by a future valid parameter value. The parameter value changed in this way can be output via a parameterization output and thus made available to other aspect blocks or software components.
  • a parameter value may change during execution of the user program.
  • a software component is designated in its entirety by the reference numeral 400.
  • the software component 400 includes an interface unit 402 in which a number 404 of inputs and a number 406 of outputs are combined.
  • the number 404 of inputs includes three types of inputs
  • the number 406 of outputs includes three types of outputs.
  • FIG. 408 of aspect blocks and a number 410 of elementary and / or group components are included in the software component 400 . The linking of the blocks contained in the software component 400 has been omitted for reasons of clarity.
  • a software component comprises an aspect block associated with the standard control aspect, an aspect block associated with the safety control aspect, and an aspect block associated with the diagnostic aspect.
  • an aspect block associated with the visualization aspect and an aspect block associated with the drive control aspect may be provided.
  • the above enumeration of aspect blocks contained in a software component is exemplary and thus has no conclusive character.
  • the representation chosen in FIG. 13, according to which the software component 400 contains a number 410 of elementary and / or group components is not intended to be limiting. Due to the representation selected in FIG. 13, the software component 400 corresponds to a group component.
  • an elemental component merely contains at least one aspect block and no elementary and / or group components.
  • both a software component and an aspect block correspond to an XML file.
  • the XML file contains the following information: occupancy information representing which quantities and / or parameters and / or sensor signals are basically assigned to the inputs and / or outputs aggregated in the interface unit; Invocation information that represents calls to the function program used to invoke software building blocks in a database, which are software building blocks compliant with the IEC / EN 61131 international standard; the function program stored in the respective aspect block.
  • occupancy information representing which quantities and / or parameters and / or sensor signals are basically assigned to the inputs and / or outputs aggregated in the interface unit
  • Invocation information that represents calls to the function program used to invoke software building blocks in a database, which are software building blocks compliant with the IEC / EN 61131 international standard
  • the function program stored in the respective aspect block In the case of a software component, this is the following information: similarly occupancy information; Information about the software components and / or aspect blocks contained in the software component.
  • the hierarchical structure of the user program is also described as an XML file, which contains the following information: Information about the parameterization of individual aspect blocks; Information about the I / O mapping of individual aspect blocks; Text modules that are contained in individual aspect blocks that are assigned to the diagnostic aspect.
  • Information about the parameterization of individual aspect blocks Information about the I / O mapping of individual aspect blocks
  • Text modules that are contained in individual aspect blocks that are assigned to the diagnostic aspect.
  • any other suitable descriptive language can be used, which is able to map a hierarchical structure.
  • a hierarchical structure is designated in its entirety by the reference numeral 420.
  • This hierarchical structure represents both the hierarchical structure on which the system 210 to be controlled is based, and also the hierarchical structure on which the user program 38 for the safety controller 18 is based.
  • each block has two meanings.
  • the reference number before the slash indicates which hardware component of the system 210 to be controlled represents the respective block.
  • the reference number following the slash indicates which software component the respective block represents in the user program 38.
  • the illustration in FIG. 14 is based on FIGS. 5a, 7a and 9a. This is not intended to be limiting.
  • the structure shown in FIG. 14 can also be transferred to the illustration of FIGS. 5b, 7b and 9b or the illustration of FIGS. 5c, 7c and 9c.
  • Reference numeral 422 denotes a block representing the plant 210 to be controlled in its entirety or the user program 38 in its entirety.
  • the reference numeral 424 denotes a topmost hierarchical level. With regard to the plant 210 to be controlled, this hierarchical level comprises the handling station 212, the process station 214 and the test station 216. These hardware components are referred to as subcomponents.
  • Reference numeral 426 denotes a first hierarchical level which lies directly below the highest hierarchical level.
  • This hierarchical level includes the rotary table 270, the inspection module 272, the drilling module 274, and the ejection module 276. These hardware components are referred to as subcomponents.
  • the reference numeral 428 denotes a second hierarchical level, which lies directly below the first hierarchical level.
  • This hierarchical level includes the motor 310, the transfer cylinder 312 and the drill cylinder 314. These hardware components are referred to as individual components.
  • the first hierarchical level has not been represented for each subcomponent shown and the second hierarchical level is not shown for each subcomponent shown. This is not intended to be limiting. For each of the subcomponents and subcomponents shown in FIG. 14, corresponding hierarchy levels exist. Furthermore, for the sake of clarity, the presentation of all emergency stop buttons was omitted.
  • the system 210 to be controlled is transferred to an operating mode in which the movements of the system 210 to be controlled by the user program 38 take place at a reduced speed.
  • a manufacturing process realized with the plant 210 to be controlled can continue at a reduced speed, while at the same time maintenance work on the plant 210 to be controlled can be carried out.
  • the exemplary embodiment is based on the system 210 to be controlled.
  • This system 210 is controlled by a security controller 18, in which a hierarchically structured user program 38 is executed.
  • a security controller 18 in which a hierarchically structured user program 38 is executed.
  • the provided software components can be embodied both as elemental components and as group components, wherein a hierarchical structure arises on the basis of the software components designed as group components.
  • Logically linking the software components creates a component subprogram.
  • the software components contained in it are also logically linked with each other.
  • Existing aspect blocks may also be associated with the software components.
  • Aspect subprograms related to the individual aspects of control are created for the existing aspect blocks.
  • the component subprogram and the aspect subprograms then together form the user program, wherein the user program represents a sequential control or a sequential control is realized by it.
  • the logical connections in particular those between the software components with each other but also those between the software components on the one hand and the aspect blocks on the other hand can be realized according to different linkage approaches.
  • the complexity of the system to be controlled or the complexity of the sequence control which is to be realized for the system to be controlled or to take into account the processes to be realized.
  • the same linkage approach does not have to be used for all hierarchy levels. It is conceivable to apply different linkage approaches to individual hierarchy levels or even to individual group components. The different applicable linkage approaches will be discussed below.
  • FIGS. 5a, 5b, 5c, 7a, 7b, 7c, 9a, 9b and 9c the complete representation of the logical connections has been omitted for reasons of clarity. This applies in particular to individual aspect blocks contained in the aforementioned figures. This omission of logical connections should have no limiting effect.
  • FIGS. 5a, 7a and 9a are based on the cascaded connection approach.
  • the cascaded linkage approach is used, for example, when the plant to be controlled is a simple plant is and complementarily or alternatively, the process control to be implemented is not very complex.
  • the hardware components contained in the plant to be controlled are each equipped with powerful data processing components. This is reflected in the software components that represent these hardware components.
  • the cascaded linkage approach at least some of the software components are logically linked to one another in such a way that at least a subset of the process control to be implemented is implemented by the logical connections.
  • the illustration in FIGS. 5a, 7a and 9a is based on a first scope of control in addition to the cascaded connection approach and represents a high scope of control. For this reason, numerous aspect blocks are shown in FIGS. 5a, 7a and 9a.
  • an enable signal generated by the emergency stop button 218 may be supplied to the second aspect block 250.
  • the second aspect block 250 may be supplied with signals generated by the sixth aspect block 258 regarding a lock function, such as a lock enable signal for the fourth software component 238, a lock enable signal for the third software component 236, or a lock enable signal for the second software component 234 may act.
  • the signals applied to the second aspect block 250 are linked by means of a logical AND function.
  • total enable signals for the software components 234, 236, 238 are thus generated. For reasons of clarity, the representation of corresponding logical connections between the named software components and the mentioned aspect blocks has been dispensed with.
  • FIGS. 5b, 7b, 9b is also based on the cascaded logic operation, a second scope of control, which represents a lower control scope than the first control scope. For this reason, in FIGS. 5b, 7b and 9b, only the minimum required extent of aspect blocks is provided. 11
  • FIG. 5b aspect blocks corresponding to the first aspect block 248, the second aspect block 250, the fifth aspect block 256, and the sixth aspect block 258 are not included in FIG. 5b.
  • signals are supplied to the software components 234', 236 'and 238'.
  • a start / stop signal possibly generated by the fourth aspect block 254 'is directly supplied to the software components 234', 236 ', and 238'.
  • this start / stop signal is in each case linked to an enable signal provided by the first software component 232 'and to supplied status signals in the form of a logical AND operation.
  • aspect blocks corresponding respectively to the seventh aspect block 294, the eighth aspect block 296, the eleventh aspect block 302, and the twelfth aspect block 304 are not included in FIG. 7b.
  • the representation of logical connections between the ninth aspect block 298 'and the software components 282', 284 ', 286' and 288 ' has been dispensed with.
  • the above explanations regarding the two aspect blocks 252 'and 254' are correspondingly applicable to the two aspect blocks 298 'and 300'.
  • the seventh software component 282' is supplied with two position signals.
  • the values obtained when checking the workpieces for an x-coordinate and for a y-coordinate are available. Any necessary correction can be made.
  • aspect blocks corresponding respectively to the fourteenth aspect block 332 and the eighteenth aspect block 340 are not included in FIG. 9b.
  • an aspect block 338 ' is provided, which is assigned to the drive control aspect.
  • the use of an aspect block that is assigned to the safety control aspect is not mandatory.
  • the enable signal generated by the emergency stop button can be processed by appropriate rounding in the individual software components.
  • the aspect block 338 'associated with the drive control aspect allows the engine 310 represented by the software component 326' to be controlled.
  • the engine speed, the rotational speed or the force generated by the engine can be set to a defined value.
  • the representation of logical connections between the fifteenth aspect block 334 'and the software components 320', 322 ', 324' and 326 ' has been dispensed with.
  • the above statements on the two aspect blocks 252 'and 254' are correspondingly applicable to the two aspect blocks 334 'and 336'. Also in this hierarchical level, it is not necessary or provided that a start / stop signal is generated by the sixteenth aspect block 336 '.
  • FIGS. 5 c, 7 c, 9 c are based on the non-cascaded linkage approach.
  • the non-cascaded linkage approach is used, for example, when the plant to be controlled is a complex plant and, additionally or alternatively, the flow control to be implemented is complex.
  • the hardware components contained in the system to be controlled are each equipped with powerful data processing components. This is reflected in the software components that represent these hardware components.
  • the non-cascaded linkage approach requires at least one aspect block, which is assigned to the standard control aspect, to provide and thus to provide an aspect block which is assigned to the interlocking aspect.
  • an aspect block which is assigned to the drive control aspect, can be provided.
  • an aspect block is to be provided which is assigned to the safety control aspect. This is not absolutely necessary insofar as, for example, with a small amount of safety-relevant sensors, the signals generated by these sensors can be processed directly into the software components by means of rounding.
  • a first aspect block 248 "associated with the standard control aspect is displayed, each based on the second software component 234", the third software component 236 “, and the fourth software component 238" the first aspect block 248 "state signals, so-called” ready signals “supplied.
  • These status signals represent the respective state of the hardware component corresponding to the respective software component.
  • start signals are generated, one of which is supplied to one of the software components 234", 236 “, and 238", respectively.
  • start signals indicate to the respective software component that it is possible to start processing the work steps stored for the associated hardware component.
  • the first aspect block 248 "three self-contained, encapsulated control functions are stored.
  • Fig. 5c The representation chosen in Fig. 5c, according to which the sequence control is based on the processing of transfer signals, more precisely the status signals and the start signals, is not intended to have any restrictive effect.
  • end position sensors can be provided and evaluated.
  • the first Aspect block 248 "instead of the state signals from the end position sensors generated sensor signals . These sensor signals indicate whether or which end position occupies the respective hardware component in response to these sensor signals then the start signals described above can be generated also be transferred to Figs. 7c and 9c.
  • the top hierarchical level contains an aspect block associated with the safety control aspect.
  • the safety logic can not be realized solely by a rounding of individual software components supplied signals, but a more complex safety logic is required. During the rounding, the supplied signals are linked by means of a logical AND function, they are rounded.
  • a third aspect block 252 " signals from the aspect blocks arranged in the same hierarchical level are evaluated
  • the signals of all the aspect blocks arranged in the same hierarchical level are evaluated
  • the third aspect block 252" can also be supplied with signals from one, preferably all, of the Hierarchical level arranged software component can be generated.
  • the signals may be, for example, output signals generated by the aspect blocks or the software components and / or may be signals representing internal quantities generated in the aspect blocks or software components.
  • the diagnostic information corresponding to the detected states is supplied to a fourth aspect block 254 ".
  • a plurality of signals are supplied to a fourth aspect block 254". These signals may be, for example, the status signals and / or the start signals or output signals generated by the third aspect block 252 "and internal signals of the software components and / or the aspect blocks act in the second software component 234 "run piece counter.
  • the fourth aspect block 254 " which is associated with the visualization aspect, has the task of displaying the status of the plant 210 to be controlled and of the safety controller 18.
  • the fourth aspect block 254" is comprised of all software components arranged on the top hierarchy level Aspect blocks fed signals.
  • the fourth aspect block 254 outputs, for example, diagnostic information Additionally or alternatively, it generates data which serve to visualize the process executed with the plant 210 to be controlled and with which, for example, the current processing status of the process can be read.
  • the fourth aspect block 254 may also include an operating functionality in addition to the display functionality, so that in the fourth aspect block 254" the functionality required for realizing an HMI interface is stored.
  • the operating functionality the following embodiment is conceivable, for example:
  • the operator of the system 210 to be controlled can be shown with a plurality of decision options for selection, from which he can select one by touching the display area. For example, the steps required for starting up the system 210 to be controlled can be displayed, whereby the operator must acknowledge their execution by touching the display area. If all these steps have been carried out successfully, a start signal is automatically generated, by means of which the system 210 is put into operation.
  • a stop field by the touch of the operator, the system 210 out of service can take.
  • the start signal and the stop signal are supplied to the first aspect block 248 "Alternatively, a non-interactive display unit may also be used in which the above-described manual start or manual stop can be triggered by means of two buttons.
  • a sixth aspect block 258 is also supplied with the status signals which are also supplied to the first aspect block 248".
  • the sixth aspect block 258 generates "a respective associated lock enable signal for each of the software components 234", 236 ", and 238".
  • the respective lock enable signal With the respective lock enable signal, the respective software component is released and when a corresponding start signal is present, the execution of the respectively stored work steps can be started.
  • the lock enable signals it is ensured that, for example, a hardware component only begins to operate according to the control instructions stored in the user program if other hardware components have assumed a defined basic position.
  • the lock enable signal generated by the sixth aspect block 258 "for the respective software component 234", 236 “and 238” is rounded to a total enable signal applicable to the respective software component with an enable signal generated in the first software component 232 "
  • the lock enable signal and the enable signal generated by the first software component 232" are linked by means of a logical AND function.
  • the individual software components exchange no status signals with one another. Instead, a first aspect block 248 "associated with the standard control aspect and a sixth aspect block 258" associated with the locking aspect are provided.
  • FIG. 5c shows a logical connection between two software components shown in dashed lines, specifically between the two software components 236 "and 238". Over such a logical connection data can be exchanged directly between individual software components.
  • a signal "deviation from the desired value” can be supplied to the third software component 236 "which corresponds to the process station 214. This signal represents the test result achieved in the test station 216. If it is determined, for example, in the test station 216, Thus, due to a wear-related drill shortening, the drilled holes are no longer deep enough, thus, the process station 214 can be made to correspondingly extend the stroke of the drill cylinder.
  • a seventh aspect block 294 "associated with the standard control aspect is shown in Figure 7c. State signals are supplied to each of the seventh aspect block 294" from the software components 282 ", 284", 286 “, and 288", respectively. In addition, the seventh aspect block 294 "from the eighth software component 284", which represents the test module 272, is supplied with a result signal which represents the test result determined in the test module 272.
  • start signals are generated in the seventh aspect block 294, one of each of which is supplied to one of the software components 282 ", 284", 286 “, and 288.”
  • the test result supplied with the result signal there is the possibility that, in the case of a poorly failed test result, the sequence control and thus the process which is executed with the system to be controlled can be interrupted at least to a certain extent be used.
  • a ninth aspect block 298 is associated with the diagnostic aspect and the tenth aspect block 300" is associated with the visualization aspect As for the signals associated with these two aspect blocks Reference is made to the embodiments relating to the two aspect blocks 252 "and 254.” These embodiments are correspondingly applicable to the two aspect blocks 298 “and 300", optionally related to the process station 214.
  • a twelfth aspect block 304 "associated with the latching aspect is supplied with the state signal generated in the ninth software component 286". By evaluating this status signal, a lock enable signal is generated in the twelfth aspect block 304 ", which is supplied to the seventh software component 282". Details of the lock relating to the rotary table 270 and the drilling module 274 can be found in the comments on the twelfth aspect block 304.
  • a release signal is generated by a sixth software component 280 "which is supplied to the software components 282", 284 “, 286", and 288 “in the software components 284", 286 “, and 288” respectively supplied starting signal rounded.
  • the lock release signal is also taken into account during the rounding.
  • a thirteenth aspect block 330 associated with the standard control aspect and an eighteenth aspect block 340" associated with the locking aspect are provided.
  • the thirteenth aspect block 330 is connected to both a twelfth software component 322" representing the drill cylinder and a thirteenth software component 324 "representing the transfer cylinder as part of a control loop. Both starting from the twelfth software component 322 "and on the basis of the thirteenth software component 324" position signals supplied.
  • the position signal generated by the twelfth software component 322 "represents the position of the piston of the drill cylinder and the position signal generated by the thirteenth software component 324" represents the position of the piston of the transfer cylinder. It is sufficient, for example, to distinguish two piston positions. A basic position in which the piston is fully retracted into the cylinder and a working position in which the piston is extended out of the cylinder. These two piston positions can be detected, for example, by using two sensors arranged correspondingly in the respective cylinder. As an alternative to detecting only two piston positions, the exact piston stroke can also be determined, for example, using a mathematical model. For this purpose, preferably the travel command, with which the respective piston is adjusted, more precisely evaluated the adjustment signal and a temporal condition.
  • the two sensors are the twelfth software component 322 "assigned.
  • the software component and the two sensors thus form a programmatic unit.
  • the I / O mapping to be performed for the two sensors must be carried out in the next lower hierarchical level.
  • the two sensors are not dedicated to the twelfth software component 322 ", in which case the I / O mapping is performed at the hierarchical level shown in Figure 9c.
  • an adjustment signal for the drill cylinder 314 is determined and supplied to the twelfth software component 322" in response to the position signal supplied from the twelfth software component 322 "
  • the transfer cylinder 312 determines which of the thirteenth software component 324 "is fed in. With the two adjustment signals, the respective cylinder is driven in. For the extension and retraction, valves arranged in the cylinder are correspondingly actuated Aspect block 330 "generates a start / stop signal, which is fed to a seventeenth aspect block 338.” With this signal, the drive control of the motor 310 stored in the seventeenth aspect block 338 "is started or terminated.
  • an operation status signal is generated and supplied to the eighteenth aspect block 340.
  • the eighteenth aspect block 340 "for realizing a lock function is displayed as to whether the motor 310 is on or off, running or not, this information is important for realizing a lock function the drilling cylinder 314 nor the transfer cylinder 312 are moved as long as the motor 310 is driven and thus drilled with the drilling module 274. For this reason, in the eighteenth aspect block 340 "corresponding stop signals are generated, one of the twelfth software component 322" and one of the thirteenth software component 324 ".
  • the two signals namely the start / stop signal and the operating state signal
  • the use of these two signals advantageously allows a time differentiation.
  • the operating state signal relative to the start / stop signal can be generated with a time delay.
  • the thirteenth aspect block 330 "stores the scope of the user program 38 which determines how the transfer cylinder 312 and the drill cylinder 314 are to be moved and which, for determines when the motor 310 is to be controlled.
  • the order is defined in which the two cylinders 312, 314 and the motor 310 are to be controlled
  • the engine speed may be regulated and thus set to a defined value
  • a corresponding actual value is supplied to the seventeenth aspect block 338 "starting from the software component 326.”
  • a corresponding desired value is determined in dependence on this actual value
  • the seventeenth aspect block 338 "and the fourteenth software component 326" are interconnected as part of a control loop.
  • the extent of user program 38 is the control of motor 310 deposited. In this case, the setpoint is converted into a value for the current with which the motor 310 is to be controlled.
  • the sensors required for detecting the actual values present at the motor 310 are assigned to the fourteenth software component 326 in a program-related manner.
  • the I / O mapping for these sensors then takes place in the next lower hierarchical level.
  • These sensors may, for example, be sensors for detecting the rotational speed or sensors for detecting the voltage applied to the motor windings.
  • FIG. 9c no aspect block is provided which is assigned to the safety control aspect. If, for example, several safety-relevant sensors were present in this hierarchical level, an aspect block would also be used in this hierarchical level, which is assigned to the safety control aspect.
  • Fig. 9c is a fifteenth aspect block 334 "and a sixteen aspect block 336".
  • the fifteenth aspect block 334 " is the diagnostic aspect With regard to the signals supplied to and thus processed in these two aspect blocks, reference is made to the explanations concerning the two aspect blocks 252 "and 254" Mode applicable to the two aspect blocks 334 "and 336".
  • An eleventh software component 320 "generates an enable signal, which is supplied to the software components 322", 324 "and 326" and rounded with any other signals present.
  • FIGS. 5a, 5b, 5c, 7a, 7b, 7c, 9a, 9b and 9c, according to which a suitable aspect block is assigned in the individual hierarchical levels, which is assigned to the diagnostic aspect, should have no restrictive effect.
  • At least one aspect component is provided for at least the following control aspects.
  • Program created Standard control aspect for controlling the non-safety-relevant process flow of the plant taking into account a large part of the hardware components, safety control aspect for controlling all safety-relevant sub-processes and diagnostic aspect for creating and visualizing diagnostic messages.
  • an aspect program can be created for each of the following aspects: drive control, cooling, access authorization, maintenance, locking, manual operation, data management. With such aspect subprograms, the control of a complex plant can be programmed across many different hardware components under a consistent, aspect-related view, with the other aspects being "hidden".

Landscapes

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

Abstract

Das neue Verfahren und die neue Vorrichtung zum Erstellen eines Anwenderprogramms für eine Sicherheitssteuerung weist eine matrixartige Organisation der anfallenden Programmieraufgaben auf, nämlich einerseits aufgegliedert in Software-Komponenten, die jeweils bestimmten Hardware-Komponenten zugeordnet sind, und andererseits aufgegliedert in Aspektblöcke, die eine nach funktionalen Teilaspekten gruppierte Programmierung ermöglichen.

Description

Verfahren und Vorrichtung zum Erstellen eines Anwenderprogramms für eine
Sicherheitssteuerung
Die vorliegende Erfindung betrifft ein Verfahren und eine Vorrichtung zum Erstellen eines Anwenderprogramms für eine Sicherheitssteuerung, die dazu ausgebildet ist, eine Anlage mit einer Vielzahl von Hardware-Komponenten zu steuern, wobei die Vielzahl von Hardware-Komponenten jeweils zumindest einen Sensor und zumindest einen Aktor beinhaltet.
Eine Sicherheitssteuerung im Sinne der vorliegenden Erfindung ist eine Vorrichtung, die von Sensoren gelieferte Eingangssignale aufnimmt und daraus durch logische Verknüpfungen und eventuell weitere Signal- oder Datenverarbeitungsschritte Ausgangssignale erzeugt. Die Ausgangssignale können Aktoren zugeführt werden, die in Abhängigkeit von den Eingangssignalen Aktionen oder Reaktionen in einer gesteuerten Anlage bewirken. Eine Sicherheitssteuerung muss dabei vorgegebene Sicherheitsstandards einhalten, die beispielsweise in der Europäischen Norm EN 954- 1 oder einer vergleichbaren Norm, beispielsweise der Norm IEC 61508 oder der Norm EN ISO 13849-1, niedergelegt sind. Im Gegensatz zu einer Steuerung für so genannte Standardanwendungen gewährleistet eine Sicherheitssteuerung dabei zumindest eine Einfehlersicherheit im Sinne der Kategorien 3 oder 4 der Europäischen Norm EN 954- 1 oder deren Safety Integtity Level (SIL) erreicht zumindest die Stufe 2 gemäß der genannten Norm IEC 61508.
Ein bevorzugtes Anwendungsgebiet für derartige Sicherheitssteuerungen ist die Überwachung von Not-Aus-Tastern, Zwei-Hand-Steuerungen, Schutztüren oder Lichtgittern im Bereich der Maschinensicherheit. Derartige Sensoren werden verwendet, um eine Maschine oder Anlage, von der im Betrieb eine Gefahr für Menschen oder materielle Güter ausgeht, abzusichern. Beim Öffnen der Schutztür oder beim Betätigen des Not-Aus-Tasters wird jeweils ein Signal erzeugt, das die Sicherheitssteuerung als Eingangssignal erhält. In Reaktion darauf schaltet die Sicherheitssteuerung mit Hilfe eines Aktors den Gefahr bringenden Teil der Maschine oder Anlage ab. Eine programmierbare Sicherheitssteuerung bietet dem Anwender die Möglichkeit, die logischen Verknüpfungen und ggf. weiteren Signal- oder Datenverarbeitungsschritte mit Hilfe einer Software, dem genannten Anwenderprogramm, seinen Bedürfnissen entsprechend individuell festzulegen. Daraus resultiert eine große Flexibilität im Vergleich zu früheren Lösungen, bei denen die logischen Verknüpfungen durch eine definierte Verdrahtung zwischen verschiedenen Sicherheitsschaltgeräten erzeugt wurden. Ein Beispiel für ein Verfahren zum Programmieren einer Sicherheitssteuerung ist in DE 101 08 962 Al beschrieben.
Ein Problem bei der Programmierung einer Sicherheitssteuerung besteht darin, dass das Anwenderprogramm bei der Überwachung einer großen Maschinenanlage mit vielen Sicherheitseinrichtungen sehr komplex und unübersichtlich werden kann. So können große Anlagen, wie etwa ein Zementwerk, mehrere tausend Sensoren umfassen. Das zu erstellende Anwenderprogramm ist selbst ein sicherheitskritisches Element, da ein Fehler in dem Anwenderprogramm eine unkontrollierte Situation und damit einen gefährlichen Zustand bei der überwachten Maschine oder Anlage hervorrufen kann.
Um das Risiko folgenschwerer Fehler in dem Anwenderprogramm durch menschliches Versagen bei der Programmierung zu reduzieren, legt das Verfahren nach DE 101 08 962 Al dem Anwender einige Beschränkungen auf. Er kann insbesondere nur auf vorgefertigte, zertifizierte Progammmodule zugreifen und diese nur individuell zusammenfügen. Nach dem Verfahren aus DE 101 08 962 Al kann der Anwender die einzelnen Programmmodule jedoch nicht verändert und auch keine eigenständigen Programmmodule erstellen. Infolge dessen ist das Verfahren aus DE 101 08 962 Al auf Sicherheitssteuerungen für kleinere und mittelgroße Anwendungen beschränkt. Für sehr große Anlagen bietet das Verfahren nach DE 101 08 962 Al keine ausreichende Flexibilität.
Des weiteren ist es bei Anlagen nach dem Stand der Technik von Nachteil, dass Sicherheitssteuerungen häufig in Ergänzung zu einer weitgehend unbeschränkt programmierbaren Standardsteuerung verwendet werden. Es ist wünschenswert, sämtliche Standard- und Sicherheitsaufgaben mit einer gemeinsamen Steuerung zu erledigen. Dies würde die Komplexität der sicherheitsrelevanten Programme jedoch noch weiter erhöhen.
Die internationale Norm IEC/EN 61131 definiert verschiedene Verfahren zum Programmieren von industriellen Steuerungen, teilweise unter Verwendung von Grafikeditoren. Hier werden grafische Elemente entsprechend der Funktionalität der zu steuernden Maschine oder Anlage in Form von so genannten Funktionsblocks bereitgestellt. Dabei kann jede in der Maschine oder Anlage enthaltene Hardware- Komponente einem grafischen Element entsprechen, welches die Funktionalität der zugehörigen Hardware-Komponente darstellt. Die grafischen Elemente können durch logische Verknüpfungen untereinander verbunden. Um bei solchen Verfahren und Vorrichtungen die Komplexität zu reduzieren, kann eine Hierarchisierung verwendet werden, d.h. die grafischen Elemente können dem Aufbau der zu steuernden Maschine oder Anlage entsprechend unterschiedlichen Hierarchieebenen zugeordnet werden. Beim Erstellen des Anwenderprogramms kann dann ebenenweise vorgegangen werden.
Die bekannten Verfahren und Vorrichtungen können dazu beitragen, die Übersichtlichkeit beim Erstellen eines Anwenderprogramms für eine Sicherheitssteuerung zu steigern. Sie sind jedoch gerade in Bezug auf sehr komplexe Anwendungen mit einer großen Anzahl von sicherheitsrelevanten und nicht-sicherheitsrelevanten Sensoren und Aktoren noch nicht optimal.
Es ist daher eine Aufgabe der vorliegenden Erfindung, ein Verfahren und eine Vorrichtung der eingangs genannten Art weiterzubilden, um die Komplexität beim Erstellen eines Anwenderprogramms mit sicherheitsrelevanten Funktionen weiter zu reduzieren und die Übersichtlichkeit zu steigern, um somit eine einfachere, schnellere und kostengünstigere Programmierung einer Sicherheitssteuerung für sehr komplexe Anwendungen zu ermöglichen. Diese Aufgabe wird durch ein Verfahren zum Erstellen eines Anwenderprogramms für eine Sicherheitssteuerung gelöst, die dazu ausgebildet ist, eine Anlage mit einer Vielzahl von Hardware-Komponenten zu steuern, wobei die Vielzahl von Hardware- Komponenten jeweils zumindest einen Sensor und zumindest einen Aktor beinhaltet, mit folgenden Schritten:
Bereitstellen einer Vielzahl von Software-Komponenten für die Vielzahl von Hardware-Komponenten, wobei die Vielzahl von Software-Komponenten jeweils zumindest einen Logikeingang und zumindest einen Logikausgang aufweisen und zumindest einen Aspektblock enthalten, wobei jeder dieser Aspektblöcke einem von mehreren untereinander unterschiedlichen Steuerungsaspekten zugeordnet ist, wobei jeder dieser Steuerungsaspekte einen eigenständigen Teilaspekt der Sicherheitssteuerung repräsentiert, wobei jeder dieser Aspektblöcke eine Anzahl von Signaleingängen und eine Anzahl von Signalausgängen aufweist, wobei dem jeweiligen Aspektblock über seine Anzahl von Signaleingängen eine Anzahl von Eingangssignalen zugeführt werden können und dieser Aspektblock über seine Anzahl von Signalausgängen eine Anzahl von Ausgangssignalen ausgeben kann, und wobei die Ausgangssignale zumindest in Abhängigkeit der Eingangssignalen ermittelt werden,
Erstellen eines Komponententeilprogramms durch logisches Verknüpfen der Vielzahl von Software-Komponenten, wobei zumindest ein Teil der Logikeingänge und zumindest ein Teil der Logikausgänge der Software- Komponenten untereinander verbunden werden,
Erstellen eines Aspektteilprogramms für zumindest einen Steuerungsaspekt, wobei für zumindest einen Aspektblock, der in der Vielzahl von Software- Komponenten enthalten ist, zumindest einem Teil der Signaleingänge Sensoren zugeordnet werden, deren Sensorsignale in dem jeweiligen Aspektblock verarbeitet werden, und wobei zumindest einem Teil der Signalausgänge Aktoren zugeordnet werden, die mit den in dem jeweiligen Aspektblock ermittelten Ausgangssignalen angesteuert werden, Zusammenfügen des Komponententeilprogramms und des Aspektteilprogramms zu dem Anwenderprogramm.
Die Aufgabe wird ferner durch eine Vorrichtung der eingangs genannten Art gelöst, die folgende Einheiten aufweist: erste Einheiten zum Bereitstellen einer Vielzahl von Software-Komponenten für die Vielzahl von Hardware-Komponenten, wobei die Vielzahl von Software-Komponenten jeweils zumindest einen Logikeingang und zumindest einen Logikausgang aufweisen und zumindest einen Aspektblock enthalten, wobei jeder dieser Aspektblöcke einem von mehreren untereinander unterschiedlichen Steuerungsaspekten zugeordnet ist, wobei jeder dieser Steuerungsaspekte einen eigenständigen Teilaspekt zur Sicherheitssteuerung repräsentiert, und wobei jeder dieser Aspektblöcke eine Anzahl von Signaleingängen und eine Anzahl von Signalausgängen aufweist, wobei dem jeweiligen Aspektblock über seine Anzahl von Signaleingängen eine Anzahl von Eingangssignalen zugeführt werden können und dieser Aspektblock über seine Anzahl von Signalausgängen eine Anzahl von Ausgangssignalen ausgeben kann, wobei die Ausgangssignale zumindest in Abhängigkeit von den Eingangssignalen ermittelt werden, zweite Einheiten zum Erstellen eines Komponententeilprogramms durch logisches Verknüpfen der Vielzahl von Software- Komponenten, wobei zumindest ein Teil der Logikeingänge und zumindest ein Teil der Logikausgänge der Software-Komponenten untereinander verbunden werden, dritte Einheiten zum Erstellen eines Aspektteilprogramms für zumindest einen Steuerungsaspekt, wobei zumindest für einen Teil derjenigen Aspektblöcke, die in der Vielzahl von Software-Komponenten enthalten sind, jeweils zumindest einem Teil der Signaleingänge Sensoren zugeordnet werden, deren Sensorsignale in dem jeweiligen Aspektblock verarbeitet werden, und zumindest einem Teil der Signalausgänge Aktoren zugeordnet werden, die mit den in dem jeweiligen Aspektblock ermittelten Ausgangssignalen angesteuert werden, und vierte Einheiten zum Zusammenfügen des Komponententeilprogramms und des Aspektteilprogramms zum Anwenderprogramm.
Dem neuen Verfahren und der neuen Vorrichtung liegt die Idee zugrunde, Aspektblöcke einzuführen und diese beim Erstellen des Anwenderprogramms zu berücksich- tigen. Jeder Aspektblock repräsentiert einen von mehreren untereinander unterschiedlichen Steuerungsaspekten, wobei jeder dieser Steuerungsaspekte eine eigenständige Teilfunktion einer Sicherheitssteuerung repräsentiert. Durch diesen Ansatz steht zusätzlich zu den Software-Komponenten ein weiteres Gliederungswerkzeug zur Verfügung, mit dem die Komplexität beim Erstellen eines Anwenderprogramms für eine Sicherheitssteuerung reduziert werden. Wenn nachfolgend der Begriff Anwenderprogramm verwendet wird oder von dem Erstellen eines Anwenderprogramms die Rede ist, dann soll es sich um ein Steuerprogramm für eine konkrete Steueranwendung handeln, wie zum Beispiel das konkrete Steuerprogramm für eine Fertigungslinie für definierte Werkstücke.
Das Erstellen eines Anwenderprogramms entspricht somit der Realisierung einer Gesamtfunktionalität für die zu steuernde Anlage. In dieser Gesamtfunktionalität sind verschiedene Teilaspekte, etwa die Definition des eigentlichen Fertigungsverlaufs, die sicherheitstechnische Absicherung der Anlage, die Erzeugung und Bereitstellung von Diagnoseinformationen u.a. zusammengefasst. Durch die neuen Aspektblöcke ist es nun möglich, das Erstellen des komplexen Anwenderprogramms in die einzelnen Teilaspekte zu unterteilen. Mit anderen Worten beinhalten das neue Verfahren und die neue Vorrichtung eine matrixartige Organisation der anfallenden Programmieraufgaben, nämlich einerseits aufgegliedert in Software-Komponenten, die jeweils bestimmten Hardware-Komponenten zugeordnet sind, und andererseits aufgegliedert in Aspektblöcke, die eine nach funktionalen Teilaspekten gruppierte Programmierung ermöglichen. Letztere ist vorzugsweise unabhängig von den einzelnen Hardwarekomponenten, wie nachfolgend anhand einiger Ausführungsbeispiele erläutert wird.
Durch die Auswahl eines Teilaspektes und die Konzentration auf den entsprechenden Aspektblock kann eine von mehreren unterschiedlichen Sichten auf die Gesamtfunktionalität und das zu erstellende Anwenderprogramm eingenommen werden. Der Anwender kann auf einzelne Aspekte gerichtete Teilprogramme erstellen, die später zu dem Anwenderprogramm zusammengefügt werden. Dabei werden die Aspektteilprogramme in Ergänzung zu einem Komponententeilprogramm verwendet, das eine Verknüpfung von Software-Komponenten, in denen Aspektblöcke enthalten sind, repräsentiert.
Dadurch dass die unterschiedlichen Steuerungsaspekte jeweils einen separaten Teilaspekt einer Sicherheitssteuerung repräsentieren, können die Aspektteilprogramme eigenständig erstellt werden. Das Erstellen des Anwenderprogramms kann getrennt nach eigenständigen Teilaspekten durch Erstellen einer Vielzahl von eigenständigen Aspektteilprogrammen erfolgen.
Der neue Ansatz entspricht einer vertikalen Unterteilung der Gesamtfunktionalität, die für die zu steuernde Anlage zu realisieren ist. Die eigenständigen Teilaspekte kommen bevorzugt in allen Hierarchieebenen vor, in die eine zu steuernde Anlage gegliedert werden kann. Durch die Betrachtung einzelner Teilaspekte lässt sich die zu realisierende Gesamtfunktionalität vertikal unterteilen.
Mit der neuen Kombination von Komponenten und Aspekten stehen zwei eigenständige Maßnahmen für die Unterteilung der Gesamtfunktionalität zur Verfügung, mit denen sich eine sehr starke Reduzierung der Komplexität und daher eine Steigerung der Übersichtlichkeit realisieren lassen.
Die oben genannte Aufgabe ist vollständig gelöst.
In einer bevorzugten Ausgestaltung der Erfindung entsprechen die Vielzahl von Software-Komponenten der Vielzahl von Hardware-Komponenten.
Diese Maßnahme stellt sicher, dass für jede Hardware-Komponente, die in der zu steuernden Anlage enthalten ist, eine Software-Komponente bereitgestellt wird, die zudem die Funktionalität repräsentiert, die die jeweilige Hardware-Komponente aufweist. Diese Maßnahme trägt zur Übersichtlichkeit bei dem Erstellen des Anwenderprogramms bei und verbessert somit die Fehlersicherheit. In einer weiteren Ausgestaltung der Erfindung wird bei dem Bereitstellen der Vielzahl von Software-Komponenten zumindest eine Software-Komponente aus einer Menge vordefinierter Software-Komponenten ausgewählt.
Diese Ausgestaltung der Erfindung hat den Vorteil, dass innerhalb eines Anwenderprogramms einheitliche Software-Komponenten verwendet werden. So ist sichergestellt, dass für in der zu steuernden Anlage enthaltene identische Hardware- Komponenten, bei entsprechender Auswahl, untereinander identische Software- Komponenten bereitgestellt werden. Durch die Verwendung vordefinierter, d.h. vorgefertigter Software-Komponenten wird somit ausgeschlossen, dass identische Hardware-Komponenten durch Software-Komponenten repräsentiert werden, die untereinander ein unterschiedliches programmtechnisches Verhalten aufweisen. Dies gilt nicht nur für ein einzelnes Anwenderprogramm, sondern auch für eine Vielzahl von Anwenderprogrammen, sofern diese mit Hilfe eines Computerprogramms unter Verwendung ein und derselben Datenbank, die die vordefinierten Software- Komponenten enthält, erstellt wurden. Insgesamt wird durch diese Maßnahme die Übersichtlichkeit erhöht und die Fehlersicherheit verbessert.
Die Verwendung vordefinierter Software-Komponenten bietet einen weiteren Vorteil. Wie bereits erwähnt, benötigen Sicherheitssteuerungen vor ihrer Verwendung eine besondere Zulassung durch zuständige Aufsichtsbehörden. Hiervon ist auch das Anwenderprogramm umfasst. Werden vordefinierte Software-Komponenten verwendet, reicht es aus, diese einmal von einer Aufsichtsbehörde abnehmen zu lassen. Dies erfolgt in der Regel zusammen mit der Abnahme des Computerprogramms, mit dem Anwenderprogramme erstellt werden können. Werden dann bei dem Erstellen eines Anwenderprogramms durch entsprechend sichere Maßnahmen Software- Komponenten durch Auswählen aus einer Menge vordefinierter Software- Komponenten bereitgestellt, ist für denjenigen Teil eines Anwenderprogramms, der ausschließlich solche bereitgestellten Software-Komponenten enthält, keine Abnahme mehr erforderlich. Dadurch wird die Effizienz bei dem Erstellen eines Anwenderprogramms gesteigert. In einer weiteren Ausgestaltung der zuvor genannten Maßnahme repräsentieren die vordefinierten Software-Komponenten jeweils eine von mehreren untereinander unterschiedlichen Hardware-Komponentenarten, wobei jede dieser Hardware- Komponentenarten eine Funktionalität aufweist, die für diese Hardware- Komponentenart als solche charakteristisch ist, und die jede der zu dieser Hardware- Komponentenart zugehörige Hardware-Komponente aufweist, wobei die vordefinierten Software-Komponenten jeweils diejenigen Aspektblöcke enthalten, die denjenigen Steuerungsaspekten zugeordnet sind, die für diejenige Hardware-Komponentenart von Bedeutung sind, die die vordefinierte Software-Komponente repräsentiert.
Diese Maßnahme besitzt den Vorteil, dass in einer vordefinierten Software- Komponente alle relevanten Aspekte zusammengefasst sind, die für diejenige Hardware-Komponentenart von Bedeutung sind, die die vordefinierte Software- Komponente repräsentiert. Die Hardware-Komponentenart wird mit Blick auf die Teilaspekte der Sicherheitssteuerung durch die sie repräsentierende Software- Komponente vollständig beschrieben. Für den Programmierer eines Anwenderprogramms ist es somit völlig ausreichend, für eine in der zu steuernden Anlage befindliche Hardware-Komponente eine Software-Komponente bereitzustellen, und zwar durch Auswählen derjenigen vordefinierten Software-Komponente, die diejenige Hardware-Komponentenart repräsentiert, zu der die Hardware-Komponente gehört. Der Programmierer muss somit für die betreffende Hardware-Komponente nur eine einzige Software-Komponente bereitstellen, es sind nicht mehrere Software- Komponenten oder zusätzliche Aspektblöcke bereitzustellen.
Bei der Funktionalität, die die Hardware-Komponentenart aufweist, kann es sich um eine mechanische oder elektrische oder elektromechanische Funktionalität handeln. Diese Funktionalitäten begründen eine Vielzahl von Unterscheidungsmerkmalen, so dass es sich bei den Hardware-Komponentenarten beispielsweise um Motoren oder um Verstellzylinder, die beispielsweise pneumatisch ausgeführt sind, handeln kann. Neben elementaren Komponenten kann eine Hardware-Komponentenart auch für eine komplexe Baugruppe, beispielsweise Prozessstationen, Teststationen oder Bohr- module stehen. Die Aufzählung elementarer Komponenten und komplexer Baugruppen ist nicht abschließend.
Unter programmtechnischen Gesichtspunkten entspricht eine vordefinierte Software- Komponente einem Platzhalter, der eine Hardware-Komponentenart repräsentiert. Enthält die Anlage eine Hardware-Komponente, die zu einer bestimmten Hardware- Komponentenart gehört, dann wird bei dem Erstellen des Anwenderprogramms eine Software-Komponente durch Auswählen der entsprechenden vordefinierten Software- Komponente bereitgestellt, wobei die bereitgestellte Software-Komponente der in der Anlage vorhandenen realen Hardware-Komponente entspricht. Diese Vorgehensweise kann mit der Vorgehensweise verglichen werden, die der objektorientierten Programmierung zugrunde liegt. Überträgt man die Gesetzmäßigkeiten der objektorientierten Programmierung auf das neue Verfahren, so entspricht die vordefinierte Software-Komponente einer Klasse, d.h. der Gesamtheit aller Objekte der gleichen Art. Die bereitgestellte Software-Komponente entspricht einer Instanz, d.h. einem Objekt einer bestimmten Klasse.
In einer weiteren Ausgestaltung der Erfindung wird von der ausgewählten vordefinierten Software-Komponente eine Kopie erstellt, die dann als Software-Komponente bereitgestellt wird.
Diese Maßnahme besitzt den Vorteil, dass eine vordefinierte Software-Komponente an unterschiedlichen Stellen in einem zu erstellenden Anwenderprogramm verwendet werden kann. Sie ist somit mehrfach verwendbar, sie ist wieder verwertbar. Dabei weisen sämtliche Kopien der vordefinierten Software-Komponente, d.h. sämtliche bereitgestellten Software-Komponenten, die auf dieselbe vordefinierte Software- Komponente zurückgehen, dieselben Eigenschaften auf, die durch die vordefinierte Software-Komponente vorgegeben werden. Die bereitgestellten Software- Komponenten sind lediglich parametrierbar. D.h. deren Funktionalität ist dem Grunde nach durch die vordefinierte Software-Komponenten festgelegt, kann jedoch in gewissen Grenzen leicht modifiziert werden. Dadurch ist sichergestellt, dass in einer zu steuernden Anlage vorhandene identische Hardware-Komponenten durch Software-Komponenten repräsentiert werden, die dem Grunde nach eine identische Funktionalität aufweisen. Insgesamt wird ein effizientes Erstellen eines Anwenderprogramms ermöglicht. Dadurch, dass die bereitgestellten Software-Komponenten jeweils einer Kopie einer vordefinierten Software-Komponente entsprechen, ist gewährleistet, dass in der zu steuernden Anlage vorhandene identische Hardware- Komponenten durch identische Software-Komponenten repräsentiert werden. Dies verbessert die Fehlersicherheit.
Überträgt man die Gesetzmäßigkeit der objektorientierten Programmierung auf das neue Verfahren, so entspricht das Erstellen einer Kopie einer vordefinierten Software- Komponente der Instanzierung.
In einer weiteren Ausgestaltung der Erfindung wird bei dem Bereitstellen der Vielzahl von Software-Komponenten zumindest eine neue Software-Komponente erstellt.
Diese Maßnahme besitzt den Vorteil, bei Bedarf, d.h. entsprechend den Gegebenheiten der zu steuernden Anlage, neue benötigte Software-Komponenten generieren zu können. Dadurch ist ein hohes Maß an Variabilität gewährleistet, beispielsweise für den Fall, dass die in dem Computerprogramm, mit dem das Anwenderprogramm erstellt wird, vorhandenen vordefinierten Software-Komponenten zur Abbildung der Gesamtfunktionalität der zu steuernden Anlage nicht ausreichen.
In einer weiteren Ausgestaltung der Erfindung sind die vordefinierten Software- Komponenten und/oder die neu erstellten Software-Komponenten jeweils entweder als Gruppenkomponente oder als Elementarkomponente ausgebildet, wobei eine Gruppenkomponente zumindest einen Aspektblock und zumindest eine Software- Komponente enthält, wobei die enthaltene Software-Komponente selbst wiederum als Elementarkomponente oder als Gruppenkomponente ausgebildet sein kann, und wobei eine Elementarkomponente lediglich zumindest einen Aspektblock enthält. Durch diese Maßnahme wird ein hohes Maß an Flexibilität erreicht. So kann der Anbieter eines Computerprogramms, mit dem das neue Verfahren durchgeführt werden kann, eine Vielzahl vordefinierter Software-Komponenten für gängige Elementarkomponenten und/oder gängige Gruppenkomponenten in einer umfassenden Datenbank zur Verfügung stellen. Für diese Komponenten ist in der Regel die Abnahme durch eine Aufsichtsbehörde bereits erfolgt, wodurch die Fehlersicherheit verbessert wird.
Mit den neu erstellten Software-Komponenten kann flexibel auf Gegebenheiten, die bei der zu steuernden Anlage vorliegen, reagiert werden. So kann für eine Hardware- Komponente, für die noch keine entsprechende Software-Komponente in der Datenbank hinterlegt ist, eine entsprechende Software-Komponente geschaffen werden, und zwar unabhängig von der Komplexität der Hardware-Komponente. Für eine einfache Hardware-Komponente kann eine als Elementarkomponente ausgebildete und für eine komplexe Hardware-Komponente eine als Gruppenkomponente ausgebildete Software-Komponente geschaffen werden.
Auch besteht die Möglichkeit, wenn ein Programmierer bei dem Erstellen eines Anwenderprogramms feststellt, dass das Erstellen des Anwenderprogramms aufgrund der großen Vielzahl von Software-Komponenten, die für die in der zu steuernden Anlage vorhandene Vielzahl von Hardware-Komponenten benötigt wird, unübersichtlich wird, eine größere Anzahl von Hardware-Komponenten zu einer als Gruppenkomponente ausgebildeten Software-Komponente zusammenzufassen. Diese Modulbildung führt zu einer Reduzierung der Komplexität und somit zu einer Steigerung der Übersichtlichkeit. Insgesamt wird die Fehlersicherheit verbessert.
Die große Flexibilität, die hinsichtlich des Aufbaus von neu zu erstellenden Software- Komponenten gegeben ist, ermöglicht das Erstellen von wieder verwendbaren Software-Komponenten. Dadurch dass eine Software-Komponente als Gruppenkomponente ausgebildet sein kann, kann ein hierarchisch aufgebautes bzw. strukturiertes Anwenderprogramm geschaffen werden. Vorteilhafterweise umfasst das Erstellen einer neuen Elementarkomponente folgende Schritte, wobei die neue Elementarkomponente eine Anzahl von Logikeingängen und eine Anzahl von Logikausgängen aufweist:
Bereitstellen einer Anzahl von Aspektblöcken, die denjenigen Steuerungsaspekten zugeordnet sind, die für diejenige Hardware-Komponente, der die neue Elementarkomponente entspricht, von Bedeutung sind, wobei die Anzahl von Aspektblöcken jeweils als Eingänge neben der Anzahl von Signaleingängen zusätzlich eine Anzahl von Logikeingängen und/oder eine Anzahl von Parametriereingängen und als Ausgänge neben der Anzahl von Signalausgängen zusätzlich eine Anzahl von Logikausgängen und/oder eine Anzahl von Pa- rametrierausgängen aufweisen, wobei der Anzahl von Aspektblöcken jeweils über die Anzahl von Logikeingängen eine Anzahl von Logikgrößen oder eine Anzahl von Zwischengrößen, die jeweils in einem anderen Aspektblock ermittelt wurden, und über die Anzahl von Parametriereingängen eine Anzahl von Parametern zugeführt werden können, und wobei die Anzahl von Aspektblöcken jeweils über die Anzahl von Logikausgängen eine Anzahl von Logikgrößen oder eine Anzahl von Zwischengrößen, die jeweils von einem anderen Aspektblock benötigt werden, und über die Anzahl von Parametrierausgängen eine Anzahl von Parametern ausgeben können,
Festlegen derjenigen Logikgrößen und/oder derjenigen Zwischengrößen und/oder derjenigen Parameter und/oder derjenigen Sensorsignale, die in der Anzahl von Aspektblöcken jeweils zur Verarbeitung benötigt werden, und die über die zugehörigen Eingänge zuzuführen sind,
Festlegen derjenigen Logikgrößen und/oder derjenigen Zwischengrößen und/oder derjenigen Parameter und/oder derjenigen Ausgangssignale, die in der Anzahl von Aspektblöcken jeweils ermittelt und über die zugehörigen Ausgänge ausgegeben werden, Verbinden zumindest eines Teils der Logikeingänge und zumindest eines Teils der Logikausgänge der Anzahl von Aspektblöcken untereinander und/oder mit zumindest einem Teil der Logikeingänge und/oder zumindest einem Teil der Logikausgänge der neuen Elementarkomponente,
Erstellen jeweils eines Funktionsprogramms für zumindest einen Teil der Anzahl von Aspektblöcken, wobei das jeweilige Funktionsprogramm Aspekteigenschaften der Hardware-Komponente für denjenigen Steuerungsaspekt festgelegt, dem der jeweilige Aspektblock zugeordnet ist.
Das Erstellen einer neuen Elementarkomponente gemäß den vorstehend beschriebenen Einzelschritten hat den Vorteil, dass die neue Elementarkomponente programmtechnisch sämtliche Information enthält, um die Funktionalität der Hardware- Komponente, der die neu erstellte Elementarkomponente entspricht, vollständig zu beschreiben bzw. abzubilden.
Durch das Bereitstellen der Anzahl von Aspektblöcken und deren logische Anbindung sind alle Teilaspekte einer Sicherheitssteuerung, die für die Hardware- Komponente von Bedeutung sind, in der neuen Elementarkomponente zusammenge- fasst. Durch das Erstellen der zugehörigen Funktionsprogramme ist die der Hardware- Komponente innewohnende Funktionalität festgelegt. Durch das Festlegen der Größen und/oder Signale ist sichergestellt, dass alle Größen und/oder Signale, die in der neuen Elementarkomponente gemäß der Funktionalität der Hardware- Komponente benötigt werden, zur Verfügung stehen, und dass alle von der neuen Elementarkomponente auszugebenden Größen und/oder Signale bestimmt sind. Somit reicht es aus, zur Erfassung einer in der zu steuernden Anlage enthaltenen Hardware-Komponente, in dem zu erstellenden Anwenderprogramm lediglich die neu erstellte Elementar komponente bereitzustellen.
In einer weiteren Ausgestaltung der zuvor genannten Maßnahme wird in einem weiteren Schritt die neu erstellte Elementarkomponente in einen gekapselten Zu- stand überführt, wobei in diesem Zustand keine Änderungen an der neu erstellten Elementarkomponente vorgenommen werden können.
Die Kapselung der neu erstellten Elementarkomponente bewirkt, dass deren Komponenteneigenschaften verborgen werden. Dies bedeutet, dass der direkte Zugriff auf die innere Datenstruktur der neu erstellten Elementarkomponente unterbunden ist. Ein Zugriff auf die neu erstellte Elementarkomponente ist nur über definierte Schnittstellen, nämlich deren Eingänge und/oder Ausgänge, möglich.
Die Komponenteneigenschaften sind durch die bereitgestellten Aspektblöcke, die in diesen hinterlegten Funktionsprogramme, die logische Anbindung der Aspektblöcke und die festgelegten Größen und/oder Signale, die der neu erstellten Elementarkomponente zuzuführen sind bzw. von dieser ausgegeben werden, festgelegt. Durch die Kapselung der neu erstellten Elementarkomponente wird die Fehlersicherheit verbessert, denn die neu erstellte Elementarkomponente kann lediglich unverändert, d.h. unter Beibehaltung ihrer Eigenschaften, beliebig oft in einem Anwenderprogramm eingesetzt werden. Üblicherweise ist vorgesehen, dass derjenige, der die gekapselte neue Elementarkomponente erstellt hat, zu einem späteren Zeitpunkt durchaus Änderungen an dieser vornehmen kann. Wohingegen der Anwender, der bei dem Erstellen eines Anwenderprogramms eine gekapselte neue Elementarkomponente lediglich bereitstellt, an dieser keine Änderungen vornehmen kann.
Vorteilhafterweise umfasst das Erstellen einer neuen Gruppenkomponente folgende Schritte, wobei die neue Gruppenkomponente eine Anzahl von Logikeingängen und eine Anzahl von Logikausgängen aufweist:
Bereitstellen einer Anzahl von Elementarkomponenten und/oder einer Anzahl von Gruppenkomponenten, wobei die Anzahl von Elementarkomponenten und/oder die Anzahl von Gruppenkomponenten jeweils eine Anzahl von Logikeingängen und eine Anzahl von Logikausgängen aufweist, Bereitstellen einer Anzahl von Aspektblöcken, die denjenigen Steuerungsaspekten zugeordnet sind, die für diejenige Hardware-Komponente, der die neue Gruppenkomponente entspricht, von Bedeutung sind, wobei die Anzahl von Aspektblöcken jeweils als Eingänge neben der Anzahl von Signaleingängen zusätzlich eine Anzahl von Logikeingängen und/oder eine Anzahl von Pa- rametriereingängen und als Ausgänge neben der Anzahl von Signalausgängen zusätzlich eine Anzahl von Logikausgängen und/oder eine Anzahl von Para- metrierausgängen aufweisen, wobei der Anzahl von Aspektblöcken jeweils über die Anzahl von Logikeingängen eine Anzahl von Logikgrößen oder eine Anzahl von Zwischengrößen, die jeweils in einem anderen Aspektblock ermittelt wurden, und über die Anzahl von Parametriereingängen eine Anzahl von Parametern zugeführt werden können, und wobei die Anzahl von Aspektblöcken jeweils über die Anzahl von Logikausgängen eine Anzahl von Logikgrößen oder eine Anzahl von Zwischengrößen, die jeweils von einem anderen Aspektblock benötigt werden, und über die Anzahl von Parametrierausgängen eine Anzahl von Parametern ausgeben können,
Festlegen derjenigen Logikgrößen und/oder derjenigen Zwischengrößen und/oder derjenigen Parameter und/oder derjenigen Sensorsignale, die in der Anzahl von Aspektblöcken jeweils zur Verarbeitung benötigt werden, und über die zugehörigen Eingänge zuzuführen sind,
Festlegen derjenigen Logikgrößen und/oder derjenigen Zwischengrößen und/oder derjenigen Parameter und/oder derjenigen Ausgangssignale, die in der Anzahl von Aspektblöcken jeweils ermittelt, und die über die zugehörigen Ausgänge ausgegeben werden,
Verbinden zumindest eines Teiles der Logikeingänge und zumindest eines Teils der Logikausgänge der Anzahl von Aspektblöcken untereinander und/oder mit zumindest einem Teil der Logikeingänge und/oder zumindest einem Teil der Logikausgänge der Anzahl von Elementarkomponenten und/oder der Anzahl von Gruppenkomponenten und/oder mit zumindest ei- nem Teil der Logikeingänge und/oder mit zumindest einem Teil der Logikausgänge der neuen Gruppenkomponente,
Verbinden zumindest eines Teils der Logikeingänge und zumindest eines Teils der Logikausgänge der Anzahl von Elementarkomponenten und/oder der Anzahl von Gruppenkomponenten untereinander und/oder mit zumindest einem Teil der Logikeingänge und/oder mit zumindest einem Teil der Logikausgänge der neuen Gruppenkomponente,
Erstellen jeweils eines Funktionsprogramms für zumindest einen Teil der Anzahl von Aspektblöcken, wobei das jeweilige Funktionsprogramm Aspekteigenschaften der Hardware-Komponente für den denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspekt zugeordnet ist.
Das Erstellen einer neuen Gruppenkomponente gemäß den vorstehend beschriebenen Einzelschritten hat den Vorteil, dass die neue Gruppenkomponente programmtechnisch sämtliche Information enthält, um die Funktionalität der Hardware- Komponente, der die neu erstellte Gruppenkomponente entspricht, vollständig zu beschreiben bzw. abzubilden.
Durch das Bereitstellen der Anzahl von Aspektblöcken und deren logische Anbindung sind alle Teilaspekte einer Sicherheitssteuerung, die für die Hardware- Komponente von Bedeutung sind, in der neuen Gruppenkomponente zusammenge- fasst. Durch das Bereitstellen der Anzahl von Elementarkomponenten und/oder der Anzahl von Gruppenkomponenten und deren logische Anbindung sind alle in der Hardware-Komponente zusammengefassten Komponenten berücksichtigt. Durch das Erstellen der zugehörigen Funktionsprogramme ist die der Hardware-Komponente innewohnende Funktionalität festgelegt. Durch das Festlegen der Größen und/oder Signale ist sichergestellt, dass alle Größen und/oder Signale, die in der neuen Gruppenkomponente gemäß der Funktionalität der Hardware-Komponente benötigt werden, zur Verfügung stehen, und dass alle von der neuen Gruppenkomponente auszugebenden Größen und/oder Signale bestimmt sind. Somit reicht es aus, zur Erfassung einer in der zu steuernden Anlage enthaltenen Hardware-Komponente, in dem zu erstellenden Anwenderprogramm lediglich die neu erstellte Gruppenkomponente bereitzustellen.
Vorteilhafterweise kann bei einer Gruppenkomponente über einen Funktionalitätsparameter eine von mehreren hinterlegten Funktionalitäten aktiviert oder ausgewählt werden. Vorzugsweise sind diese Funktionalitäten in einer in der Gruppenkomponente enthaltenen Software-Komponente hinterlegt und definieren die Funktionalität dieser Software-Komponente. Jeder dieser Funktionalitäten ist ein definierter Funktionalitätsparameterwert zugewiesen. Somit kann vorzugsweise beim Erstellen einer Gruppenkomponente durch Festlegen des Funktionalitätsparameterwerts eine der hinterlegten Funktionalitäten aktiviert oder ausgewählt werden. Als Beispiel sei eine Software-Komponente angeführt, die einen Not-Aus-Taster repräsentiert. Not- Aus-Taster sind in unterschiedlichsten Ausgestaltungen und somit Funktionalitäten verfügbar, beispielsweise mit oder ohne Acknowledge-Eingang. Durch Festlegen des entsprechenden Funktionalitätsparameterwerts kann nun beim Erstellen der Gruppenkomponente festgelegt werden, ob für diejenige Sofware-Komponente, die einen in einer Hardware-Komponente verbauten Not-Aus-Taster repräsentiert, entsprechend den realen Gegebenheiten eine erste Funktionalität zu aktivieren ist, die einen Achnowledge-Eingang abbildet oder aber eine zweite Funktionalität zu aktivierten ist, bei der kein Acknowledge-Eingang abgebildet ist. Wie dieses konkrete Beispiel des Not- Aus-Tasters zeigt, hat diese Maßnahme den Vorteil, dass nicht für jeden hardwaretechnisch realisierten Not- Aus-Taster jeweils eine eigenständige zugeordnete Software-Komponente vordefiniert werden muss. Stattdessen reicht es aus, eine Software-Komponente vorzudefinieren, die eine Vielzahl von hardwaretechnisch unterschiedlich ausgestalteten Not-Aus-Taster repräsentiert und durch festlegen eines Funktionalitätsparameterwerts an die hardwaretechnischen Gegebenheiten angepasst werden kann. Eine mit einem Funktionalitätsparameter versehene Software- Komponente repräsentiert somit eine Hardware-Komponentenart. Dies trägt zu einer größeren Übersichtlichkeit beim Erstellen des Anwenderprogramms bei und verbessert somit die Fehlersicherheit. Vorzugsweise ist der Funktionalitätsparameterwert in einem Aspektblock hinterlegt, der dem Standardsteuerungsaspekt oder dem Sicher- heitssteuerungsaspekt zugeordnet ist.
Neben der vorstehend beschriebenen bevorzugten Ausführungsform, gemäß der die hinterlegten Funktionalitäten allein die Software-Komponente betreffen, ist es auch denkbar, dass die hinterlegten Funktionalitäten die gesamte Gruppenkomponente betreffen und somit die jeweiligen Funktionalitäten einer Vielzahl von in der Gruppenkomponente enthaltenen Software-Komponenten beeinflussen. Ferner ist es dankbar, neben der vorstehend beschriebenen bevorzugten Vorgehensweise, die Funktionalitätsparameterwerte beim Erstellen einer Gruppenkomponente festzulegen, diese erst beim Erstellen eines Aspekteilprogramms festzulegen. Darüber hinaus ist es auch denkbar, dass eine Elementarkomponente mit einem Funktionalitätsparameter versehen ist, beispielsweise eine Software-Komponente, die einen eigenständigen Not-Aus-Taster repräsentiert.
In einer weiteren Ausgestaltung der zuvor genannten Maßnahme wird in einem weiteren Schritt die neu erstellte Gruppenkomponente in einen gekapselten Zustand überführt, wobei in diesem Zustand keine Änderungen an der neu erstellten Gruppenkomponente vorgenommen werden können.
Die Vorteile, die zuvor für eine neu erstellte Elementarkomponente, die in einen gekapselten Zustand überführt wird, vorgetragen wurden, gelten in entsprechender Weise auch für eine neu erstellte Gruppenkomponente, die in einen gekapselten Zustand überführt wird. Die Komponenteneigenschaften der neu erstellten Gruppenkomponente sind durch die bereitgestellten Aspektblöcke, die in diesen hinterlegten Funktionsprogramme, die logische Anbindung der Aspektblöcke, die bereitgestellten Elementarkomponenten und/oder Gruppenkomponenten und deren logische Anbindung und die festgelegten Größen und/oder Signale, die der neu erstellten Gruppenkomponente zuzuführen sind bzw. von dieser ausgegeben werden, festgelegt. Die Komponenteneigenschaften der neu erstellten Gruppenkomponente umfassen somit auch die Komponenteneigenschaften der in ihr enthaltenen Elementarkomponenten und/oder Gruppenkomponenten. In einer weiteren Ausgestaltung der Erfindung wird von der neu erstellten Software- Komponente eine Kopie erstellt, die dann als Software-Komponente bereitgestellt wird.
Die Vorteile, die zuvor für das Erstellen einer Kopie von der ausgewählten vordefinierten Software-Komponente vorgetragen wurden, gelten in entsprechender Weise auch für eine neu erstellte Software-Komponente, von der eine Kopie erstellt wird.
In einer weiteren Ausgestaltung der Erfindung handelt es sich bei den vordefinierten Software-Komponenten und/oder bei der neu erstellten Software-Komponente jeweils um gekapselte Software-Komponenten, an denen keine Änderungen vorgenommen werden können.
Bezüglich der Vorteile, die sich durch Kapselung der neu erstellten Software- Komponenten ergeben, wird auf die Ausführungen verwiesen, die vorstehend in diesem Zusammenhang für neu erstellte Elementarkomponenten und neu erstellte Gruppenkomponenten vorgetragen wurden. Diese Vorteile gelten in entsprechender Weise auch für vordefinierte Software-Komponenten. Auch deren Komponenteneigenschaften bleiben verborgen. Bei einer vordefinierten Software-Komponente ist üblicherweise vorgesehen, dass von dem Anwender des Computerprogramms, mit dem das neue Verfahren durchgeführt werden kann oder von dem Programmierer, der das Anwenderprogramm erstellt, keine Änderungen an den gekapselten Software- Komponenten vorgenommen werden können. Wohingegen seitens des Herstellers des Computerprogramms sehr wohl Änderungen an den vordefinierten Software- Komponenten vorgenommen werden können. Eine gekapselte Software-Komponente kann in beliebiger Anzahl in einem Anwenderprogramm verwendet werden. Von dieser könnenbeliebig viele Kopien erstellt und bereitgestellt werden.
In einer weiteren Ausgestaltung können die gekapselten Software-Komponenten in einen Bearbeitungsmodus überführt werden, wobei in diesem Bearbeitungsmodus Änderungen an den gekapselten Software-Komponenten vorgenommen werden können.
In dem Bearbeitungsmodus kann eine gekapselte Software-Komponente bearbeitet und somit grundlegende Änderungen an dieser vorgenommen werden. Diese Änderungen werden bei allen Kopien, die von dieser vordefinierten Software-Komponente erstellt wurden, und die in einem Anwenderprogramm als Software-Komponente bereitgestellt sind, berücksichtigt. Diese Änderungen gehen über die Modifikationen hinaus, die an einer Software-Komponente durch die Vorgabe von Parameterwerten vorgenommen werden können. Mit diesen Änderungen soll beispielsweise die Funktionalität einer Software-Komponente an die Steuerungsaufgabe angepasst werden können.
Die beschriebene Maßnahme hat folgenden Vorteil: wird beispielsweise während des Erstellens eines Anwenderprogramms festgestellt, dass eine vordefinierte Software- Komponente die Funktionalität derjenigen Hardware-Komponente, der die vordefi- nierte Software-Komponente entspricht, nicht vollständig umfasst, weil beispielsweise herstellerseitig im Herstellungsprozess Änderungen an der Hardware-Komponente vorgenommen wurden, so kann die vordefinierte Software-Komponente dahingehend bearbeitet werden, dass die Funktionalität vollständig umfasst wird. Auch kann diese Maßnahme dazu verwendet werden, unter Verwendung einer vordefinierten Software-Komponente, eine neue Software-Komponente zu erstellen. Hierzu wird die vordefinierte Software-Komponente in den Bearbeitungszustand überfuhrt und zumindest in einem Teilumfang geändert. Dadurch ist es möglich, eine vordefinierte Software-Komponente, die die Eigenschaften einer Hardware-Komponente nicht umfassend beschreibt, so abzuändern, dass die daraus generierte neue Software- Komponente diese Eigenschaften umfassend beschreibt. Da hierfür auf eine bereits existierende vordefinierte Software-Komponente zurückgegriffen wird, führt dies zu einer Zeitersparnis bei dem Erstellen der neuen Software-Komponente. Insgesamt wird durch die vorstehend beschriebene Ausgestaltung eine größtmögliche Flexibilität beim Erstellen eines Anwenderprogramms erreicht. In einer weiteren Ausgestaltung der zuvor genannten Maßnahme können in dem Bearbeitungsmodus zumindest für einen Teil der Steuerungsaspekte die in den zugeordneten Aspektblöcken jeweils hinterlegten Funktionsprogramme verändert werden.
Durch diese Maßnahme besteht die Möglichkeit, die Funktionalität einer bestehenden Software-Komponente in einfacher Art und Weise an geänderte Gegebenheiten anzupassen. Somit ist eine große Flexibilität beim Erstellen eines Anwenderprogramms gewährleistet.
In einer weiteren Ausgestaltung der zuvor genannten Maßnahme können für denjenigen Steuerungsaspekt, der den Teilaspekt Sicherheitssteuerung repräsentiert, die in den zugeordneten Aspektblöcken jeweils hinterlegten Funktionsprogramme nicht verändert werden.
Durch diese Maßnahme ist sichergestellt, dass die einmal definierte und von einer Aufsichtsbehörde abgenommene Funktionalität für die Sicherheitssteuerung erhalten bleibt. Dies trägt zur Verbesserung der Fehlersicherheit bei. Die für die Sicherheitssteuerung relevante Funktionalität kann somit nicht grundlegend verändert werden. Sie kann lediglich über Parameter in gewissen Grenzen, beispielsweise durch die Vorgabe von entsprechenden Intervallen modifiziert werden.
In einer weiteren Ausgestaltung der Erfindung ist zumindest in einem Teil der in der bereitgestellten Anzahl von Software-Komponenten enthaltenen Aspektblöcken jeweils ein Funktionsprogramm hinterlegt, welches Aspekteigenschaften der Hardware-Komponente für denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspektblock zugeordnet ist, wobei in dem Funktionsprogramm Parameter verarbeitet werden, wobei für die Parameter Parameterwerte vorgegeben werden können, wobei eine Veränderung der Parameterwerte eine Modifikation der Aspekteigenschaften bewirkt. Eine Veränderung der Parameterwerte führt zu einer Modifikation der Aspekteigenschaften. Die Aspekteigenschaften können somit in den Grenzen, die durch die Parameterwerte vorgegeben werden, in einfacher Art und Weise an die Eigenschaften der zu steuernden Anlage angepasst werden. Im Gegensatz zu der Maßnahme, bei der eine gekapselte Software-Komponente in einen Bearbeitungsmodus überführt wird, in welchem grundlegende Änderungen an der Software-Komponente, in erster Linie Änderungen an deren Funktionalität vorgenommen werden können, bleibt bei einer Modifikation der Aspekteigenschaften die Funktionalität der Software-Komponente dem Grunde nach erhalten.
In einer weiteren Ausgestaltung der Erfindung werden die Parameterwerte bei dem Erstellen eines Aspektteilprogrammes für die hierbei berücksichtigten Aspektblöcke vorgegeben.
Das Verknüpfen der beiden Arbeitsschritte Vorgeben der Parameterwerte und Erstellen des Aspektteilprogrammes ermöglicht zum einen ein effizientes Erstellen von Anwenderprogrammen. Zum anderen wird dadurch die Fehlersicherheit verbessert. Durch die gleichzeitige Zuordnung der Sensoren zu den Signaleingängen der Aspektblöcke und die Vorgabe der Parameterwerte wird eine umfassende Betrachtung zu den einzelnen Aspektblöcken angestellt.
In einer weiteren Ausgestaltung der Erfindung ist in den Aspektblöcken jeweils ein Funktionsprogramm hinterlegt, welches Aspekteigenschaften einer Hardware- Komponente für denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspektblock zugeordnet ist, wobei es sich um diejenige Hardware-Komponente handelt, der diejenige Software-Komponente entspricht, die den jeweiligen Aspektblock enthält, wobei zumindest einer der mehreren untereinander unterschiedlichen Steuerungsaspekte und somit die für diesen festgelegten Aspekteigenschaften die Hardware- Komponente als solche betreffen. Diese Maßnahme besitzt den Vorteil, dass für die jeweilige Software-Komponente aspektweise, d.h. bezogen auf den einzelnen Teilaspekt einer Sicherheitssteuerung, die Funktionalitäten und somit Eigenschaften gezielt vorgegeben werden können. Somit kann das Anwenderprogramm präzise erstellt und die Gesamtfunktionalität der zu steuernden Anlage präzise bestimmt werden. Zudem ist sichergestellt, dass sämtliche für die Beschreibung der Funktionalität einer Hardware-Komponente erforderlichen Daten bzw. Information in einer einzigen Software-Komponente enthalten sind. Insgesamt wird durch diese Maßnahme die Fehlersicherheit verbessert.
In einer weiteren Ausgestaltung der Erfindung enthält zumindest ein Teil der bereitgestellten Vielzahl von Software-Komponenten neben einer Anzahl von Aspektblöcken zusätzlich eine Anzahl von Elementarkomponenten und/oder eine Anzahl von Gruppenkomponenten, wobei eine Gruppenkomponente zumindest einen Aspektblock und zumindest eine Software-Komponente enthält, wobei die enthaltene Software-Komponente selbst wiederum als Elementarkomponente oder als Gruppenkomponente ausgebildet sein kann, und wobei eine Elementarkomponente lediglich zumindest einen Aspektblock enthält, wobei in der Anzahl von Aspektblöcken jeweils ein Funktionsprogramm hinterlegt ist, welches Aspekteigenschaften für denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspektblock zugeordnet ist, wobei zumindest einer der mehreren untereinander unterschiedlichen Steuerungsaspekte und somit die für diesen festgelegten Aspekteigenschaften das Zusammenwirken zumindest eines Teils der Anzahl von Elementarkomponenten und/oder zumindest eines Teils der Anzahl von Gruppenkomponenten betrifft.
Die Maßnahme, dass ein Steuerungsaspekt das Zusammenwirken mehrerer Hardware- Komponenten betrifft, die selbst wiederum in einer Hardware-Komponente angeordnet sind, hat folgenden Vorteil: Enthält eine zu steuernde Anlage eine Hardware- Komponente, die mehrere Hardware-Komponenten umfasst, so wird durch das Bereitstellen der Software-Komponente, die dieser Hardware-Komponente entspricht, gleichzeitig die Funktionalität mit bereitgestellt, die das Zusammenwirken der enthaltenen Hardware-Komponenten vorgibt. Hierdurch wird die Komplexität beim Erstel- len eines Anwenderprogramms reduziert und somit die Fehlersicherheit verbessert. Ein Teilaspekt einer Sicherheitssteuerung, der das Zusammenwirken mehrerer Hardware-Komponenten betrifft, ist beispielsweise der Teilaspekt der Verriegelung.
Vorteilhafterweise kann es sich bei den untereinander unterschiedlichen Steuerungsaspekten um eine beliebige Anzahl folgender Steuerungsaspekte handeln: ein Standardsteuerungsaspekt, der den Teilaspekt Standardsteuerung, d.h. den für eine bestimmte Anwendung benötigten Betriebsablauf der Anlage repräsentiert; ein Sicherheitssteuerungsaspekt, der alle Sicherungsmaßnahmen zur Vermeidung von Unfällen repräsentiert; ein Diagnoseaspekt, der die Sammlung und Verarbeitung von Diagnoseinformationen repräsentiert; ein Visualisierungsaspekt, der alle zur Visualisierung von Anlagenzuständen erforderlichen Programmschritte beinhaltet; ein Antriebsregelungsaspekt, der die Details einer oder mehrerer Antriebsregelungen innerhalb der Anlage repräsentiert; ein Kühlungsaspekt, alle zur Kühlung erforderlichen Maßnahmen repräsentiert; ein Zugriffberechtigungsaspekt, der alle Maßnahmen beinhaltet, die eine Zugriffberechtigung betreffen; ein Wartungsaspekt, der alle für die regelmäßige Wartung erforderlichen Programmschritte repräsentiert; ein Verriegelungsaspekt, der den Teilaspekt Verriegelung repräsentiert; ein Handbetriebsaspekt, der den Teilaspekt Handbetrieb repräsentiert; ein Datenverwaltungsaspekt, der den Teilaspekt Datenverwaltung repräsentiert.
Somit können unterschiedliche funktionale Steuerungsaspekte anlagenübergreifend programmiert werden, wobei jeder dieser Steuerungsaspekte einen eigenständigen Teilaspekt der Steuerung repräsentiert. Die eigenständigen Teilaspekte haben untereinander wenig Gemeinsamkeiten, weswegen sie sich dazu eignen, die Gesamtfunktionalität, die für die zu steuernde Anlage zu erstellen ist, in mehrere Teilfunktionalitäten zu unterteilen. Dadurch kann die Komplexität beim Erstellen eines Anwenderprogramms reduziert werden. Zudem wird dadurch die Möglichkeit geschaffen, dass die einzelnen Aspektteilprogramme durch einen jeweiligen Experten erstellt werden können. Insgesamt führt dies zu einer Verbesserung der Fehlersicherheit. Die vorstehend aufgeführten Steuerungsaspekte können in technologiebedingte und in anwendungsbedingte Steuerungsaspekte unterteilt werden. Zu den technologiebedingten Aspekten zählen beispielsweise der Sicherheitssteuerungsaspekt, der Standardsteuerungsaspekt, der Diagnoseaspekt und der Visualisierungsaspekt. Zu den anwendungsbedingten Steuerungsaspekten zählt beispielsweise der Verriegelungsaspekt und der Handbetriebsaspekt.
Der Teilaspekt Standardsteuerung betrifft diejenigen Umfange einer Sicherheitssteuerung, in denen Standardvariablen verarbeitet werden, und die somit nicht sicher ausgelegt sein müssen. Der Teilaspekt Sicherheitssteuerung betrifft diejenigen Umfange einer Sicherheitssteuerung, in denen sichere Variablen verarbeitet werden, und die somit sicher ausgelegt sein müssen. Der Teilaspekt Diagnose betrifft diejenigen Umfange einer Sicherheitssteuerung, die für die Feststellung von Fehlern bzw. Fehlerursachen ausgebildet sind. Der Teilaspekt Visualisierung betrifft diejenigen Umfange einer Sicherheitssteuerung, die für die Darstellung von Daten oder Zuständen von Hardware-Komponenten ausgebildet sind. Auch sollen diejenigen Umfange umfasst sein, die eine Interaktion des Betreibers der Anlage mit der Sicherheitssteuerung ermöglichen. Der Teilaspekt Antriebsregelung betrifft diejenigen Umfange einer Sicherheitssteuerung, die dazu ausgebildet sind, einen Antrieb zu regeln, und zwar im Sinne der Einstellung beispielsweise einer Drehzahl oder einer Geschwindigkeit oder einer Kraft. Der Teilaspekt Kühlung betrifft diejenigen Umfange einer Sicherheitssteuerung, die für die Kühlung von in der zu steuernden Anlage enthaltenen Hardware-Komponenten ausgebildet sind. Der Teilaspekt Zugriffsberechtigung betrifft diejenigen Umfange einer Sicherheitssteuerung, die dazu ausgebildet sind, die zu steuernde Anlage beispielsweise von einer Betriebsart Automatikbetrieb, in der das Anwenderprogramm abgearbeitet wird, in eine Betriebsart Einrichtbetrieb umzuschalten, in welcher Einstellarbeiten an der zu steuernden Anlage durchgeführt werden können. Der Teilaspekt Wartung betrifft diejenigen Umfange einer Sicherheitssteuerung, die auf Maßnahmen zum Erhalt der Funktionsfähigkeit der zu steuernden Anlage gerichtet sind. Der Teilaspekt Verriegelung betrifft diejenigen Umfange einer Sicherheitssteuerung, die dazu ausgebildet sind, dass eine zu steuernde Anlage erst dann angefahren werden kann wenn bestimmte Voraussetzungen erfüllt sind, beispielsweise eine Schutztüre verriegelt ist. Ergänzend oder alternativ betrifft der Teilaspekt Verriegelung auch diejenigen Umfange, die dazu ausgebildet sind, dass eine in der Anlage enthaltene Hardware-Komponente erst dann einen bestimmten Zustand einnehmen kann, wenn eine andere Hardware-Komponente, mit der diese zusammenwirkt, einen vordefinierten Zustand einnimmt. Der Teilaspekt Handbetrieb betrifft diejenigen Umfange einer Sicherheitssteuerung, die dazu ausgebildet sind, die zu steuernde Anlage von einem Automatikbetrieb in einen Handbetrieb umzuschalten, in welchem schrittweise die einzelnen Schritte des Anwenderprogramms abgefahren werden können. Der Teilaspekt Datenverwaltung betrifft diejenigen Umfange einer Sicherheitssteuerung, die dazu ausgebildet sind, Daten zu sammeln und zu speichern (im Sinne von SCADA; Supervisory Control and Data Acquisition).
Die vorstehende Aufzählung ist nicht abschließend. Beispielsweise kann ein Steuerungsaspekt Simulation vorgesehen werden. Mit einem diesem Steuerungsaspekt zugeordneten Aspektblock kann diejenige Software-Komponente geprüft werden, in der dieser Aspektblock enthalten ist. Geprüft werden kann beispielsweise das Verhalten oder die Funktion der Software-Komponente. Es kann auch ein Steuerungsaspekt Dokumentation vorgesehen werden. Ein diesem Steuerungsaspekt zugeordneter Aspektblock dient der Unterstützung desjenigen, der ein Anwenderprogramm erstellt. So ist vorgesehen, dass in einem solchen Aspektblock Information über diejenige Software-Komponente hinterlegt ist, in der der jeweilige Aspektblock enthalten ist. Dabei kann es sich um folgende Information handeln: Beschreibung der Software- Komponente, Beschreibung der Schnittstellen der Software-Komponente, Beschreibung der in der Software-Komponente verwendeten Parameter, Beschreibung der Funktionalität und des möglichen Einsatzes der Software-Komponente. Es ist aber auch denkbar, in solch einem Aspektblock Information für den Betreiber der mit der Sicherheitssteuerung gesteuerten Anlage zu hinterlegen. Dabei kann es beispielsweise um folgende Information handeln: Bedienungsanleitung für diejenige Hardware- Komponente, der die Software-Komponente entspricht, in der der Aspektblock enthalten ist, Einsatzbereich der Hardware-Komponente. Vorzugsweise wird ein Aspektblock durch Auswahl eines konkreten Aspektblockes, der in einer Menge auswählbarer und somit vordefinierter Aspektblöcke enthalten ist, bereitgestellt. Es ist aber auch denkbar, dass derjenige, der ein Anwenderprogramm erstellt, weitere Aspektblöcke applikationsspezifisch erstellen kann, die dann vorteilhafterweise zu den bereits existierenden auswählbaren Aspektblöcken hinzugefügt werden können. Das Erstellen weiterer Aspektblöcke ermöglicht es beispielsweise einem Werkzeugmaschinenhersteller, hinsichtlich deren Profil und/oder deren Struktur unternehmensspezifisch einheitliche Aspektblöcke zu definieren und somit zu verwenden. Die Möglichkeit einen neuen Aspektblock definieren zu können, versetzt den Ersteller eines Anwenderprogramms in die Lage, zu denjenigen Sichten, unter denen die zu steuernde Anlage aufgrund der vordefinierten Aspektblöcke bereits betrachtet werden kann, eine weitere Sicht hinzuzufügen. Somit ist es auch für Aspektblöcke möglich, entsprechend der Vorgehensweise bei den Software- Komponenten, Aspektblöcke durch Auswählen oder Erstellen bereitzustellen.
Das Erstellen eines neuen Aspektblock erfordert im Wesentlichen folgende Schritte: Definieren eines Blockes; Vergeben eines Namens für den neuen Aspektblock; Festlegen des Inhalts des Aspektblockes und somit Definieren eines neuen Teilaspektes. Vorteilhafterweise umfasst der Teilaspekt Antriebsregelung nicht nur Steuerungsaufgaben, die üblicherweise mit einer nicht-sicheren Standardsteuerung, d.h. unter Verwendung nicht-sicherer Standardvariablen ausgeführt werden können und insofern dem Standardsteuerungsaspekt zuzuordnen sind. Vielmehr soll der Teilaspekt Antriebsregelung auch Steuerungsaufgaben umfassen, die sicherheitsrelevant sind und daher dem Sicherheitssteuerungsaspekt zuzuordnen sind und somit unter Verwendung von sicheren Variabein auszuführen sind.
Beispiele für solche dem Sicherheitssteuerungsaspekt zuzuordnenden Steuerungsaufgaben sind die im Rahmen einer „Sicheren Bremskurvenüberwachung" abzuarbeitenden Steuerungsaufgaben oder die im Rahmen einer „Sicheren reduzierten Geschwindigkeit" abzuarbeitenden Steuerungsaufgaben. Die „Sichere Bremskurvenüberwachung" betrifft das kontrollierte Abbremsen eines Motors. Unter Einhaltung einer parametrierten Bremskurve soll der Motor zum Stillstand kommen, wobei über die Parametrierung vorgegeben werden kann, wie steil die Bremskurve abfallen soll. Die parametrierte Bremskurve gibt für verschiedene, innerhalb eines vorgegebenen Zeitintervalls gelegene Zeitpunkte diejenige Drehgeschwindigkeit des Motors vor, die dieser maximal einnehmen darf. Wird festgestellt, dass diese vorgegebenen Werte nicht eingehalten werden, d.h. liegt für einzelne Zeitpunkte die tatsächlich vorliegende Drehgeschwindigkeit des Motors oberhalb der vorgegebenen Werte, so werden beispielsweise als Schütze ausgebildete Aktoren, mit denen der Motor an die Stromversorgung angebunden ist, angesteuert, um den Motor von der Stromversorgung abzutrennen. Die „Sichere reduzierte Geschwindigkeit" bezieht sich vorzugsweise auf den Betrieb eines Roboters im Wartungsmodus. Bei den Wartungsarbeiten soll es durchaus möglich sein, dass der Roboter Bewegungen durchführen kann. Um allerdings das Verletzungsrisiko für das Wartungspersonal so gering wie möglich zu halten, darf die dabei erzielte Bewegungsgeschwindigkeit einen vorgegebenen Wert nicht überschreiten. Dieser vorgegebene Wert wird mittels eines Parameters festgelegt. Während der Wartungsarbeiten wird die aktuell erzielte Bewegungsgeschwindigkeit des Roboters erfasst und mit dem vorgegebenen Wert verglichen. Wird der vorgegebene Wert überschritten, so werden diejenigen Schütze, mit denen der Roboter an die Stromversorgung angeschlossen ist, angesteuert, um den Roboter von der Stromversorgung zu trennen.
In einer weiteren Ausgestaltung der Erfindung werden zusätzlich zu der Vielzahl von Software-Komponenten eine Anzahl von Aspektblöcken bereitgestellt, wobei diese Anzahl von Aspektblöcken bei dem Erstellen eines Aspektteilprogrammes berücksichtigt werden.
Diese Maßnahme besitzt den Vorteil, dass für die Hardware-Komponenten, denen die Vielzahl von bereitgestellten Software-Komponenten entsprechen, Aspekteigenschaften vergeben werden können. Beispielsweise kann somit das Zusammenwirken dieser Hardware-Komponenten, vorzugsweise im Sinne einer Verriegelung, festgelegt werden. In einer weiteren Ausgestaltung der Erfindung ist das Anwenderprogramm hierarchisch strukturiert, wobei durch die bereitgestellte Vielzahl von Software- Komponenten eine Hierarchieebene festgelegt wird, bei der es sich um die oberste Hierarchieebene handelt und wobei durch zumindest eine Software-Komponente, die in einer derjenigen Software-Komponenten enthalten ist, die zu der bereitgestellten Vielzahl von Software-Komponenten gehört, eine weitere, unterhalb der obersten Hierarchieebene liegende Hierarchieebene festgelegt wird.
Diese Ausgestaltung der Erfindung stellt eine Maßnahme dar, mit der die Komplexität bei dem Erstellen eines Anwenderprogramms reduziert werden kann. Somit steht neben der durch den neuen Ansatz begründeten Maßnahme eine zweite Maßnahme zur Reduzierung der Komplexität zur Verfügung. Wie bereits ausgeführt, wird durch die Maßnahme, die durch den neuen Ansatz begründet ist, eine vertikale Unterteilung der Gesamtfunktionalität der zu steuernden Anlage erreicht. Dahingegen bewirkt die Maßnahme der Hierarchisierung aufgrund der unterschiedlichen Hierarchieebenen eine Unterteilung der Gesamtfunktionalität in horizontaler Richtung. Die beiden Maßnahmen haben somit unterschiedliche Ordnungs- oder Gliederungsrichtungen, weswegen sie sich bei gleichzeitiger Anwendung nicht nachteilig gegenseitig beeinflussen. Somit lassen sich diese beiden Maßnahmen bzw. Strukturierungsansät- ze problemlos miteinander kombinieren, weswegen deren Kombination besonders konsequent ist. Die Komplexität lässt sich sehr stark reduzieren und somit die Übersichtlichkeit sehr stark steigern, was letztendlich zu einer sehr starken Verbesserung der Fehlersicherheit führt.
In einer weiteren Ausgestaltung der zuvor genannten Maßnahme werden zusätzlich zu der Vielzahl von Software-Komponenten eine Anzahl von Aspektblöcken bereitgestellt, wobei zumindest ein Teil der Vielzahl von Software-Komponenten und zumindest ein Teil der Anzahl von Aspektblöcken zu einer neuen Software- Komponente zusammengefasst werden können, wodurch eine neue oberste Hierarchieebene festgelegt wird, unterhalb der die bisherige oberste Hierarchieebene als zweitoberste Hierarchieebene liegt. Diese Maßnahme besitzt den Vorteil, dass in einem beliebigen Stadium bei dem Erstellen eines Anwenderprogramms innerhalb der obersten Hierarchieebene ein Teil der Vielzahl von Software-Komponenten unter Berücksichtigung entsprechend erforderlicher Aspektblöcke zu einer neuen Software-Komponente zusammengefasst werden können, um dadurch die in der obersten Hierarchieebene erreichte Komplexität zu reduzieren. Vorteilhafterweise kann diese Maßnahme auch für eine bereits existierende, unterhalb der obersten Hierarchieebene liegende weitere Hierarchieebene in entsprechender Weise angewandt werden. Somit steht eine Maßnahme zur Verfügung, mit der sich für eine beliebige Hierarchieebene die in dieser Hierarchieebene erreichte Komplexität reduzieren lässt.
In einer weiteren Ausgestaltung der Erfindung ist das Anwenderprogramm in eine Vielzahl von Hierarchieebenen strukturiert, von denen eine ausgewählt werden kann, wobei bei dem Erstellen eines Aspektteilprogramms ferner lediglich diejenigen Aspektblöcke berücksichtigt werden, die in der ausgewählten Hierarchieebene enthalten sind.
Diese Maßnahme besitzt den Vorteil, dass die Anzahl der bei dem Erstellen eines Aspektteilprogrammes zu berücksichtigenden Aspektblöcke reduziert werden kann. Dadurch wird die Komplexität beim Erstellen eines Anwenderprogramms weiter reduziert und die Fehlersicherheit weiter verbessert.
Insgesamt sind bei dem Erstellen eines Aspektteilprogrammes alle Aspektblöcke zu berücksichtigen, die dem jeweils betrachteten Steuerungsaspekt zugeordnet sind. Da nun lediglich diejenigen Aspektblöcke berücksichtigt werden, die in der ausgewählten Hierarchieebene enthalten sind, wird für die ausgewählte Hierarchieebene jeweils ein Programmfragment erstellt. Für die nicht ausgewählten Hierarchieebenen wird ebenfalls ein gemeinsames Programmfragment erstellt. Die einzelnen Programmfragmente werden dann zu dem zu erstellenden Aspektteilprogramm zusammengefügt. Eine alternative Vorgehensweise besteht darin, dass für jede der ausgewählten Hierarchieebenen ein eigenständiges Aspektteilprogramm erstellt wird und für die nicht ausgewählten Hierarchieebenen ein gemeinsames Aspektteilprogramm erstellt wird. Dies bedeutet, dass sich die Anzahl der erstellten Aspektteilprogramme erhöht.
In einer weiteren Ausgestaltung der Erfindung kann eine der Hierarchieebenen als Referenzhierarchieebene festgelegt werden, wobei sowohl für die Referenzhierarchieebene als auch für diejenigen Hierarchieebenen, die in der Hierarchie oberhalb der Referenzhierarchieebene liegen, jeweils ein eigenständiges Aspektteilprogramm erstellt wird, wobei beim Erstellen des jeweiligen eigenständigen Aspektteilprogramms lediglich diejenigen Aspektblöcke berücksichtigt werden, die in der jeweiligen Hierarchieebene enthalten sind, und wobei für die Hierarchieebenen, die unterhalb der Referenzhierarchieebene liegen, ein Aspektteilprogramm erstellt wird, wobei beim Erstellen des Aspektteilprogramms sämtliche in diesen Hierarchieebenen enthaltenen Aspektblöcke berücksichtigt werden.
Diese Maßnahme ermöglicht ein besonders effizientes Erstellen eines Anwenderprogramms. Die Referenzhierarchieebene kann so festgelegt werden, dass lediglich diejenigen Hierarchieebenen einer Einzelbetrachtung unterzogen werden, für die dies zu einer merklichen Reduzierung der Komplexität führt. Dagegen werden diejenigen Hierarchieebenen gemeinsam betrachtet, für die die Anzahl der zu berücksichtigenden Aspektblöcke überschaubar ist. Vorteilhafterweise kann die Referenzhierarchieebene vom Programmierer des Anwenderprogramms festgelegt und somit an seine Bedürfnisse angepasst werden.
Vorteilhafterweise weist zumindest ein Teil der Aspektblöcke zumindest folgende Einheiten auf, wobei jeder der Aspektblöcke über eine Anzahl von Eingängen verfügt, über die dem jeweiligen Aspektblock Eingangssignale zugeführt werden können, und über eine Anzahl von Ausgängen verfügt, über die der jeweilige Aspektblock Ausgangssignale ausgeben kann:
eine Identifiziereinheit, in der eine Kennung hinterlegt ist, die denjenigen Steuerungsaspekt festlegt, dem der Aspektblock zugeordnet ist, eine Funktionseinheit, in der ein Funktionsprogramm hinterlegt ist, mit dem eine Aspekteigenschaft derjenigen Hardware-Komponente festgelegt wird, der diejenige Software-Komponente entspricht, in der der Aspektblock enthalten ist,
eine Parametereinheit, in der Parameterwerte für Parameter, die in dem Funktionsprogramm verarbeitet werden, hinterlegt sind,
eine Interfaceeinheit, in der die Anzahl von Eingängen und die Anzahl von Ausgängen des Aspektblockes zusammengefasst sind.
Dieser strukturierte Aufbau der Aspektblöcke ermöglicht zum einen ein effizientes Erstellen eines Anwenderprogramms. Zum anderen gewährleistet er durch die Aufteilung in Funktionseinheit, in Parametereinheit und in Interfaceeinheit ein hinsichtlich Geschwindigkeit und Speicherplatzbedarf optimiertes Anwenderprogramm. Was den Aufbau der Aspektblöcke angeht, so ist es denkbar, dass diese auf jeden Fall jeweils eine Identifiziereinheit, eine Funktionseinheit und eine Interfaceeinheit aufweisen. Die Parametereinheit kann lediglich bei Bedarf, d.h. wenn in dem Funktionsprogramm Parameter vorgesehen sind, vorhanden sein. Diese Vorgehensweise ist hinsichtlich des Speicherplatzbedarfes, der für das erstellte Anwenderprogramm benötigt wird, von Vorteil.
In einer weiteren Ausgestaltung der Erfindung weist zumindest ein Teil der Software- Komponenten zumindest folgende Einheiten auf, wobei jede der Software- Komponenten über eine Anzahl von Eingängen verfugt, über die der jeweiligen Software-Komponente Eingangssignale zugeführt werden können, und über eine Anzahl von Ausgängen verfügt, über die die jeweilige Software-Komponente Ausgangssignale ausgeben kann:
eine Anzahl von Aspektblöcken, eine Anzahl von Elementar- und/oder Gruppenkomponenten, wobei eine Gruppenkomponente zumindest einen Aspektblock und zumindest eine Software-Komponente enthält, wobei die enthaltene Software-Komponente selbst wiederum als Elementarkomponente oder als Gruppenkomponente ausgebildet sein kann, und wobei eine Elementarkomponente lediglich zumindest einen Aspektblock enthält,
eine Interface-Einheit, in der die Anzahl von Eingängen sowie die Anzahl von Ausgängen der Software-Komponente zusammengefasst sind.
Der einheitliche Aufbau der Software-Komponenten gewährleistet Kompatibilität der Software-Komponenten untereinander. Dies ermöglicht ein besonders effizientes Erstellen eines Anwenderprogramms. Gleichzeitig werden mit Blick auf das logische Verknüpfen der Software-Komponenten Fehlerquellen eliminiert, was zur Verbesserung der Fehlersicherheit beiträgt. Vorzugsweise weisen alle Software-Komponenten diesen Aufbau auf.
In einer weiteren Ausgestaltung der Erfindung handelt es sich bei den Eingängen um eine Anzahl von Signaleingängen und/oder um eine Anzahl von Logikeingängen und/oder um eine Anzahl von Parametriereingängen, und bei den Ausgängen um eine Anzahl von Signalausgängen und/oder um eine Anzahl von Logikausgängen und/oder um eine Anzahl von Parametrierausgängen, wobei über die Anzahl von Signaleingängen eine Anzahl von Eingangssignalen und über die Anzahl von Logikeingängen eine Anzahl von Logikgrößen und über die Anzahl von Parametriereingängen eine Anzahl von Parameter zugeführt werden können, und wobei über die Anzahl von Signalausgängen eine Anzahl von Ausgangssignalen und über die Anzahl von Logikausgängen eine Anzahl von Logikgrößen und über die Anzahl von Parametrierausgängen eine Anzahl von Parameter ausgegeben werden können.
Die Bündelung sowohl der Eingänge als auch der Ausgänge in drei Typen von Schnittstellen, nämlich Logikschnittstellen, Parameterschnittstellen und Hardware- Schnittstellen für die Signale gewährleistet ein hohes Maß an Kompatibilität. Dies ermöglicht ein effizientes Erstellen eines Anwenderprogramms. Gleichzeitig werden mögliche Fehler beim Verbinden von Software-Komponenten und/oder von Aspektblöcken reduziert, wodurch die Fehlersicherheit verbessert wird. Die Anzahl der Eingänge und Ausgänge, die dem jeweiligen Schnittstellentyp zugeordnet sind, ist gemäß den jeweiligen Gegebenheiten variabel.
Vorteilhafterweise sind die in den Aspektblöcken jeweils enthaltenen Interfaceeinheiten und die in den Software-Komponenten jeweils enthaltenen Interfaceeinheiten funktionell identisch aufgebaut.
Diese Maßnahme stellt optimale Kompatibilität sicher. So sind die Software- Komponenten untereinander kompatibel. Auch sind die Aspektblöcke untereinander kompatibel. Ferner ist Kompatibilität zwischen Aspektblöcken und Software- Komponenten gewährleistet. Dies ermöglicht einerseits ein effizientes Erstellen eines Anwenderprogramms und andererseits eine Verbesserung der Fehlersicherheit.
In einer weiteren Ausgestaltung der Erfindung ist in den Aspektblöcken jeweils ein Funktionsprogramm hinterlegt, welches Aspekteigenschaften einer Hardware- Komponente für denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspektblock zugeordnet ist, wobei es sich um diejenige Hardware-Komponente handelt, der diejenige Software-Komponente entspricht, die den jeweiligen Aspektblock enthält, wobei die einzelnen Funktionsprogramme unter Verwendung einer Programmiersprache erstellt werden, die jeweils aus einer Vielzahl unterschiedlicher Programmiersprachen ausgewählt wird.
Diese Maßnahme stellt sicher, dass für das Erstellen der einzelnen Funktionsprogramme die jeweils am besten geeignete Programmiersprache zum Einsatz kommt. Dabei kann vorgesehen sein, dass durch das Computerprogramm, mit dem das neue Verfahren durchgeführt werden kann, die nach objektiven Kriterien festgelegte, am besten geeignete Sprache jeweils ausgewählt bzw. vorgegeben wird. Dies kann für einzelne Teilaspekte, beispielsweise den Teilaspekt der Visualisierung oder den Teilaspekt der Diagnose von Vorteil sein. Alternativ oder ergänzend ist vorgesehen, dass der Programmierer, der ein Anwenderprogramm erstellt, nach subjektiven Kriterien die am besten geeignete Programmiersprache auswählen kann. Als Vielzahl unterschiedlicher Programmiersprachen, aus denen ausgewählt werden kann, kommen beispielsweise die in der europäischen Norm IEC/EN 61131 unter Teil 3 aufgeführten Sprachen Instruction List, Ladder Diagram, Function Block Diagram, Sequen- tial Function Chart und Structured Text in Frage. Als weitere Programmiersprache kann auch die Sprache Continious Function Chart berücksichtigt werden. Neben den in der Norm IEC/EN 61131 genannten Programmiersprachen kommt prinzipiell jede Programmiersprache in Frage, die mit der Norm IEC/EN 61499 konform ist, beispielsweise auch die Programmiersprache Java. Für den Teilaspekt Standardsteuerung und den Teilaspekt Sicherheitssteuerung kommen alle in der Norm IEC/EN 61131 genannten Programmiersprachen in Frage. Für den Teilaspekt Visualisierung kann beispielsweise die Programmiersprache OBST verwendet werden. Beim Teilaspekt Diagnose ist eine Aufteilung denkbar. So können die Diagnosebedingungen unter Verwendung einer der in der Norm IEC/EN 61131 genannten Programmiersprachen programmiert werden. Die für die Anzeige der Diagnosemeldungen erforderlichen Umfange können in einer anderen Programmiersprache programmiert werden. Mit der Wahl der am besten geeigneten Programmiersprache wird auch sichergestellt, dass der am besten geeignete Editor zum Einsatz kommt.
Vorteilhafterweise werden die Software-Komponenten und/oder die Aspektblöcke mittels grafischer Symbole auf einer Benutzeroberfläche dargestellt.
Aufgrund dieser Maßnahme ist es möglich, den eigentlichen Vorgang des Program- mierens besonders anschaulich und übersichtlich zu gestalten, wodurch Fehlerquellen aufgrund menschlichen Versagens oder Flüchtigkeit erheblich reduziert werden. Die Fehlersicherheit wird erheblich gesteigert. In einer weiteren Ausgestaltung der Erfindung erfolgt das Bereitstellen der Software- Komponenten und/oder das Bereitstellen der Aspektblöcke unter Verwendung einer Drag & Drop-Funktion.
Eine Drag & Drop-Funktion ist an sich bereits von grafischen Benutzeroberflächen handelsüblicher PCs bekannt. Hierbei wird ein Element mit einem Eingabegerät, beispielsweise mit Hilfe einer sogenannten Maus, markiert und sodann mit Hilfe des Eingabegerätes an eine gewünschte Stelle verschoben oder kopiert. Eine solche Art der Auswahl ist für den Programmierer sehr einfach und komfortabel. Infolgedessen sind Fehlbedienungen und sich daraus ergebende Fehlerquellen beim Programmieren weiter erheblich reduziert.
In einer weiteren Ausgestaltung der Erfindung erfolgt das Verbinden von Eingängen und Ausgängen der Software-Komponenten und/oder das Verbinden von Eingängen und Ausgängen der Aspektblöcke durch Ziehen grafischer Linien.
Diese Maßnahme stellt eine einfache und somit wenig fehleranfällige Handhabe dar. Dadurch wird die Fehlersicherheit verbessert.
In einer weiteren Ausgestaltung der Erfindung wird für eine Vielzahl der untereinander unterschiedlichen Steuerungsaspekte jeweils ein Aspektteilprogramm erstellt, wobei das Erstellen der einzelnen Aspektteilprogramme getrennt erfolgt.
Aufgrund dieser Maßnahme wird die Komplexität bei dem Erstellen eines Anwenderprogramms in starkem Maße reduziert. Das Erstellen der einzelnen Aspektteilprogramme kann vorteilhafterweise zeitlich getrennt erfolgen, so dass zeitlich nacheinander die einzelnen Aspektteilprogramme erstellt werden. Alternativ oder ergänzend kann auch eine räumliche Trennung vorgesehen werden. Bei einer räumlichen Trennung werden die einzelnen Aspektteilprogramme jeweils unter Verwendung einer eigenen grafischen Benutzeroberfläche erstellt. Hierdurch ist es u.a. möglich, mehrere Aspektteilprogramme zeitlich parallel zu erstellen, wenn die einzelnen grafischen Benutzeroberflächen auf einem Monitor dargestellt sind. Dies ermöglicht ein besonders effizientes Erstellen eines Anwenderprogramms.
In einer bevorzugten Ausgestaltung der Erfindung werden bei dem Erstellen eines Aspektteilprogrammes für einen Steuerungsaspekt sämtliche Aspektblöcke, die in der Vielzahl von Software-Komponenten enthalten und diesem Steuerungsaspekt zugeordnet sind, berücksichtigt.
Diese Maßnahme gewährleistet innerhalb eines Steuerungsaspektes eine einheitliche Handhabe und trägt somit zur Verbesserung der Fehlersicherheit bei.
Das neue Verfahren und die neue Vorrichtung haben folgende weitere Vorteile: War bisher der Einsatz verschiedener Computerprogramme oder Werkzeuge für das Erstellen eines Anwenderprogramms erforderlich - üblicherweise musste für jeden Teilaspekt ein anderes verwendet werden - so kommt man nun mit einem einzigen aus. Dadurch werden Kompatibilitätsprobleme vermieden, die auftreten können, wenn das Anwenderprogramm unter Verwendung mehrerer Computerprogramme oder Werkzeuge erstellt wird. Es sind nicht mehrere Computerprogramme oder Werkzeuge zu beherrschen, es reicht aus, sich in eines einzuarbeiten. Bei dem Erstellen eines Anwenderprogramms können alle Teilaspekte ganzheitlich berücksichtigt werden.
Es versteht sich, dass die vorstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, sondern auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
Ausführungsbeispiele der Erfindung sind in der Zeichnung dargestellt und werden in der nachfolgenden Beschreibung näher erläutert. Es zeigen: Fig. 1 eine schematische Darstellung eines Ausführungsbeispiels der neuen
Vorrichtung in Verbindung mit einer Sicherheitssteuerung, für die ein Anwenderprogramm zu erstellen ist,
Fig. 2 eine vereinfachte Darstellung einer ersten grafischen Oberfläche zum
Bereitstellen von Software-Komponenten,
Fig. 3 eine vereinfachte Darstellung einer zweiten grafischen Oberfläche zum
Erstellen eines Komponententeilprogramms und von Aspektteilprogrammen,
Fig. 4 eine schematische Darstellung einer durch das zu erstellende Anwenderprogramm zu steuernden Anlage,
Fig. 5a eine schematische Darstellung der für die zu steuernde Anlage in einer obersten Hierarchieebene des Anwenderprogramms bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem kaskadierten Verknüpfungsansatz und einem ersten Steuerungsumfang,
Fig. 5b eine schematische Darstellung der für die zu steuernde Anlage in einer obersten Hierarchieebene des Anwenderprogramms bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem kaskadierten Verknüpfungsansatz und einem zweiten Steuerungsumfang,
Fig. 5 c eine schematische Darstellung der für die zu steuernde Anlage in einer obersten Hierarchieebene des Anwenderprogramms bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem nicht- kaskadierten Verknüpfungsansatz,
Fig. 6 eine schematische Darstellung einer Teilkomponente der zu steuernden
Anlage, Fig. 7a eine schematische Darstellung der für die Teilkomponente bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem kaskadier- ten Verknüpfungsansatz und einem ersten Steuerungsumfang,
Fig. 7b eine schematische Darstellung der für die Teilkomponente bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem kaskadier- ten Verknüpfungsansatz und einem zweiten Steuerungsumfang,
Fig. 7c eine schematische Darstellung der für die Teilkomponente bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem nicht- kaskadierten Verknüpfungsansatz,
Fig. 8 eine schematische Darstellung einer in der Teilkomponente enthaltenen Unterkomponente und deren Einzelkomponenten,
Fig. 9a eine schematische Darstellung der für die Unterkomponente bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem kaskadierten Verknüpfungsansatz und einem ersten Steuerungsumfang,
Fig. 9b eine schematische Darstellung der für die Unterkomponente bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem kaskadierten Verknüpfungsansatz und einem zweiten Steuerungsumfang,
Fig. 9c eine schematische Darstellung der für die Unterkomponente bereitgestellten Software-Komponenten und Aspektblöcke, gemäß einem nicht-kaskadierten Verknüpfungsansatz,
Fig. 10 eine schematische Darstellung der für eine in der Unterkomponente enthaltenen Einzelkomponente bereitgestellten Aspektblöcke, Fig. 11 eine schematische Darstellung der für einen Not-Aus-Taster bereitgestellten Aspektblöcke,
Fig. 12 in einer schematischen Darstellung den prinzipiellen Aufbau eines
Aspektblockes,
Fig. 13 in einer schematischen Darstellung den prinzipiellen Aufbau einer
Software-Komponente, und
Fig. 14 in einer Übersichtsdarstellung die hierarchische Struktur eines erstellten
Anwenderprogramms .
In Fig. 1 ist ein Ausführungsbeispiel der neuen Vorrichtung in seiner Gesamtheit mit der Bezugsziffer 10 bezeichnet.
Die Vorrichtung 10 beinhaltet einen herkömmlichen PC 12 mit einem Monitor 14, auf dem ein Computerprogramm 16 ausgeführt wird. Das Computerprogramm 16 ermöglicht das Erstellen eines Anwenderprogramms 38 für eine Sicherheitssteuerung. Es wird in der Fachterminologie daher häufig auch als Programmiertool bezeichnet.
Die zu programmierende Sicherheitssteuerung, für die ein Anwenderprogramm zu erstellen ist, ist in Fig. 1 mit der Bezugsziffer 18 bezeichnet. Sie ist hier zweikanalig- redundant aufgebaut, um die erforderliche Fehlersicherheit zum Steuern sicherheitskritischer Prozesse zu erreichen. Stellvertretend für den zweikanaligen Aufbau sind in Fig. 1 zwei voneinander getrennte Prozessoren 20, 22 dargestellt, die über eine bidirektionale Kommunikationsschnittstelle 24 miteinander in Verbindung stehen, um sich gegenseitig kontrollieren und Daten austauschen zu können. Bevorzugt sind die beiden Kanäle der Sicherheitssteuerung 18 und die beiden Prozessoren 20, 22 diversitär, d.h. verschieden voneinander aufgebaut, um systematische Fehler weitgehend auszuschließen. Mit der Bezugsziffer 26 ist eine Ein-/ Ausgabeeinheit bezeichnet, die mit jedem der beiden Prozessoren 20, 22 in Verbindung steht. Die Ein-/Ausgabeeinheit nimmt Eingangssignale 28 von externen Sensoren 30 auf und leitet diese in einem angepass- ten Datenformat an jeden der beiden Prozessoren 20, 22 weiter. Ferner erzeugt die Ein-/Eingabeeinheit in Abhängigkeit von den Prozessoren 20, 22 Ausgangssignale 32, mit denen Aktoren 34 angesteuert werden.
Bei den Sensoren 30 handelt es sich beispielsweise um Not-Aus-Taster, Zwei-Hand- Taster, Schutztürschalter, Drehzahlüberwachungsgeräte, Lichtschranken, Sicherheitsschalter, Endlagenschalter oder andere Sensoren zur Aufnahme sicherheitsrelevanter Größen. Für den bevorzugten Fall, dass die Sicherheitssteuerung auch den Teilaspekt Antriebsregelung umfasst, können die Sensoren 30 auch Sensoren umfassen, die üblicherweise bei Standardsteuerungen eingesetzt werden und mit denen dann im Rahmen der Antriebsregelung eine zu regelnde Größe erfasst werden kann. Beispielsweise kann es sich um Sensoren zur Aufnahme von Kräften oder Geschwindigkeiten oder Drehwinkeln handeln. Die vorstehenden Aufzählungen sollen keinen abschließenden Charakter haben.
Die Aktoren 34 sind beispielsweise Schütze, mit denen die Stromversorgung eines Antriebes oder einer kompletten Maschine abgeschaltet werden kann. Bei den Aktoren 34 kann es sich aber auch um Aktoren zur Realisierung einer Bewegung handeln, beispielsweise Motoren oder Zylinder, insbesondere pneumatisch ausgebildete Zylinder, wie sie beispielsweise für eine Linearbewegung zum Einsatz kommen.
Mit der Bezugsziffer 36 ist eine Chipkarte bezeichnet, auf der hier ein Anwenderprogramm 38 abgespeichert wird. Das Anwenderprogramm 38 wird mit Hilfe der Vorrichtung 10 erstellt und es legt die von der Sicherheitssteuerung 18 durchzuführenden Steuerungsaufgaben fest. Diese Steuerungsaufgaben wiederum legen die Gesamtfunktionalität der mit der Sicherheitssteuerung zu steuernden Anlage fest. Die Verwendung einer Chipkarte 36 als Speichermedium ermöglicht einen einfachen Austausch des Anwenderprogramms 38 auch ohne direkten Anschluss an die Vorrich- tung 10. Alternativ kann das Anwenderprogramm 38 über eine Datenschnittstelle in einen Speicher der Sicherheitssteuerung 18 geladen werden.
Das Computerprogramm 16 stellt auf dem Monitor 14 nachfolgend näher erläuterte Benutzeroberflächen bereit. Die Benutzeroberflächen stellen einem Programmierer Software-Komponenten und Aspektblöcke bereit, und sie ermöglichen ihm das Erstellen eines Komponententeilprogramms und von Aspektteilprogrammen, wobei das Komponententeilprogramm und die Aspektteilprogramme zu dem Anwenderprogramm 38 zusammengefügt werden.
Das Bereitstellen der Software-Komponenten und der Aspektblöcke sowie das Erstellen des Komponententeilprogramms und der Aspektteilprogramme ist in Fig. 1 durch einen Funktionsblock 40 symbolisiert. Nachdem der Programmierer die gewünschten Software-Komponenten und Aspektblöcke bereitgestellt, die Software-Komponenten ggf. parametriert und das Komponententeilprogramm und die Aspektteilprogramme erstellt hat, wird dies alles in einem Speicher 42 des PCs abgespeichert. Bevorzugt wird es dort zusätzlich mit zumindest einer CRC (Cyclic Redundancy Check) Prüfsumme abgesichert. Von dem Speicher 42 aus kann das Anwenderprogramm dann auf die Chipkarte 36 oder direkt auf die Sicherheitssteuerung 18 übertragen werden. Durch Absicherung mit der CRC wird dabei sichergestellt, dass das übertragene Anwenderprogramm mit dem zuvor generierten und im Speicher 42 abgelegten Anwenderprogramm übereinstimmt.
Das Anwenderprogramm 38 enthält hier sowohl Steuerungsaufgaben, die nach dem Stand der Technik üblicherweise mit einer nicht-sicheren Standardsteuerung ausgeführt werden und insofern einem Standardsteuerungsaspekt zuzuordnen sind, als auch Steuerungsaufgaben, die sicherheitsrelevant sind und daher dem Sicherheits- steuerungsaspekt zuzuordnen sind. Die Sicherheitssteuerung 18 verfügt über ein Bussystem, über welches der gesamte Datenaustausch zwischen einzelnen Komponenten der Sicherheitssteuerung 18 läuft, der bei der Abarbeitung des Anwenderprogramms 38 anfällt. D.h. über dieses Bussystem erfolgt der Datenaustausch sowohl für den Fall, dass Steuerungsaufgaben, die dem Standardsteuerungsaspekt zugeordnet sind, als auch Steuerungsaufgaben, die dem Sicherheitssteuerungsaspekt zugeordnet sind, abgearbeitet werden.
In Fig. 2 ist eine erste grafische Oberfläche, die das Computerprogramm 16 dem Programmierer auf dem Monitor 14 bereitstellt, in ihrer Gesamtheit mit der Bezugsziffer 50 bezeichnet.
Die erste grafische Benutzeroberfläche 50 beinhaltet ein Software-Komponenten-Feld 52, welches eine Menge 54 vordefinierter Software-Komponenten in Form von grafischen Symbolen enthält, wobei die einzelnen vordefinierten Software- Komponenten mit den Bezugsziffern 56, 58, 60, 62 bezeichnet sind. Die vordefinierten Software-Komponenten 56 bis 62 wurden vom Anbieter des Computerprogramms 16, mit dem das neue Verfahren zum Erstellen eines Anwenderprogramms 38 durchgeführt werden kann, erstellt und sind in einer in diesem Computerprogramm 16 enthaltenen Datenbank oder Bibliothek abgelegt. Durch die in Fig. 2 für die vordefinierten Software-Komponenten 56 bis 62 vergebenen Bezeichnungen SK 1, SK 2, SK 3 und SK n ist angedeutet, dass die Menge 54 vordefinierter Software- Komponenten mehr als die in Fig. 2 dargestellten vordefinierten Software- Komponenten 52 bis 62 umfassen kann.
Das Software-Komponenten-Feld 52 enthält eine Menge 64 neu erstellter Software- Komponenten in Form von grafischen Symbolen, wobei die einzelnen neu erstellten Software-Komponenten mit den Bezugsziffern 66, 68, 70 bezeichnet sind. Bei den neu erstellten Software-Komponenten 66 bis 70 handelt es sich um solche Software- Komponenten, die vom Programmierer beim Erstellen des Anwenderprogramms 38 für in der zu steuernden Anlage enthaltene Hardware-Komponenten, für die keine entsprechende vordefinierte Software-Komponente in der Datenbank oder Bibliothek des Computerprogramms 16 enthalten sind, erstellt wurden und anschließend gekapselt wurden. In entsprechender Weise sind auch die vordefinierten Software- Komponenten 56 bis 62 gekapselt. Durch die Kapselung wird erreicht, dass die Eigenschaften bzw. die Funktionalität der vordefinierten Software-Komponenten 56 bis 62 und der neu erstellten Software- Komponenten 66 bis 70 nicht mehr verändert werden kann, nachdem diese erstellt wurden. Die für die neu erstellten Software-Komponenten 66 bis 70 verwendeten Bezeichnungen SK n+1, SK n+2 und SK n+3 zeigen an, dass die in dem Computerprogramm 16 enthaltene Datenbank oder Bibliothek um diese Software-Komponenten erweitert wird. Somit können diese Software-Komponenten zu einem späteren Zeitpunkt, wenn beispielsweise ein weiteres Anwenderprogramm erstellt werden soll, zusätzlich zu den herstellerseitig vordefinierten Software-Komponenten 56 bis 62 verwendet werden.
Zur besseren Unterscheidung sind im Software-Komponenten-Feld 52 die vordefinierten Software-Komponenten 56 bis 62 in durchgezogenen Linien dargestellt und die neu erstellten Software-Komponenten 66 bis 70 in gestrichelten Linien dargestellt. Ferner sind im Software-Komponenten-Feld 52 Software-Komponenten, die als so genannte Elementarkomponenten ausgeführt sind, mit einem kleinen Block dargestellt, während Software-Komponenten, die als Gruppenkomponenten ausgeführt sind, mit einem großen Block dargestellt sind. Diese Darstellungsformen haben für die gesamte Fig. 2 Gültigkeit. Ferner sei erwähnt, dass sowohl die vordefinierten Software-Komponenten 56 bis 62, als auch die neu erstellten Software-Komponenten 66 bis 70 jeweils auswählbar sind.
Die erste grafische Benutzeroberfläche 50 beinhaltet ein Aspektblock-Feld 72, welches eine Menge 74 auswählbarer Aspektblöcke in Form von grafischen Symbolen enthält, wobei die einzelnen Aspektblöcke hier mit den Bezugsziffern 76, 78, 80, 82, 84, 86 bezeichnet sind.
Jeder der Aspektblöcke 76 bis 86 ist einem von mehreren untereinander unterschiedlichen Steuerungsaspekten zugeordnet, wobei jeder dieser Steuerungsaspekte einen eigenständigen Teilaspekt der Sicherheitssteuerung repräsentiert. Die für die Aspektblöcke 76 bis 86 verwendeten Bezeichnungen Ab 1, Ab 2, Ab 3, Ab 4, Ab 5, und Ab n sollen andeuten, dass in dem Computerprogramm 16 mehr als die in Fig. 2 darge- stellten Aspektblöcke zur Verfügung stehen können. Die Aspektblöcke 76 bis 86 sind in einer im Computerprogramm 16 enthaltenen Datenbank oder Bibliothek abgelegt.
Die erste grafische Benutzeroberfläche 50 beinhaltet ferner ein Arbeitsfeld 88. Mit Hilfe dieses Arbeitsfeldes 88 können bei dem Erstellen eines Anwenderprogramms 38 vom Programmierer neue Software-Komponenten erstellt werden.
Mit der Bezugsziffer 90 ist eine zu erstellende erste neue Software-Komponente bezeichnet, die als Elementarkomponente ausgeführt ist. Für die zu erstellende erste neue Software-Komponente 90 wird eine Anzahl 92 von Aspektblöcken bereitgestellt. Das Bereitstellen eines Aspektblockes erfolgt, indem der entsprechende in dem Aspektblock-Feld 72 enthaltene Aspektblock 76 bis 86 mit Hilfe einer Drag & Drop- Funktion der zu erstellenden neuen Software-Komponente hinzugefügt wird, wie dies anhand des Pfeils 94 beispielhaft dargestellt ist. In diesem Beispiel wird eine Kopie 96 des ausgewählten Aspektblockes 80 erstellt. Programmtechnisch wird bei diesem Vorgang ein Speicherbereich bereitgestellt, in dem die Funktionalität bzw. die Eigenschaften hinterlegt werden, die der ausgewählte Aspektblock 80 vorgibt. An dieser Stelle sei angemerkt, dass dieser programmtechnische Zusammenhang in entsprechender Weise auch für nachfolgende Ausführungen hinsichtlich des Erstellens einer Kopie eines Aspektblockes und/oder des Erstellen einer Kopie einer Software- Komponente gilt.
Für die bereitgestellte Anzahl 92 von Aspektblöcken sind diejenigen Logikgrößen und/oder diejenigen Zwischengrößen und/oder diejenigen Parameter und/oder diejenigen Signale festzulegen, die dem jeweiligen Aspektblock zur Bearbeitung über zugehörige Eingänge zuzuführen sind oder die von dem jeweiligen Aspektblock ermittelt und von diesem über zugehörige Ausgänge ausgegeben werden. Dieses Festlegen kann beispielsweise durch Zuweisungen erfolgen, die unter Verwendung einer textuellen Programmiersprache in einem Eingabefeld 98 eingegeben werden. In diesem Stadium werden die Größen und/oder Parameter und/oder Signale lediglich dem Grunde nach festgelegt. Die Festlegung der konkreten Sensoren und/oder Aktoren, die mit dem jeweiligen Aspektblock zu verbinden sind, erfolgt in einem späteren, noch zu beschreibenden Schritt.
Jeder Aspektblock enthält Logikeingänge und Logikausgänge. Zumindest ein Teil dieser Logikeingänge und zumindest ein Teil dieser Logikausgänge sind untereinander und/oder mit Logikeingängen und/oder mit Logikausgängen, die die erste neue Software-Komponente 90 aufweist, zu verbinden. Dies ist beispielhaft mit einer Verbindung 100 angedeutet. Diese Verbindungen können beispielsweise grafisch durch Ziehen von Linien erzeugt werden. Dass keine Verbindungen zwischen einem Aspektblock und der ersten neuen Software-Komponente 90 dargestellt ist, soll keine einschränkende Wirkung haben. Aus Gründen der Übersichtlichkeit wird auf die Darstellung der Logikeingänge verzichtet.
Ferner ist zumindest für einen Teil der bereitgestellten Anzahl 92 von Aspektblöcken jeweils ein Funktionsprogramm zu erstellen. Unter Verwendung einer der in der europäischen Norm IEC/EN 61131 beschriebenen Sprachen kann dies jeweils durch Eingabe entsprechender Anweisungen in dem Programmierfeld 98 erfolgen.
Ist die erste neue Software-Komponente 90 erstellt, d.h. sind alle für das Erstellen dieser Software-Komponente erforderlichen Schritte durchgeführt, wird diese Software-Komponente gekapselt und in dem Software-Komponenten-Feld 52 wird eine neu erstellte Software-Komponente 66 angelegt, was durch einen Pfeil 102 angedeutet ist. Diese kann dann in einem noch zu beschreibenden Bereitstellungsfeld 104 bereitgestellt werden, was durch einen Pfeil 106 angedeutet ist. In dem Bereitstellungsfeld 104 wird eine Kopie 108 der neu erstellten Software-Komponente 66 angelegt. Programmtechnisch bedeutet dies, dass ein Speicherbereich reserviert wird, in dem die Funktionalität bzw. die Eigenschaften hinterlegt sind, die durch die neu erstellte Software-Komponente 66 vorgegeben sind.
Alternativ zu der durch die Pfeile 102, 106 dargestellten Abfolge ist es denkbar, dass die erstellte erste neue Software-Komponente 90 direkt in dem Bereitstellungsfeld 104 bereitgestellt wird und nicht erst in das Software-Komponenten-Feld 52 übertragen bzw. in diesem angelegt wird. Nachdem die erste neue Software-Komponente 90 bereitgestellt wurde, kann dann in dem Software-Komponenten-Feld 52 eine neu erstellte Software-Komponente 66 angelegt werden, sofern der Programmierer des Anwenderprogramms dieses wünscht.
Mit der Bezugsziffer 110 ist eine zu erstellende zweite neue Software-Komponente bezeichnet, die als Gruppenkomponente ausgeführt ist. Für die zu erstellende zweite neue Software-Komponente 110 wird eine Anzahl 112 von Aspektblöcken bereitgestellt. Dies ist beispielhaft durch einen Pfeil 114 dargestellt. Die Vorgehensweise entspricht dabei derjenigen, die bereits im Zusammenhang mit der ersten neuen Software-Komponente 90 beschrieben wurde. In diesem Fall wird eine Kopie 116 des Aspektblockes 86 erstellt.
Ferner wird für die zweite neue Software-Komponente 110 eine Anzahl 118 von Elementarkomponenten bereitgestellt. Dies ist durch einen Pfeil 120 angedeutet. Bei diesem Vorgang wird eine Kopie 122 der vordefinierten Software-Komponente 60 erstellt. Programmtechnisch bedeutet dies, dass ein Speicherbereich bereitgestellt wird, in dem die Funktionalität bzw. die Eigenschaften hinterlegt sind, die durch die vordefinierte Software-Komponente 60 vorgegeben sind. Ergänzend oder alternativ werden für die zweite neue Software-Komponente 110 eine Anzahl 124 von Gruppenkomponenten bereitgestellt.
Für die bereitgestellte Anzahl 112 von Aspektblöcken werden jeweils diejenigen Logikgrößen und/oder diejenigen Zwischengrößen und/oder diejenigen Parameter und/oder diejenigen Signale festgelegt, die in dem jeweiligen Aspektblock zur Bearbeitung benötigt werden und diesem über entsprechende Eingänge zuzuführen sind und/oder die von dem jeweiligen Aspektblock ermittelt und über entsprechende Ausgänge von diesem ausgegeben werden. Dies erfolgt wie im Zusammenhang mit der ersten neuen Software-Komponente 90 beschrieben, weswegen bzgl. der konkreten Vorgehensweise und weitergehender Information auf die zugehörigen Ausführungen verwiesen wird. Wie bereits im Zusammenhang mit der ersten neuen Software-Komponente 90 beschrieben, weisen die bereitgestellte Anzahl 112 von Aspektblöcken Logikeingänge und Logikausgänge auf. Ebenfalls weisen die bereitgestellte Anzahl 118 von Elementarkomponenten, die bereitgestellte Anzahl 124 von Gruppenkomponenten und die zu erstellende zweite Software-Komponente 110 selbst jeweils Logikeingänge und Logikausgänge auf. Auf die Darstellung der Logikeingänge und Logikausgänge wird jedoch aus Gründen der Übersichtlichkeit verzichtet.
Nachdem die Größen und/oder Parameter und/oder Signale festgelegt sind, werden anschließend Verbindungen für die zweite neue Software-Komponente 110 erstellt. Hierbei werden zumindest ein Teil der Logikeingänge und zumindest ein Teil der Logikausgänge der Anzahl 112 von Aspektblöcken untereinander und/oder mit zumindest einem Teil der Logikeingänge und/oder zumindest einem Teil der Logikausgänge der Anzahl 118 von Elementarkomponenten und/oder der Anzahl 124 von Gruppenkomponenten und/oder mit zumindest einem Teil der Logikeingänge und/oder mit zumindest einem Teil der Logikausgänge der zweiten neuen Software- Komponente 110 verbunden. Ferner werden zumindest ein Teil der Logikeingänge und zumindest ein Teil der Logikausgänge der Anzahl 118 von Elementarkomponenten und/oder der Anzahl 124 von Gruppenkomponenten untereinander und/oder mit zumindest einem Teil der Logikeingänge und/oder mit zumindest einem Teil der Logikausgänge der zweiten neuen Software-Komponente 110 verbunden. Entsprechend erstellte Verbindungen sind mit der Bezugsziffer 126 bezeichnet. Diese Verbindungen können beispielsweise grafisch durch Ziehen von Linien erzeugt werden. Dass keine Verbindungen zwischen einem Aspektblock oder einer Software- Komponente und der zweiten neuen Software-Komponente 110 und keine Verbindungen zwischen einer Elementarkomponente und einer Gruppenkomponente dargestellt ist, soll keine einschränkende Wirkung haben.
Für zumindest einen Teil der bereitgestellten Anzahl 112 von Aspektblöcken wird jeweils ein Funktionsprogramm erstellt. Dies erfolgt in entsprechender Weise, wie dies im Zusammenhang mit der ersten neuen Software-Komponente 90 beschrieben wurde. Sind alle für das Erstellen der zweiten neuen Software-Komponente 110 erforderlichen Schritte durchgeführt, so wird diese gekapselt und in dem Software- Komponenten-Feld 52 wird eine neu erstellte Software-Komponente 70 angelegt, wie dies durch einen Pfeil 128 angedeutet ist. Die neu erstellte Software-Komponente 70 kann dann, wie dies durch einen Pfeil 130 angedeutet ist, bei dem Erstellen eines Anwenderprogramms in dem Bereitstellungsfeld 104 bereitgestellt werden. Hierbei wird eine Kopie 132 der neu erstellten Software-Komponente 70 erstellt. In entsprechender Weise kann auch die im Zusammenhang mit der ersten neuen Software- Komponente 90 dargelegte alternative Vorgehensweise zum Einsatz kommen.
Für die beiden zu erstellenden neuen Software-Komponenten 90, 110 gilt: Durch das Festlegen der den einzelnen Aspektblöcken zuzuführenden und/oder von diesen auszugebenden Größen und/oder Parametern und/oder Signalen sind automatisch diejenigen Größen und/oder Parameter und/oder Signale festgelegt, die derjenigen Software-Komponente, in der die Aspektblöcke enthalten sind, zuzuführen sind und/oder von dieser ausgegeben werden,. Alternativ kann auch vorgesehen sein, dass diejenigen Größen und/oder Parameter und/oder Signale, die einer Software- Komponente zuzuführen sind und/oder von dieser ausgegeben werden, vom Programmierer des Anwenderprogramms 38 in einem eigenständigen Verfahrensschritt festgelegt werden.
In dem Arbeitsfeld 88 ist eine dritte neue Software-Komponente 134 enthalten. Diese ist als Elementarkomponente ausgebildet, die eine Anzahl 136 von Aspektblöcken enthält. Bei dem Erstellen der dritten neuen Software-Komponente 134 wird von der vordefinierten Software-Komponente 62 ausgegangen. Bei der vordefinierten Software-Komponente 62 handelt es sich um eine gekapselte Software-Komponente. Diese wird in einen Bearbeitungsmodus überführt und in dem Arbeitsfeld 88 wird die dritte neue Software-Komponente 134 angelegt. Die in der Anzahl 136 von Aspektblöcken enthaltenen einzelnen Aspektblöcke, die Verbindungen zwischen diesen Aspektblöcken untereinander und/oder zu der dritten neuen Software-Komponente 134 entsprechen denjenigen, wie sie in der vordefinierten Software-Komponente 62 vorliegen. Aufgrund des Bearbeitungsmodus können nun folgende Änderungen vorgenommen werden: Es können einzelne Aspektblöcke entfernt und/oder hinzugefügt werden; es können Verbindungen zwischen einzelnen Aspektblöcken untereinander und/oder zur dritten neuen Software-Komponente 134 entfernt und/oder hinzugefügt werden; an in bereits vorhandenen Aspektblöcken enthaltenen Funktionsprogramme können jeweils Änderungen vorgenommen werden. Insgesamt kann somit in einfacher Art und Weise auf der Grundlage einer bereits vorhandenen vordefinierten Software-Komponente eine neue Software-Komponente erstellt werden, indem Modifikationen an der bereits vorhandenen Software-Komponente durchgeführt werden.
Das Überführen der vordefinierten Software-Komponente 62 in einen Bearbeitungsmodus und das Anlegen der dritten neuen Software-Komponente 134 ist durch einen Pfeil 138 angedeutet. Sind alle für das Erstellen der neuen Software-Komponente 134 erforderlichen Schritte durchgeführt, so wird diese gekapselt und in dem Software- Komponenten-Feld 52 wird eine neu erstellte Software-Komponente 68 angelegt, wie dies durch einen Pfeil 140 angedeutet ist. Die neu erstellte Software-Komponente 68 kann dann bei dem Erstellen eines Anwenderprogramms bereitgestellt werden, wobei eine Kopie 142 der neu erstellten Software-Komponente 68 in dem Bereitstellungsfeld 104 angelegt wird, wie dies durch einen Pfeil 144 angedeutet ist. Was die konkrete Abfolge angeht, so kann auch die im Zusammenhang mit der ersten neuen Software- Komponente 90 beschriebene alternative Abfolge in Betracht kommen. Die in Fig. 2 gewählte Darstellung, gemäß der die dritte neue Software-Komponente 134 als Elementarkomponente ausgeführt ist, soll keine einschränkende Wirkung haben. In entsprechender Weise kann auch eine neue Software-Komponente auf der Grundlage einer bereits vorhandenen vordefinierten Software-Komponente, die als Gruppenkomponente ausgeführt ist, erstellt werden.
Bei der Betrachtung des Software-Komponenten-Feldes 52 wurde angenommen, dass die neu erstellten Software-Komponenten 66 bis 70 bereits angelegt und somit vorhanden sind. Bei der Betrachtung des Arbeitsfeldes 88 wurde dahingegen angenommen, dass diese Komponenten erst noch zu erstellen sind. Dies stellt keinen Widerspruch dar, da in Fig. 2 zusammenfassend und somit beispielhaft verschiedene Vorgehensweisen bei dem Erstellen eines Anwenderprogramms beschrieben sind.
Bei dem Erstellen eines Anwenderprogramms 38 werden eine Vielzahl 146 von Software-Komponenten bereitgestellt. Wie bereits beschrieben und durch die Pfeile 106, 130, 144 angedeutet, können hierbei neu erstellte Software-Komponenten 66 bis 70 bereitgestellt werden. Ergänzend oder alternativ können auch vordefinierte Software- Komponenten 56 bis 62 bereitgestellt werden, wie dies durch einen Pfeil 148 angedeutet ist. In diesem Fall wird in dem Bereitstellungsfeld 104 eine Kopie 150 der vordefinierten Software-Komponente 56 angelegt. Zusätzlich werden eine Anzahl 152 von Aspektblöcken bereitgestellt, was beispielhaft durch einen Pfeil 154 dargestellt ist. In dem Bereitstellungsfeld 104 wird eine Kopie 156 des Aspektblockes 76 angelegt.
Das Anwenderprogramm 38 ist hierarchisch strukturiert. Durch die bereitgestellte Vielzahl 146 von Software-Komponenten wird eine oberste Hierarchieebene festgelegt. Ist in der bereitgestellten Vielzahl 146 von Software-Komponenten eine Software-Komponente enthalten, die als Gruppenkomponente ausgebildet ist, so wird durch die Anzahl von Software-Komponenten, die in dieser Software-Komponente enthalten ist, eine weitere, unterhalb der oberen Hierarchieebene liegende Hierarchieebene festgelegt. Dies ist beispielsweise für die Kopie 132 der Fall.
In gestrichelten Linien ist angedeutet, dass ein Teil der Vielzahl 146 von Software- Komponenten und ein Teil der Anzahl 152 von Aspektblöcken zu einer neuen Software-Komponente 158 zusammengefasst werden können. Dies ist eine Maßnahme, um die in der betrachteten Hierarchieebene erreichte Komplexität zu reduzieren. Wird solch eine zusammengefasste Software-Komponente 158 in der obersten Hierarchieebene erstellt, so wird dadurch eine neue oberste Hierarchieebene festgelegt, unterhalb der die bisherige Hierarchieebene als zweitoberste Hierarchieebene liegt. Dass das Erstellen einer zusammengefassten Software-Komponente in Zusammenhang mit der obersten Hierarchieebene beschrieben wird, soll keine einschränkende Wirkung haben. So kann eine zusammengefasste Software-Komponente auch in einer unterhalb der obersten Hierarchieebene liegenden Hierarchieebene erstellt werden. In diesem Fall enthält dann das Bereitstellungsfeld 104 nicht die Software- Komponenten und Aspektblöcke der obersten Hierarchieebene, sondern diejenigen der betrachteten Hierarchieebene. Somit kann mit dem neuen Verfahren ein Anwenderprogramm 38 sowohl nach dem "Top-Down"-Konzept als auch nach dem "Bot- tom-Up"-Konzept erstellt werden. Aufgrund der Konzeption des neuen Verfahrens und der neuen Vorrichtung können bei dem Erstellen eines Anwenderprogramms diese beiden Konzepte auch gemischt werden.
Ebenso kann auf einer beliebigen Hierarchieebene ein Aspektblock zugefügt werden. Beispielsweise ist dies bei dem Erstellen einer zusammengefassten Software-Komponente erforderlich. Hierbei kann es sich beispielsweise um einen Aspektblock handeln, der demjenigen Steuerungsaspekt zugeordnet ist, der den Teilaspekt Verriegelung repräsentiert. Nicht nur ein Aspektblock, sondern auch eine Software- Komponente kann auf einer beliebigen Hierarchieebene des Anwenderprogramms eingefügt werden, um eine Reduzierung der Komplexität zu erzielen.
Die in Fig. 2 gewählte Darstellung soll keine einschränkende Wirkung haben. So kann anstelle der gewählten kombinierten Anordnung der einzelnen Felder 52, 72, 88, 98, 104 auch jedes dieser Felder in einer eigenen grafischen Benutzeroberfläche oder eine beliebige Unterkombination jeweils für sich in einer eigenen grafischen Benutzeroberfläche angeordnet sein. Auch kann es vorgesehen sein, dass die neu erstellten Software-Komponenten 66 bis 70 in einem eigenen Software- Komponenten-Feld enthalten sind. Die für das Arbeitsfeld 88 gewählte Darstellung, gemäß der drei neue Software-Komponenten 90, 110, 134 parallel bearbeitet werden, soll keine einschränkende Wirkung haben. Beispielsweise können diese drei neuen Software-Komponenten mittels des Arbeitsfelds 88 auch zeitlich nacheinander und somit einzeln erstellt werden. In Fig. 3 ist eine zweite grafische Benutzeroberfläche in ihrer Gesamtheit mit der Bezugsziffer 170 bezeichnet.
Die zweite grafische Benutzeroberfläche 170 beinhaltet ein Komponenten-Feld 172, in dem eine bereitgestellte Vielzahl 174 von Software-Komponenten angeordnet sind. Hierbei handelt es sich um die Software-Komponenten der obersten Hierarchieebene. Durch logisches Verknüpfen der Vielzahl 174 von Software-Komponenten wird ein Komponententeilprogramm erstellt. Hierzu werden zumindest ein Teil der Logikeingänge und zumindest ein Teil der Logikausgänge der Software-Komponenten untereinander verbunden, was durch eine Vielzahl 176 von Verbindungen dargestellt ist. Aufgrund der in den Software-Komponenten jeweils enthaltenen internen logischen Verknüpfungen werden die in diesen Software-Komponenten angeordneten Elementarkomponenten und/oder Gruppenkomponenten automatisch mit verknüpft. Folglich reicht es aus, bei dem Erstellen des Komponententeilprogramms die in der obersten Hierarchieebene enthaltenen Software-Komponenten untereinander logisch zu verknüpfen. In darunter liegenden Hierarchieebenen enthaltene Software- Komponenten müssen nicht explizit berücksichtigt werden. Die logischen Verknüpfungen für die in der obersten Hierarchieebene enthaltenen Aspektblöcke können beispielsweise in dem Bereitstellungsfeld 104 vorgenommen werden. Alternativ kann dies auch in einem weiteren, eigenständigen Feld vorgenommen werden, wobei auf die Darstellung eines solchen Feldes aus Gründen der Übersichtlichkeit verzichtet wurde. Insgesamt wird zumindest ein Teil der Logikeingänge und zumindest ein Teil der Logikausgänge der Aspektblöcke untereinander und/oder mit zumindest einem Teil der Logikeingänge und/oder zumindest einem Teil der Logikausgänge der bereitgestellten Software-Komponenten verbunden. Somit umfasst das Erstellen des Komponententeilprogramms neben dem vorstehend beschriebenen logischen Verknüpfen der Software-Komponenten auch das vorstehend beschriebene logische Verknüpfen der Aspektblöcke. Bei dem logischen Verknüpfen der Aspektblöcke werden insbesondere durch das Verknüpfen von Logikeingängen und/oder Logikausgängen von Aspektblöcken einerseits mit Logikeingängen und/oder Logikausgängen von Software-Komponenten andererseits ebenfalls logische Verbindungen zwischen Logikeingängen und Logikausgängen von Software-Komponenten realisiert und folglich Logikeingänge und Logikausgänge von Software-Komponenten untereinander verbunden.
Das Bereitstellen einer Vielzahl von Software-Komponenten für die Vielzahl von Hardware-Komponenten bedeutet nicht, dass hierbei nur Software-Komponenten bereitgestellt werden, die Hardware-Komponenten entsprechen, die jeweils zumindest einen Sensor und zumindest einen Aktor beinhalten. Es können auch solche Software-Komponenten bereitgestellt werden, die nicht gleichzeitig zumindest einen Sensor und zumindest einen Aktor beinhalten. Beispielsweise werden auch Software- Komponenten bereitgestellt, die einem sicherheitsrelevanten Sensor, insbesondere einem Not- Aus-Taster entsprechen.
Die zweite grafische Benutzeroberfläche 170 beinhaltet ferner ein erstes Aspektfeld 178. In diesem ersten Aspektfeld 178 sind eine Vielzahl 180 von Aspektblöcken angeordnet. Jeder dieser Aspektblöcke ist demselben Steuerungsaspekt zugeordnet. Im Ausfuhrungsbeispiel soll es sich um den Standardsteuerungsaspekt handeln, der den Teilaspekt Standardsteuerung repräsentiert. Die Vielzahl 180 von Aspektblöcken umfasst die in sämtlichen Hierarchieebenen des Anwenderprogramms 38 enthaltenen Aspektblöcke, die dem Standardsteuerungsaspekt zugeordnet sind, und zwar unabhängig davon, ob sie in einer der Hierarchieebenen eigenständig oder als Teil einer Software-Komponente enthalten sind.
Die zweite grafische Benutzeroberfläche 170 beinhaltet weiter ein Sensorenfeld 182. In diesem Sensorenfeld 182 ist eine Vielzahl 184 von grafischen Sensorsymbolen angeordnet. Für jeden Sensor, der in der zu steuernden Anlage enthalten ist, enthält das Sensorenfeld 182 ein zugehöriges grafisches Sensorsymbol. Die Vielzahl 184 von grafischen Sensorsymbolen repräsentieren sowohl die hinsichtlich des Sicherheits- steuerungsaspektes als auch die hinsichtlich des Standardsteuerungsaspektes in der zu steuernden Anlage enthaltenen Sensoren. Als weiteres Feld enthält die zweite grafische Benutzeroberfläche 170 ein Aktorfeld 186. In diesem Aktorfeld 186 ist eine Vielzahl 188 von grafischen Aktorsymbolen angeordnet. Für jeden Aktor, der in der zu steuernden Anlage enthalten ist, enthält das Aktorfeld 186 ein zugehöriges grafi- sches Aktorsymbol. Die Vielzahl 188 von grafischen Aktorsymbolen umfassen sowohl die hinsichtlich des Sicherheitssteuerungsaspektes als auch die hinsichtlich des Standardsteuerungsaspektes in der zu steuernden Anlage enthaltenen Aktoren.
Für die in dem ersten Aspektfeld 178 enthaltene Vielzahl 180 von Aspektblöcken wird ein Aspektteilprogramm erstellt. Hierzu wird zumindest für einen Teil der in dem ersten Aspektfeld 178 enthaltenen Aspektblöcke sowohl für deren Eingänge als auch für deren Ausgänge ein sog. I/O-Mapping durchgeführt. Das heißt zumindest einem Teil der Signaleingänge werden diejenigen Sensoren zugeordnet, deren Sensorsignale in dem jeweiligen Aspektblock verarbeitet werden. Dies ist beispielhaft durch einen Pfeil 190 dargestellt. Außerdem werden zumindest einem Teil der Signalausgänge Aktoren zugeordnet, die mit den in dem jeweiligen Aspektblock ermittelten Ausgangssignalen angesteuert werden. Dies ist beispielhaft durch einen Pfeil 192 dargestellt. Alternativ kann das I/O-Mapping auch durch textuelle Eingaben in einem Eingabefeld 194 vorgenommen werden. Als weitere Alternative ist es denkbar, das I/O-Mapping auch mittels Ziehen von Linien zwischen einzelnen Aspektblöcken und einzelnen grafischen Sensorsymbolen oder grafischen Aktorsymbolen zu realisieren.
Bei dem Erstellen des Aspektteilprogramms kann gleichzeitig auch das Parametrieren der Aspektblöcke vorgenommen werden. Hierbei können für einzelne Aspektblöcke Parameterwerte für diejenigen Parameter vorgegeben werden, die in den jeweiligen Funktionsprogrammen verwendet werden, die in den jeweiligen Aspektblöcken enthalten sind. Die Parameterwerte können durch textuelle Eingaben in dem Eingabefeld 194 vorgegeben werden.
Die zweite grafische Benutzeroberfläche 170 enthält ferner ein zweites Aspektfeld 196. In dem zweiten Aspektfeld 196 sind eine Vielzahl 198 von Aspektblöcken angeordnet. Im Ausfuhrungsbeispiel sind diese Aspektblöcke einem Sicherheitssteue- rungsaspekt zugeordnet, der den Teilaspekt Sicherheitssteuerung repräsentiert. Auch für diese Aspektblöcke wird ein Aspektteilprogramm erstellt. Das heißt, für diese Aspektblöcke wird ein I/O-Mapping vorgenommen, wie es beispielhaft durch Pfeile 200, 202 dargestellt ist. Einzelheiten hierzu können den Ausführungen zu dem ersten Aspektfeld 178 entnommen werden. Auch bezüglich der gegebenenfalls vorzunehmenden Parametrierung der Aspektblöcke wird auf die Ausführungen zu dem ersten Aspektfeld 178 verwiesen.
Es ist auch denkbar, bei dem Erstellen eines Aspektteilprogrammes gleichzeitig Aspektblöcke, die einem ersten Steuerungsaspekt zugeordnet sind und Aspektblöcke, die einem zweiten Steuerungsaspekt zugeordnet sind, zu berücksichtigen.
An dieser Stelle sei noch folgendes angemerkt: bei den Ausführungen zu Fig. 3 wurde angenommen, dass in den Feldern 178, 182, 186 die entsprechenden Einheiten für die gesamte zu steuernde Anlage angeordnet sind, d.h. für sämtliche Hierarchieebenen. Dies soll keine einschränkende Wirkung haben. Wenn beispielsweise bei dem Erstellen eines Aspektteilprogrammes lediglich eine Hierarchieebene berücksichtigt wird, so können in den Feldern 178, 182, 186 lediglich die in dieser Hierarchieebene enthaltenen Einheiten angeordnet sein.
In Fig. 4 ist ein Beispiel für eine zu steuernde Anlage in ihrer Gesamtheit mit der Bezugsziffer 210 bezeichnet. Die zu steuernde Anlage 210 setzt sich aus drei Teilbereichen zusammen, nämlich einer Handlingstation 212, einer Prozessstation 214 und einer Teststation 216. Mit der Handlingstation 212 wird die Prozessstation 214 mit Werkstücken befüllt. Diese Werkstücke werden in der Prozessstation 214 bearbeitet. Anschließend werden die bearbeiteten Werkstücke von der Handlingstation 212 an die Teststation 216 weitergegeben, in der überprüft wird, ob das bearbeitete Werkstück entsprechende Prüfkriterien erfüllt. Werden diese Prüfungen bestanden, kann die Prozessstation 214 wieder mit einem neuen zu bearbeitenden Werkstück befüllt werden. Darüber hinaus weist die zu steuernde Anlage 210 einen Not-Aus-Taster 218 auf, mit dem die zu Anlage 210 abgeschaltet und in einen sicheren Zustand überführt werden kann. Ferner ist in Fig. 4 eine Anzeigeeinheit 220 dargestellt, mit der beispielsweise Diagnosedaten oder Informationen über den Zustand der zu steuernden Anlage 210 angezeigt werden können. Die Anlage 210 wird durch die Sicherheitssteuerung 18 gesteuert. In Fig. 5a sind diejenigen Software-Komponenten und Aspektblöcke für die zu steuernde Anlage 210 dargestellt, die in der obersten Hierarchieebene enthalten sind.
Insgesamt wird eine Vielzahl 230 von Software-Komponenten für die zu steuernde Anlage 210 bereitgestellt, wobei es sich im Einzelnen um folgende Software- Komponenten handelt: eine erste Software-Komponente 232, die dem Not-Aus-Taster 218 entspricht und als Einzelkomponente ausgebildet ist. Eine zweite Software- Komponente 234, die der Handlingstation 212 entspricht. Eine dritte Software- Komponente 236, die der Prozessstation 214 entspricht. Eine vierte Software- Komponente 238, die der Teststation 316 entspricht. Wobei die Software- Komponenten 234, 236, 238 jeweils als Gruppenkomponente ausgebildet sind. Sowie eine fünfte Software-Komponente 240, die der Anzeigeeinheit 220 zugeordnet ist und die als Elementarkomponente ausgebildet ist. Jede der bereitgestellten Software- Komponenten 234, 236, 238 repräsentiert eine in der zu steuernden Anlage vorhandene, reale mechatronische Komponente.
Die erste Software-Komponente 232 ist über eine erste Logikverbindung 242 mit der zweiten Software-Komponente 234, mit der dritten Software-Komponente 236 und mit der vierten Software-Komponente 238 verbunden. Solange der Not-Aus-Taster 218 nicht betätigt ist, gibt die erste Software-Komponente 232 ein Freigabesignal aus, welches über die erste Logikverbindung 242 den angeschlossenen Software- Komponenten 234, 236, 238 zugeführt wird. Durch dieses Freigabesignal werden diese Software-Komponenten frei geschaltet und ein Betrieb der zu steuernden Anlage 210 ist möglich.
Die Software-Komponenten 234, 236, 238 sind untereinander durch zweite Logikverbindungen 244 verbunden. Über die zweiten Logikverbindungen 244 werden den Ablauf steuernde Signale zwischen den Software-Komponenten 234, 236, 238 ausgetauscht. Die zweite Software-Komponente 234 erzeugt ein Signal, welches der dritten Software-Komponente 236 zugeführt wird. Mit diesem Signal wird der Prozessstation 214 angezeigt, dass die Arbeitsschritte der Handlingstation 212 abgeschlossen sind und somit mit der Abarbeitung der Arbeitsschritte der Prozessstation 214 begonnen werden kann. Die dritte Software-Komponente 236 erzeugt ein Signal, welches der vierten Software-Komponente 238 zugeführt wird. Mit diesem Signal wird der Teststation 216 angezeigt, dass die Arbeitsschritte der Prozessstation 214 beendet sind und somit mit der Abarbeitung der Arbeitsschritte der Teststation 216 begonnen werden kann. Die vierte Software-Komponente 238 erzeugt ein Signal, welches der dritten Software-Komponente 236 zugeführt wird. Mit diesem Signal wird das in der Teststation 216 bei einem Prüfvorgang des bearbeiteten Werkstückes ermittelte Ergebnis der Prozessstation 214 mitgeteilt. Die dritte Software-Komponente 236 erzeugt ein Signal, welches der zweiten Software-Komponente 234 zugeführt wird. Mit diesem Signal wird der Handlingstation 212 mitgeteilt, ob in der Prozessstation 214 ein Fehler vorliegt.
Neben der Vielzahl 230 von Software-Komponenten ist auch eine Anzahl 246 von Aspektblöcken dargestellt. Im Einzelnen handelt es sich hier um einen ersten Aspektblock 248, der einem Standardsteuerungsaspekt zugeordnet ist, um einen zweiten Aspektblock 250, der einem Sicherheitssteuerungsaspekt zugeordnet ist, um einen dritten Aspektblock 252, der einem Diagnoseaspekt zugeordnet ist, um einen vierten Aspektblock 254, der einem Visualisierungsaspekt zugeordnet ist, um einen fünften Aspektblock 256, der einem Antriebsregelungsaspekt zugeordnet ist und um einen sechsten Aspektblock 258, der einem Verriegelungsaspekt zugeordnet ist. Vorteilhafterweise ist der vierte Aspektblock 254 mit der fünften Software-Komponente 240 verbunden. Ebenso kann zumindest ein Teil der von dem dritten Aspektblock 252 erzeugten Diagnosemeldungen mit der fünften Software-Komponente 240 zur Anzeige gebracht werden.
Ein wesentlicher Vorteil des neuen Verfahrens und der neuen Vorrichtung soll anhand Fig. 4 und 5 beschrieben werden. Soll die Anlage 210 beispielsweise modifiziert werden, indem eine zweite Prozessstation eingefügt wird, die zu der bereits vorhandenen Prozessstation 214 identisch ist, so ist in der obersten Hierarchieebene des Anwenderprogramms 38 lediglich eine Kopie der bereits vorhanden Software- Komponente 236, die der Prozessstation 214 entspricht, einzufügen und durch entsprechende logische Verbindungen einzubinden. Es kann somit eine vorhandene Software-Komponente auch auf einer der höheren Hierarchieebenen vollständig wiederverwendet werden. Dadurch können bestehende Anwenderprogramme sehr effizient angepasst werden. Dabei ist hier angenommen, dass die Handlingstation 212 mechanisch so ausgebildet ist, dass sie beide Prozessstationen bedienen kann. Für den erweiterten Bewegungsumfang der Handlingstation 212 sind ggf. Modifikationen in den Funktionsprogrammen erforderlich, die in der Software-Komponente 234 enthalten sind.
In Fig. 6 ist die Teilkomponente Prozessstation in ihrer Gesamtheit mit der Bezugsziffer 214 bezeichnet. Dass nachfolgend lediglich die Prozessstation und die in ihr enthaltenen Hardware-Komponenten betrachtet werden, soll keine einschränkende Wirkung haben. Die nachfolgenden Ausführungen gelten in entsprechender Weise auch für die Handlingstation 212 und die Teststation 216.
Die Prozessstation 214 umfasst einen Rundtisch 270, ein Prüfmodul 272, ein Bohrmodul 274 und ein Auswurfmodul 276. Mit dem Rundtisch 270 können in der Prozessstation 214 sämtliche Werkstücke zwischen den einzelnen Modulen 272, 274, 276 transportiert werden. Mit dem Prüfmodul 272 werden zu bearbeitende Werkstücke auf das Vorhandensein vorgegebener Eigenschaften überprüft. Mit dem Bohrmodul 274 werden die in der Prozessstation 214 befindlichen Werkstücke bearbeitet. Mit dem Auswurfmodul 276 werden die bearbeiteten Werkstücke entnommen und an die Teststation 216 weitergegeben. Alternativ können die bearbeiteten Werkstücke auch mit der Handlingstation 212 übergeben werden. Der Prozessstation 214 ist ein Not-Aus-Taster 278 zugeordnet.
In Fig. 7a sind die in der dritten Software-Komponente 236 enthaltenen Software- Komponenten und Aspektblöcke dargestellt.
Mit der Bezugziffer 280 ist eine sechste Software-Komponente bezeichnet, die dem Not-Aus-Taster 278 entspricht und die als Elementarkomponente ausgebildet ist. Mit der Bezugsziffer 282 ist eine siebte Software-Komponente bezeichnet, die dem Rund- tisch 270 entspricht. Mit der Bezugsziffer 284 ist eine achte Software-Komponente bezeichnet, die dem Prüfmodul 272 entspricht. Mit der Bezugsziffer 286 ist eine neunte Software-Komponente bezeichnet, die dem Bohrmodul 274 entspricht. Mit der Bezugsziffer 288 ist eine zehnte Software-Komponente bezeichnet, die dem Auswurfmodul 276 entspricht. Die Software-Komponenten 282, 284, 286, 288 sind als Gruppenkomponenten ausgebildet.
Über eine Logikverbindung 290 wird den Software-Komponenten 282, 284, 286, 288 ein in der sechsten Software-Komponente 280 erzeugtes Freigabesignal zugeführt. Einzelheiten zu dem Freigabesignal können in entsprechender Weise der Beschreibung zu Fig. 5a entnommen werden. Die Software-Komponenten 282, 284, 286, 288 sind über vierte Logikverbindungen 292 untereinander verbunden. Durch entsprechende Signale, die über die vierten Logikverbindungen 292 zwischen den Software- Komponenten 282, 284, 286, 288 ausgetauscht werden, wird eine Ablaufsteuerung realisiert. In der siebten Software-Komponente 282 werden drei Signale erzeugt, von denen jeweils eines der achten Software-Komponente 284, der neunten Software- Komponente 286 und der zehnten Software-Komponente 288 zugeführt wird. Diese Signale zeigen der jeweiligen Hardware-Komponente, der die jeweilige Software- Komponente entspricht an, dass der Rundtisch 270 jeweils eine definierte Position einnimmt. In jeder der Software-Komponenten 284, 286, 288 wird ein Signal erzeugt, welches der siebten Software-Komponente 282 zugeführt wird. Mit diesen Signalen wird jeweils angezeigt, dass die für die Module 272, 274, 276 vorgesehenen Arbeitsschritte abgearbeitet sind. In der achten Software-Komponente 284 wird ein weiteres Signal erzeugt, welches ebenfalls der siebten Software-Komponente 282 zugeführt wird. Dieses Signal repräsentiert das Ergebnis der in dem Prüfmodul 272 durchgeführten Prüfung. In Abhängigkeit dieses Ergebnisses kann die Arbeitsweise des Rundtisches 270 beeinflusst werden.
Zusätzlich weist die dritte Software-Komponente 236 mehrere Aspektblöcke auf. Einen siebten Aspektblock 294, der dem Standardsteuerungsaspekt zugeordnet ist, einen achten Aspektblock 296, der dem Sicherheitssteuerungsaspekt zugeordnet ist, einen neuen Aspektblock 298, der dem Diagnoseaspekt zugeordnet ist, einen zehnten Aspektblock 300, der dem Visualisierungsaspekt zugeordnet ist, einen elften Aspektblock 302, der dem Antriebsregelungsaspekt zugeordnet ist und einen zwölften Aspektblock 304, der dem Verriegelungsaspekt zugeordnet ist.
Anhand der Prozessstation 214 wird die Bedeutung des Verriegelungsaspektes erläutert. Mit dem Aspektblock 304 lässt sich beispielsweise in einfacher Art und Weise das Zusammenwirken des Rundtisches 270 und des Bohrmoduls 274 koordinieren. In dem Aspektblock 304 wird ein Signal ausgewertet, welches in der neunten Software- Komponente 286 erzeugt wird. Es handelt sich um das Signal, welches anzeigt, dass das Bohrmodul 274 eine Grundstellung einnimmt, in der sich der Motor 310 in solch einer Höhe befindet, dass sich der Rundtisch 270 frei drehen kann. Von dem Aspektblock 304 wird erst dann ein für den Rundtisch 270 bestimmtes Freigabesignal erzeugt, wenn dieses Grundstellungssignal vorliegt. Somit ist sichergestellt, dass bei einer Drehbewegung des Rundtisches 270 das Bohrmodul 274 nicht beschädigt werden kann.
In Fig. 8 ist das Bohrmodul in seiner Gesamtheit mit der Bezugsziffer 274 bezeichnet. Das Bohrmodul 274 weist als Einzelkomponenten mit einer mechanischen oder elektrischen oder elektromechanischen Funktion einen Motor 310, einen Transferzylinder 312 und einen Bohrzylinder 314 auf. Mit den beiden Zylindern 312, 314 kann der Motor 310 entlang einer Führungseinheit relativ zu dem zu bearbeitenden Werkstück bewegt werden, und zwar mit dem Bohrzylinder 314 in vertikaler Richtung und mit dem Transferzylinder 312 in horizontaler Richtung. Dem Bohrmodul 274 ist ein Not- Aus-Taster 316 zugeordnet.
In Fig. 9a sind die in der neunen Software-Komponente 286 enthaltenen Software- Komponenten und Aspektblöcke dargestellt. Es handelt sich hierbei um eine elfte Software-Komponente 320, die dem Not- Aus-Taster 316 entspricht. Um eine zwölfte Software-Komponente 322, die dem Bohrzylinder 314 entspricht, um eine dreizehnte Software-Komponente 324, die dem Transferzylinder 312 entspricht und um eine vierzehnte Software-Komponente 326, die dem Motor 310 entspricht. Die Software- Komponenten 320, 322, 324, 326 sind als Elementarkomponenten ausgebildet. Den Software-Komponenten 322, 324, 326 wird über eine fünfte Logikverbindung 328 ein in der elften Software-Komponente 320 erzeugtes Freigabesignal zugeführt. Einzelheiten zu dem Freigabesignal können in entsprechender Weise der Beschreibung zu Fig. 5a entnommen werden.
Ferner enthält die neunte Software-Komponente 286 einen dreizehnten Aspektblock 330, der dem Standardsteuerungsaspekt zugeordnet ist, einen vierzehnten Aspektblock 332 der dem Sicherheitssteuerungsaspekt zugeordnet ist, einen fünfzehnten Aspektblock 334, der dem Diagnoseaspekt zugeordnet ist, einen sechzehnten Aspektblock 336, der dem Visualisierungsaspekt zugeordnet ist, einen siebzehnten Aspektblock 338, der dem Antriebsregelungsaspekt zugeordnet ist und einen achtzehnten Aspektblock 340, der dem Verriegelungsaspekt zugeordnet ist. Dem vierzehnten Aspektblock 332 wird über die fünfte Logikverbindung 328 das Freigabesignal zugeführt.
Die Aspektblöcke 330, 332 und die Software-Komponenten 322, 324, 326 sind untereinander über sechste Logikverbindungen 342 verbunden.
In der zwölften Software-Komponente 322 wird ein Signal erzeugt, welches den Zustand des Bohrzylinders 314 repräsentiert. Dieses Signal wird sowohl dem dreizehnten Aspektblock 330 als auch dem vierzehnten Aspektblock 332 zugeführt. In Abhängigkeit der ihm zugeführten Signale erzeugt der vierzehnte Aspektblock 332 ein Signal, welches der vierzehnten Software-Komponente 326 zugeführt wird. Mit diesem Signal kann der Motor 310 an- und ausgeschaltet werden. Die dreizehnte Software-Komponente 324 erzeugt ein Signal, welches den Zustand des Transferzylinders 312 repräsentiert. Dieses Signal wird dem dreizehnten Aspektblock 330 zugeführt. Die vierzehnte Software-Komponente 326 erzeugt ein Signal, welches ein Zustand des Motors 310 repräsentiert. Dieses Signal wird dem dreizehnten Aspektblock 330 zugeführt. In dem dreizehnten Aspektblock 330 werden in Abhängigkeit der ihm zugeführten Signale, hierbei handelt es sich um die vorstehend beschriebenen drei Signale sowie ein Signal, welches anzeigt, dass sich in der unter dem Bohrmodul 274 befindlichen Aufnahme des Rundtisches 270 ein zu bearbeitendes Werk- stück befindet, sowie einen den maximalen Bohrdurchmesser repräsentierenden Parameter drei Signale erzeugt, von denen jeweils eines der zwölften Software- Komponente 322, der dreizehnten Software-Komponente 324 und der vierzehnten Software-Komponente 326 zugeführt wird. Mit dem der zwölften Software- Komponente 322 zugeführten Signal wird der Bohrzylinder 214 aktiviert. Mit dem der dreizehnten Software-Komponente 324 zugeführten Signal wird der Transferzylinder 312 aktiviert. Mit dem der vierzehnten Software-Komponente 326 zugeführten Signal wird der Motor 310 aktiviert.
In Fig. 10 sind diejenigen Aspektblöcke dargestellt, die in einer Software-Komponente enthalten sind, die einem in der zu steuernden Anlage 210 enthaltenen Zylinder entspricht. Im vorliegenden Ausführungsbeispiel ist dies beispielsweise die zwölfte Software-Komponente 322. Dies soll jedoch keine einschränkende Wirkung haben, die nachfolgenden Ausführungen gelten ebenso für die dreizehnte Software- Komponente 324.
Die zwölfte Software-Komponente 322 enthält einen neunzehnten Aspektblock 350, der dem Standardsteuerungsaspekt zugeordnet ist, einen zwanzigsten Aspektblock 352, der dem Sicherheitssteuerungsaspekt zugeordnet ist, einen einundzwanzigsten Aspektblock 354, der dem Diagnoseaspekt zugeordnet ist und einen zweiundzwanzigsten Aspektblock 356, der dem Visualisierungsaspekt zugeordnet ist. Optional kann die zwölfte Software-Komponente auch einen dreiundzwanzigsten Aspektblock 358 enthalten, der dem Antriebsregelungsaspekt zugeordnet ist, sofern eine entsprechende Ansteuerung des Bohrzylinders 314 erfolgen soll. Diese Option ist durch die gestrichelten Linien angedeutet. Für gewöhnlich ist in dieser Hierarchieebene kein Aspektblock vorzusehen, der dem Antriebsregelungsaspekt zugeordnet ist. Die den Antriebsregelungsaspekt bereffenden Steuerungsaufgaben werden für gewöhnlich von dem in der nächst höheren Hierarchieebene enthaltenen Aspektblock übernommen, der dem Antriebsregelungsaspekt zugeordnet ist.
Die Aspektblöcke 350, 352, 354, 356 sind untereinander und mit einem Eingang und einem Ausgang, den die zwölfte Software-Komponente 322 aufweist, über siebte Logikverbindungen 360 verbunden. Der neunzehnte Aspektblock 350 wird über ein Signal aktiviert, welches ihm ausgehend vom Eingang der zwölften Software- Komponente 322 zugeführt wird. Dem zwanzigsten Aspektblock 352 wird über eine nicht dargestellte Verbindung ein Freigabesignal zugeführt. Als Sensoren sind dem neunzehnten Aspektblock 350 zwei Endlagesensoren, die vorzugsweise als Endlageschalter ausgebildet sind, zugeordnet. Mit einem ersten Endlagesensor wird diejenige Lage des Kolbens erfasst, in der die Kolbenstange maximal aus dem Zylindergehäuse ausgefahren ist. Mit einem zweiten Endlagesensor wird diejenige Endlage des Kolbens erfasst, in der die Kolbenstange minimal aus dem Zylindergehäuse ausgefahren ist.
In Abhängigkeit der in dem neunzehnten Aspektblock 350 zur Verfügung stehenden Größen wird in diesem eine Größe erzeugt, die den Zustand des Bohrzylinders 314 repräsentiert. Diese Größe wird zum einen dem Ausgang der zwölften Software- Komponente 322 zugeführt. Zum anderen wird diese Größe dem zweiundzwanzigsten Aspektblock 356 zugeführt. In Abhängigkeit dieser Größe wird im zweiundzwanzigsten Aspektblock 356 eine Größe erzeugt, die den mit dem Bohrzylinder eingestellten Hub repräsentiert. Diese Größe kann beispielsweise der Anzeigeeinheit 220 zugeführt werden, mit der dem Betreiber der zu steuernden Anlage 210 eine entsprechende Information angezeigt werden kann.
In dem neunzehnten Aspektblock 350 wird eine Größe erzeugt, mit der der Bohrzylinder 314 derart angesteuert wird, dass sich dessen Kolben in diejenige Endlage bewegt, in der die Kolbenstange minimal aus dem Zylindergehäuse herausschaut. Außerdem wird in dem neunzehnten Aspektblock 350 eine zweite Größe erzeugt, mit der der Bohrzylinder 314 derart angesteuert wird, dass sich der Kolben in diejenige Endlage bewegt, in der die Kolbenstange maximal aus dem Zylindergehäuse herausschaut. Diese beiden Größen werden jeweils an einem Ausgang des neunzehnten Aspektblocks 350 bereitgestellt.
In dem zwanzigsten Aspektblock 352 werden zwei Größen erzeugt. Eine erste Größe, die anzeigt, dass für den Bohrzylinder 314 die Hineinbewegung des Kolbens in das Zylindergehäuse freigegeben ist. Eine zweite Größe, die anzeigt, dass für den Bohr- zylinder 314 die Herausbewegung des Kolbens aus dem Zylindergehäuse heraus freigegeben ist. Diese beiden Größen werden jeweils an einem Ausgang des zwanzigsten Aspektblockes 352 bereitgestellt. Die von dem neunzehnten Aspektblock und die von dem zwanzigsten Aspektblock jeweils bereitgestellten Größen werden paarweise gemäß einer logischen UND-Funktion miteinander verknüpft. Dies verknüpften Größen stehen an entsprechenden Ausgängen der zwölften Software-Komponente 322 zur Verfügung und werden dem Bohrzylinder 314 zu dessen Ansteuerung zugeführt.
Anhand der Darstellung in Fig. 10 wird deutlich: Die dem Bohrzylinder 314 innewohnende Gesamtfunktionalität bzw. die ihn charakterisierende Gesamtfunktionalität wird in die vier Teilaspekte Standardsteuerung, Sicherheitssteuerung, Diagnose und Visualisierung zerlegt. Somit kann der Bohrzylinder 314 getrennt unter jeweils einem dieser vier Teilaspekte betrachtet werden. Da sämtliche in dem Anwenderprogramm verwendete Software-Komponenten nach diesem Prinzip aufgebaut sind, kann das Anwenderprogramm getrennt nach einzelnen Steuerungsaspekten erstellt werden, was mit Hilfe der Aspektteilprogramme der Fall ist.
Die strichlinierte Verbindung zwischen den beiden Aspektblöcken 350 und 354 repräsentiert einen zwischen diesen beiden Aspektblöcken stattfindenden Datenaustausch. Es kann sich hierbei um Ausgangsdaten oder um interne Daten handeln. Auch zwischen einzelnen Aspektblöcken, die in bereits zuvor beschriebenen oder noch nachfolgend zu beschreibenden Figuren enthalten sind, kann solch ein Datenaustausch stattfinden. Auf eine entsprechende Darstellung in diesen Figuren wurde jedoch aus Gründen der Übersichtlichkeit verzichtet.
In Fig. 11 sind diejenigen Aspektblöcke dargestellt, die in einer Software-Komponente enthalten sind, die einem Not-Aus-Taster entspricht. Beispielsweise kann es sich um die elfte Software-Komponente 320 handeln, die dem Not-Aus-Taster 316 entspricht. Dies soll keine einschränkende Wirkung haben. Ebenso kann es sich um eine andere in dem vorliegenden Ausführungsbeispiel enthaltene Software-Komponente handeln, die einem Not-Aus-Taster entspricht. Die elfte Software-Komponente 320 weist einen vierundzwanzigsten Aspektblock 370 auf, der dem Sicherheitssteuerungsaspekt zugeordnet ist. Ferner weist diese Software- Komponente einen fünfundzwanzigsten Aspektblock 372 auf, der dem Diagnoseaspekt zugeordnet ist. In dem vierundzwanzigsten Aspektblock 370 wird in Abhängigkeit der ihm zugeführten Größen ein Freigabesignal ermittelt, welches einem Ausgang der elften Software-Komponente 320 zugeführt wird. Außerdem wird in dem vierundzwanzigsten Aspektblock 370 ein Signal erzeugt, welches den Zustand des Not- Aus-Tasters 316 repräsentiert. Dieses Signal wird dem fünfundzwanzigsten Aspektblock 372 zugeführt und steht somit zu Diagnosezwecken zur Verfügung. Ergänzend oder alternativ kann dem fünfundzwanzigsten Aspektblock 372 auch das von dem vierundzwanzigsten Aspektblock 370 erzeugte Freigabesignal zugeführt werden. Beispielsweise können in dem fünfundzwanzigsten Aspektblock 372 folgende Systemzustände des Not- Aus-Taster 316 erkannt werden: der Not- Aus-Taster ist gedrückt; die Kontakte des Not-Aus-Tasters sind verklebt; die beiden Eingangssignale des Not-Aus-Tasters sind synchronisiert.
Vorzugsweise ist die Softwarekomponente 320 mit einem Funktionalitätsparameter versehen, der in dem vierundzwanzigsten Aspektblock 370 hinterlegt ist. Mit diesem Funktionalitätsparameter kann nun eine von mehreren hinterlegten Funktionalitäten aktiviert werden. Verfügt der Not- Aus-Taster 316 über einen Acknowledge-Eingang, so kann durch Festlegen eines entsprechenden Funktionalitätsparameterwerts eine Funktionalität aktiviert werden, die einen Acknowledge-Eingang abbildet. In diesem Fall wird ein Acknowledge-Eingang ausgewertet und somit ein an ihm anliegendes Acknowledge-Signal zur weiteren Auswertung erfasst. Verfügt der Not- Aus-Taster 316 dagegen über keinen Acknowledge-Eingang, so kann durch Festlegen eines entsprechenden Funktionalitätsparameterwerts eine Funktionalität aktiviert werden, bei der kein Acknowledge-Eingang abgebildet ist. In diesem Fall unterbleibt die Auswertung eines Acknowledge-Eingangs.
Wie der Darstellung in den Fig. 10 und 11 zu entnehmen ist, ist zumindest ein Teil der Software-Komponenten und/oder Aspektblöcke, die in einer als Gruppenkomponente ausgebildeten Software-Komponente enthalten sind, mit Eingängen und/oder Ausgängen dieser Software- Komponente verbunden. Aus Gründen der Übersichtlichkeit wurde in den Fig. 7 a, 7bj-7c, 9a, 9b und 9c auf die Darstellung entsprechender Verbindungen verzichtet, was allerdings keine einschränkende Wirkung haben soll.
In Fig. 12 ist der schematische Aufbau eines in seiner Gesamtheit mit der Bezugsziffer 380 bezeichneten Aspektblockes dargestellt.
Der Aspektblock 380 weist eine Identifiziereinheit 382 auf, in der eine Kennung hinterlegt ist, die denjenigen Steuerungsaspekt festlegt, dem der Aspektblock zugeordnet ist. Der Aspektblock 380 weist ferner eine Interfaceeinheit 384 auf, in der eine Anzahl 386 von Eingängen und eine Anzahl 388 von Ausgängen zusammengefasst sind. Wie in Fig. 12 angedeutet, umfasst die Anzahl 386 von Eingängen drei unterschiedliche Typen von Eingängen. Einen ersten Typ von Eingängen, über den dem Aspektblock 380 Logikgrößen und/oder Zwischengrößen zugeführt werden können. Einen zweiten Typ von Eingängen, über den dem Aspektblock 380 Parameter zugeführt werden können. Einen dritten Typ von Eingängen, über den dem Aspektblock 380 Sensorsignale zugeführt werden können. Ebenso umfassen die Anzahl 388 von Ausgängen drei Typen von Ausgängen. Einen ersten Typ von Ausgängen, über die von dem Aspektblock 380 Logikgrößen und/oder Zwischengrößen ausgegeben werden können. Einen zweiten Typ von Ausgängen, über den von dem Aspektblock 380 Parameter ausgegeben werden können. Einen dritten Typ von Ausgängen, über den von dem Aspektblock 380 Ausgangssignale ausgegeben werden können.
Ferner enthält der Aspektblock 380 eine Funktionseinheit 390, in der ein Funktionsprogramm hinterlegt ist, mit dem eine Aspekteigenschaft derjenigen Hardware- Komponente festgelegt wird, der diejenige Software-Komponente entspricht, in der der Aspektblock enthalten ist. Außerdem enthält der Aspektblock 380 eine Parametereinheit 392, in der Parameterwerte für Parameter hinterlegt sind, die in dem Funktionsprogramm verarbeitet werden. Auf die Verknüpfung der in dem Aspektblock 380 enthaltenen Blöcke wurde aus Gründen der Übersichtlichkeit verzichtet. Das Funktionsprogramm, welches in einem Aspektblock hinterlegt ist, der dem Diagnoseaspekt zugeordnet ist, enthält die auszuwertenden Diagnosebedingungen. Außerdem enthält dieses Funktionsprogramm diejenigen Texte, die in Abhängigkeit des Ergebnisses, welches bei der Auswertung der Diagnosebedingungen erhalten wird, als Meldungen und Abhilfen anzuzeigen sind. Das Funktionsprogramm, welches in einem Aspektblock hinterlegt ist, der dem Visualisierungsaspekt zugeordnet ist, enthält diejenigen Umfange des Anwenderprogramms, die die Steuerung einer grafischen Oberfläche festlegen. Mittels einer grafischen Oberfläche werden beispielsweise beim Abarbeiten des Anwenderprogramms ermittelte Daten oder sich einstellende Zustände von Hardware-Komponenten unter Verwendung eines Monitors oder Displays dargestellt. Das Funktionsprogramm, welches in einem Aspektblock hinterlegt ist, der dem Standardsteuerungsaspekt zugeordnet, legt diejenigen Steuerungsaufgaben fest, die im Rahmen der Standardsteuerung abzuarbeiten sind, und zwar für diejenige Hardware-Komponente, der diejenige Software-Komponente entspricht, in der der Aspektblock enthalten ist. Entsprechend werden in dem Funktionsprogramm, welches in einem Aspektblock hinterlegt ist, der dem Sicherheits- steuerungsaspekt zugeordnet ist, die Steuerungsaufgaben festgelegt, die im Rahmen der Sicherheitssteuerung abzuarbeiten sind.
Wie den vorstehenden Ausführungen zu entnehmen ist, handelt es sich bei den in Abhängigkeit der Eingangssignale ermittelten Ausgangssignale nicht zwangsläufig um Ausgangssignale im steuerungstechnischen Sinn, wobei unter Ausgangssignalen im steuerungstechnischen Sinn Ausgangssignale zu verstehen sind, mit denen ein Aktor, beispielsweise ein Motor, ein Zylinder oder ein Schütz angesteuert wird. Beispielsweise handelt es sich bei den Ausgangssignalen eines dem Visualisierungsaspekt zugeordneten Aspektblocks nicht um Ausgangssignale im steuerungstechnischen Sinn. Diese Ausgangssignale legen beispielsweise fest, wie ein auf einer grafischen Oberfläche dargestelltes Bild aussieht oder wie eine Information dargestellt wird. Ebenso handelt es sich bei den Ausgangssignalen eines dem Diagnoseaspekt zugeordneten Aspektblocks nicht um Ausgangssignale im steuerungstechnischen Sinn. Dagegen handelt es sich bei den Ausgangssignalen eines dem Standardsteuerungsaspekt zugeordneten Aspektblocks oder bei den Ausgangssignalen eines dem Sicherheits- Steuerungsaspekt zugeordneten Aspektblocks um Ausgangssignale im steuerungstechnischen Sinn. Wie bereits ausgeführt, sind in der Parametriereinheit 392 Parameterwerte hinterlegt. Die hierfür vorzunehmende Parametrierung erfolgt üblicherweise zum Projektierungszeitpunkt, d.h. beim Erstellen des Anwenderprogramms. Dabei wird zum einen der Eingang über den dem Aspektblock ein Parameter zugeführt werden kann und somit der Parameter dem Grunde nach festgelegt. Zum anderen wird auch der Wert des Parameters festgelegt. Üblicherweise bleibt dann der Parameterwert während dem Abarbeiten des Anwenderprogramms unverändert. In diesem Fall muss aufgrund des unveränderlichen Parameterwerts kein Ausgang in der Interfaceeinheit vorgesehen sein, über den der Parameter ausgegeben werden kann. Allerdings ist auch folgender Ansatz denkbar, bei dem eine Interfaceeinheit zum Einsatz kommt, die Ausgänge aufweist, über die Parameter ausgegeben werden können: In einem Anwenderprogramm sind mehrere Rezepturen hinterlegt, die üblicherweise zum Projektierungszeitpunkt erstellt werden. Diese Rezepturen unterscheiden sich dadurch voneinander, dass zumindest einem Teil der in dem Anwenderprogramm verwendeten Parameter in den einzelnen Rezepturen unterschiedliche Werte zugewiesen sind. Folglich können in einer Parametriereinheit eines Aspektblockes für ein und denselben Parameter unterschiedliche Parameterwerte hinterlegt sein. Das Anwenderprogramm enthält eine Anzahl von Prüfbedingungen, mit denen ermittelt wird, welche der hinterlegten Rezepturen aktuell abgearbeitet werden soll. Wird beim Abarbeiten des Anwenderprogramms festgestellt, dass eine solche Prüfbedingung erfüllt ist, dann wird zwischen einzelnen Rezepturen umgeschaltet. Eine aktuell abgearbeitete Rezeptur wird durch eine zukünftig abzuarbeitende Rezeptur ersetzt. Dementsprechend wird derjenige Parameterwert, der einem Parameter aktuell zugewiesen ist, durch einen zukünftig geltenden Parameterwert ersetzt. Der so geänderte Parameterwert kann über einen Parametrierausgang ausgegeben und somit anderen Aspektblöcken oder Software-Komponenten zur Verfügung gestellt werden. Dies bedeutet, dass entsprechend den einzelnen hinterlegten Rezepturen verschiedene Parametersätze bereitgestellt werden können und somit zwischen unterschiedlichen Parametrierungen umgeschaltet werden kann. Bei diesem Ansatz kann sich somit ein Parameterwert während dem Abarbeiten des Anwenderprogramms ändern. In Fig. 13 ist eine Software-Komponente in ihrer Gesamtheit mit der Bezugsziffer 400 bezeichnet.
Die Software-Komponente 400 enthält eine Interfaceeinheit 402, in der eine Anzahl 404 von Eingängen und eine Anzahl 406 von Ausgängen zusammengefasst sind. Ebenso wie im Fall des in Fig. 12 beschriebenen Aspektblockes 380 umfassen die Anzahl 404 von Eingängen drei Typen von Eingängen und umfassen die Anzahl 406 von Ausgängen drei Typen von Ausgängen. Was die Einzelheiten zu den drei Typen von Eingängen und den drei Typen von Ausgängen angeht sei auf die Beschreibung der Fig. 12 verwiesen. Ferner sind in der Software-Komponente 400 eine Anzahl 408 von Aspektblöcken und eine Anzahl 410 von Elementar- und/oder Gruppenkomponenten enthalten. Auf die Verknüpfung der in der Software-Komponente 400 enthaltenen Blöcke wurde aus Gründen der Übersichtlichkeit verzichtet. Vorteilhafterweise umfasst eine Software-Komponente einen Aspektblock, der dem Standardsteuerungsaspekt zugeordnet ist, einen Aspektblock, der dem Sicherheitssteuerungs- aspekt zugeordnet ist und einen Aspektblock, der dem Diagnoseaspekt zugeordnet ist. Optional können noch ein Aspektblock, der dem Visualisierungsaspekt zugeordnet ist, und ein Aspektblock, der dem Antriebsregelungsaspekt zugeordnet ist, vorgesehen sein. Die vorstehende Aufzählung von in einer Software-Komponente enthaltenen Aspektblöcken ist exemplarisch und hat somit keinen abschließenden Charakter. Ferner soll die in Fig. 13 gewählte Darstellung, gemäß der die Software-Komponente 400 eine Anzahl 410 von Elementar- und/oder Gruppenkomponenten enthält, keinen einschränkenden Charakter haben. Aufgrund der in Fig. 13 gewählten Darstellung entspricht die Software-Komponente 400 einer Gruppenkomponente. Eine Elementarkomponente enthält dagegen lediglich zumindest einen Aspektblock und keine Elementar- und/oder Gruppenkomponenten.
Programmtechnisch entspricht sowohl eine Software-Komponente als auch ein Aspektblock einem XML-File. Im Falle eines Aspektblockes enthält das XML-File folgende Informationen: Belegungsinformationen, die wiedergeben, welche Größen und/oder Parameter und/oder Sensorsignale den Eingängen und/oder Ausgängen, die in der Interfaceeinheit zusammengefasst sind, dem Grunde nach zugeordnet sind; Aufrufinformationen, die in dem Funktionsprogramm enthaltene Aufrufe wiedergeben, mit denen in einer Datenbank befindliche Software-Bausteine aufgerufen werden, wobei es sich um der internationalen Norm IEC/EN 61131 entsprechende Software-Bausteine handelt; das in dem jeweiligen Aspektblock hinterlegte Funktionsprogramm. Im Falle einer Software-Komponente handelt es sich um folgende Informationen: in entsprechender Weise ebenfalls Belegungsinformationen; Informationen über die in der Software-Komponente enthaltenen Software-Komponenten und/oder Aspektblöcke. Auch die hierarchische Struktur des Anwenderprogramms wird als XML-File beschrieben, wobei dieses folgende Informationen enthält: Informationen über die Parametrierung einzelner Aspektblöcke; Informationen über das I/O-Mapping einzelner Aspektblöcke; Textbausteine, die in einzelnen Aspektblöcken enthalten sind, die dem Diagnoseaspekt zugeordnet sind. Selbstverständlich kann zur Beschreibung der Aspektblöcke, der Software-Komponenten sowie insbesondere der hierarchischen Struktur des Anwenderprogramms eine beliebige andere hierfür geeignete Beschreibungssprache verwendet werden, die in der Lage ist, eine hierarchische Struktur abzubilden.
In Fig. 14 ist eine hierarchische Struktur in ihrer Gesamtheit mit der Bezugsziffer 420 bezeichnet.
Diese hierarchische Struktur repräsentiert sowohl diejenige hierarchische Struktur, die der zu steuernden Anlage 210 zugrunde liegt, als auch diejenige hierarchische Struktur, die dem Anwenderprogramm 38 für die Sicherheitssteuerung 18 zugrunde liegt. In der für Fig. 14 gewählten Darstellung hat jeder Block zwei Bedeutungen. Mit der vor dem Schrägstrich stehenden Bezugsziffer wird angegeben, welche Hardware- Komponente der zu steuernden Anlage 210 der jeweilige Block repräsentiert. Mit der nach dem Schrägstrich stehenden Bezugsziffer wird angegeben, welche Software- Komponente der jeweilige Block in dem Anwenderprogramm 38 repräsentiert. Der Darstellung in Fig. 14 liegen die Fig. 5a, 7a und 9a zugrunde. Dies soll keine einschränkende Wirkung haben. Die in Fig. 14 dargestellte Struktur lässt sich ebenso auf die Darstellung der Fig. 5b, 7b und 9b oder die Darstellung der Fig. 5c, 7c und 9c übertragen. Mit der Bezugsziffer 422 ist ein Block bezeichnet, der die zu steuernde Anlage 210 in ihrer Gesamtheit oder das Anwenderprogramm 38 in seiner Gesamtheit repräsentiert. Mit der Bezugsziffer 424 ist eine oberste Hierarchieebene bezeichnet. Mit Blick auf die zu steuernde Anlage 210 umfasst diese Hierarchieebene die Handlingstation 212, die Prozessstation 214 und die Teststation 216. Diese Hardware-Komponenten werden als Teilkomponenten bezeichnet.
Mit der Bezugsziffer 426 ist eine erste Hierarchieebene bezeichnet, die direkt unterhalb der obersten Hierarchieebene liegt. Diese Hierarchieebene umfasst den Rundtisch 270, das Prüfmodul 272, das Bohrmodul 274 und das Auswurfmodul 276. Diese Hardware-Komponenten werden als Unterkomponenten bezeichnet.
Mit der Bezugsziffer 428 ist eine zweite Hierarchieebene bezeichnet, die direkt unterhalb der ersten Hierarchieebene liegt. Diese Hierarchieebene umfasst den Motor 310, den Transferzylinder 312 und den Bohrzylinder 314. Diese Hardware-Komponenten werden als Einzelkomponenten bezeichnet.
In Fig. 14 wurde nicht für jede dargestellte Teilkomponente die erste Hierarchieebene und nicht für jede dargestellte Unterkomponente die zweite Hierarchieebene dargestellt. Dies soll keine einschränkende Wirkung haben. Für jede der in Fig. 14 dargestellten Teilkomponenten und Unterkomponenten existieren entsprechende Hierarchieebenen. Ferner wurde aus Gründen der Übersichtlichkeit auf die Darstellung sämtlicher Not-Aus-Taster verzichtet.
Hinsichtlich des Wartungsaspektes sei folgendes ausgeführt: Bei der Wartung wird die zu steuernde Anlage 210 in eine Betriebsart überführt, bei der die durch das Anwenderprogramm 38 definierten Bewegungsabläufe der zu steuernden Anlage 210 mit einer reduzierten Geschwindigkeit ablaufen. Somit kann beispielsweise ein mit der zu steuernden Anlage 210 realisierter Fertigungsprozess mit reduzierter Geschwindigkeit weiterlaufen, während gleichzeitig Wartungsarbeiten an der zu steuernden Anlage 210 durchgeführt werden können. Dem Ausführungsbeispiel liegt die zu steuernde Anlage 210 zugrunde. Diese Anlage 210 wird mit einer Sicherheitssteuerung 18 gesteuert, in der ein hierarchisch aufgebautes Anwenderprogramm 38 abgearbeitet wird.JBeim Erstellen des Anwenderprogramms werden eine Vielzahl von Software-Komponenten und gegebenenfalls Aspektblöcke bereitgestellt. Die bereitgestellten Software-Komponenten können sowohl als Elementarkomponenten als auch als Gruppenkomponenten ausgebildet sein, wobei eine hierarchische Struktur aufgrund der als Gruppenkomponenten ausgebildeten Software-Komponenten entsteht. Durch logisches Verknüpfen der Software-Komponenten wird ein Komponententeilprogramm erstellt. Innerhalb der jeweiligen Gruppenkomponente sind die in ihr enthaltenen Software-Komponenten ebenfalls untereinander logisch verknüpft. Vorhandene Aspektblöcke können ebenfalls mit den Software-Komponenten verbunden sein. Für die vorhandenen Aspektblöcke werden auf die einzelnen Steuerungsaspekte bezogene Aspektteilprogramme erstellt. Das Komponententeilprogramm und die Aspektteilprogramme ergeben dann zusammen das Anwenderprogramm, wobei das Anwenderprogramm eine Ablaufsteuerung darstellt bzw. durch dieses eine Ablaufsteuerung realisiert wird.
Die logischen Verbindungen, insbesondere die zwischen den Software-Komponenten untereinander aber auch diejenigen zwischen den Software-Komponenten einerseits und den Aspektblöcken andererseits können dabei nach unterschiedlichen Verknüpfungsansätzen realisiert werden. Welcher Verknüpfungsansatz konkret angewandt wird, hängt dabei von verschiedenen äußeren Gegebenheiten ab. Eine solche Gegebenheit ist beispielsweise der Ausstattungsgrad der Hardware-Komponenten mit Datenverarbeitungskomponenten, beispielsweise Prozessoren. Des weiteren sind die Komplexität der zu steuernden Anlage oder die Komplexität der Ablaufsteuerung, die für die zu steuernde Anlage zu realisieren ist bzw. die zu realisierenden Abläufe zu berücksichtigen. Dabei muss nicht für alle Hierarchieebenen derselbe Verknüpfungsansatz angewandt werden. Es ist denkbar, bei einzelnen Hierarchieebenen oder gar bei einzelnen Gruppenkomponenten unterschiedliche Verknüpfungsansätze anzuwenden. Auf die unterschiedlichen anwendbaren Verknüpfungsansätze wird nachfolgend eingegangen. Im Wesentlichen handelt es sich dabei um einen kaskadierten Verknüpfungsansatz und um einen nicht-kaskadierten Verknüpfungsansatz. Die beiden Verknüpfungsansätze werden anhand der Fig. 5a, 5b, 5c, 7a, 7b, 7c, 9a, 9b und 9c erläutert. In den einzelnen Figuren sind identische Einheiten mit dem selben Bezugszeichen versehen, wobei modifizierte Einheiten durch einen oder zwei angefügte Striche gekennzeichnet sind. Dabei gilt für die Software-Komponenten, dass diese dieselbe Hardware-Komponente repräsentieren, sich aber beispielsweise entsprechend dem unterschiedlichen Ausstattungsgrad der Hardware-Komponenten mit Datenverarbeitungskomponenten unterscheiden. Für die Aspektblöcke gilt, dass sie demselben Steuerungsaspekt zugeordnet sind, sich aber aufgrund des unterschiedlichen Verknüpfungsansatzes beispielsweise in der Funktionalität unterscheiden.
Einzelheiten, die den Fig. 5 a, 7a und 9a entnehmbar sind oder die im Zusammenhang mit diesen Figuren beschrieben sind, sollen, sofern dies technisch sinnvoll ist, in entsprechender Weise sowohl bei den Gegenständen der Fig. 5b, 7b und 9b als auch bei den Gegenständen der Fig. 5c, 7c und 9c einsetzbar sein. Entsprechendes gilt für Gegenstände der Fig. 5b, 7b und 9b sowohl hinsichtlich der Gegenstände der Fig. 5a, 7a und 9a als auch hinsichtlich der Gegenstände der Fig. 5c, 7c und 9c. Entsprechendes gilt für Gegenstände der Fig. 5c, 7c und 9c sowohl hinsichtlich der Gegenstände der Fig. 5 a, 7a und 9a als auch hinsichtlich der Gegenstände der Fig. 5b, 7b und 9b.
Teilweise wurde in den Fig. 5a, 5b, 5c, 7a, 7b, 7c, 9a, 9b und 9c auf die vollständige Darstellung der logischen Verbindungen aus Gründen der Übersichtlichkeit verzichtet. Dies gilt insbesondere für einzelne in den vorgenannten Figuren enthaltene Aspektblöcke. Dieses Auslassen von logischen Verbindungen soll keine einschränkende Wirkung haben.
Den vorstehend beschriebenen Fig. 5a, 7a, und 9a liegt der kaskadierte Verknüpfungsansatz zugrunde. Der kaskadierte Verknüpfungsansatz wird beispielsweise dann angewandt, wenn es sich bei der zu steuernden Anlage um eine einfache Anlage handelt und ergänzend oder alternativ die zu realisierende Ablaufsteuerung wenig komplex ist. Um den kaskadierten Verknüpfungsansatz anwenden zu können, ist es erforderlich, dass die in der zu steuernden Anlage enthaltenen Hardware- Komponenten jeweils mit leistungsfähigen Datenverarbeitungskomponenten ausgestattet sind. Dies ist in den Software-Komponenten, die diese Hardware-Komponenten repräsentieren, berücksichtigt. Bei dem kaskadierten Verknüpfungsansatz ist zumindest ein Teil der Software-Komponenten so untereinander logisch verknüpft, dass zumindest ein Teilumfang der zu realisierenden Ablaufsteuerung durch die logischen Verbindungen realisiert ist. Zudem liegt der Darstellung in den Fig. Fig. 5a, 7a und 9a neben dem kaskadierten Verknüpfungsansatz ein erster Steuerungsumfang zugrunde, er einen hohen Steuerungsumfang repräsentiert. Deswegen sind in den Fig. 5a, 7a und 9a jeweils zahlreiche Aspektblöcke dargestellt.
Vorteilhafterweise kann bei der in Fig. 5a dargestellten kaskadierten Verknüpfung ein von dem Not- Aus-Taster 218 erzeugtes Freigabesignal dem zweiten Aspektblock 250 zugeführt werden. Ferner können dem zweiten Aspektblock 250 Signale zugeführt werden, die von dem sechsten Aspektblock 258 hinsichtlich einer Verriegelungsfunktion erzeugt werden, wobei es sich beispielsweise um ein Verriegelungsfreigabesignale für die vierte Softwarekomponente 238, um ein Verriegelungsfreigabesignal für die dritte Software-Komponente 236 oder um ein Verriegelungsfreigabesignal für die zweite Software-Komponente 234 handeln kann. Die dem zweiten Aspektblock 250 zugeführten Signale werden mittels einer logischen UND-Funktion verknüpft. In dem zweiten Aspektblock 250 werden somit Gesamtfreigabesignale für die Software- Komponenten 234, 236, 238 erzeugt. Aus Gründen der Übersichtlichkeit wurde auf die Darstellung entsprechender logischer Verbindungen zwischen den genannten Software-Komponenten und den genannten Aspektblöcken verzichtet.
Der Darstellung in den Fig. 5b, 7b, 9b liegt zwar auch der kaskadierte Verknüpfungsansatz zugrunde, allerdings ein zweiter Steuerungsumfang, der gegenüber dem ersten Steuerungsumfang einen niedrigeren Steuerungsumfang repräsentiert. Deswegen ist in den Fig. 5b, 7b und 9b lediglich der minimal erforderliche Umfang an Aspektblö- 11
cken dargestellt, der benötigt wird, um für das konkrete Ausführungsbeispiel das Anwenderprogramm erstellen zu können.
Im Vergleich zu Fig. 5a sind in Fig. 5b Aspektblöcke, die jeweils dem ersten Aspektblock 248, dem zweiten Aspektblock 250, dem fünften Aspektblock 256 und dem sechsten Aspektblock 258 entsprechen, nicht enthalten. Ausgehend von dem dritten Aspektblock 252' werden den Software-Komponenten 234', 236' und 238' Signale zugeführt. Somit stehen in den Software-Komponenten im Rahmen der Diagnose gewonnene Informationen zur Verfügung und können beim Abarbeiten der jeweiligen Steuerungsaufgaben berücksichtigt werden. Ein eventuell von dem vierten Aspektblock 254' erzeugtes Start/Stopp-Signal wird den Software-Komponenten 234', 236' und 238' direkt zugeführt. In den einzelnen Software-Komponenten wird dieses Start/Stopp-Signal mit einem von der ersten Software-Komponente 232' bereitgestellten Freigabesignal und mit zugeführten Zustandssignalen in Form einer logischen UND-Verknüpfung jeweils verknüpft.
Im Vergleich zu Fig. 7a sind in Fig. 7b Aspektblöcke, die jeweils dem siebten Aspektblock 294, dem achten Aspektblock 296, dem elften Aspektblock 302 und dem zwölften Aspektblock 304 entsprechen, nicht enthalten. Aus Gründen der Übersichtlichkeit wurde auf die Darstellung von logischen Verbindungen zwischen dem neunten Aspektblock 298' und den Software-Komponenten 282', 284', 286' und 288' verzichtet. Die vorstehenden Ausführungen zu den beiden Aspektblöcken 252' und 254' sind in entsprechender Weise auf die beiden Aspektblöcke 298' und 300' übertragbar. Allerdings ist es in dieser Hierarchieebene nicht erforderlich oder vorgesehen, dass von dem zehnten Aspektblock 300' ein Start/Stopp-Signal erzeugt wird. Es reicht aus, wenn in der übergeordneten Hierarchieebene, in diesem Fall der obersten Hierarchieebene, ein Start/Stopp-Signal vorliegt. Ausgehend von der achten Software- Komponente 284' werden der siebten Software-Komponente 282' zwei Positionssignale zugeführt. Somit stehen die bei der Überprüfung der Werkstücke in Bezug auf eine x-Koordinate und in Bezug auf eine y-Koordinate ermittelten Werte zur Verfügung. Eine gegebenenfalls erforderliche Korrektur kann vorgenommen werden. Im Vergleich zu Fig. 9a sind in Fig. 9b Aspektblöcke, die jeweils dem vierzehnten Aspektblock 332 und dem achtzehnten Aspektblock 340 entsprechen, nicht enthalten. Des Weiteren ist anstelle eines Aspektblockes 332, der dem Sicherheitssteue- rungsaspekt zugeordnet ist, ein Aspektblock 338' vorgesehen, der dem Antriebsregelungsaspekt zugeordnet ist. Da bei dem vorliegenden Ausführungsbeispiel in der in Fig. 9b dargestellten Hierarchieebene lediglich ein sicherheitsrelevanter Sensor, nämlich ein durch die Software-Komponente 320' repräsentierter Not-Aus-Taster vorgesehen ist, ist der Einsatz eines Aspektblockes, der dem Sicherheitssteuerungsas- pekt zugeordnet ist, nicht zwingend erforderlich. Das von dem Not-Aus-Taster erzeugte Freigabesignal kann durch entsprechende Verundungen in den einzelnen Software-Komponenten verarbeitet werden.
Der dem Antriebsregelungsaspekt zugeordnete Aspektblock 338' ermöglicht es, den durch die Software-Komponente 326' repräsentierten Motor 310 zu regeln. Somit kann beispielsweise die Motordrehzahl, die Rotationsgeschwindigkeit oder die vom Motor erzeugte Kraft auf einen definierten Wert eingestellt werden. Aus Gründen der Übersichtlichkeit wurde auf die Darstellung von logischen Verbindungen zwischen dem fünfzehnten Aspektblock 334' und den Software-Komponenten 320', 322', 324' und 326' verzichtet. Die vorstehenden Ausführungen zu den beiden Aspektblöcken 252' und 254' sind in entsprechender Weise auf die beiden Aspektblöcke 334' und 336' übertragbar. Auch in dieser Hierarchieebene ist es nicht erforderlich oder vorgesehen, dass von dem sechzehnten Aspektblock 336' ein Start/Stopp-Signal erzeugt wird.
Den Fig. 5 c, 7c, 9c liegt der nicht-kaskadierte Verknüpfungsansatz zugrunde. Der nicht-kaskadierte Verknüpfungsansatz wird beispielsweise dann angewandt, wenn es sich bei der zu steuernden Anlage um eine komplexe Anlage handelt und ergänzend oder alternativ die zu realisierende Ablaufsteuerung komplex ist. Um den kaskadier- ten Verknüpfungsansatz anwenden zu können, ist es nicht erforderlich, dass die in der zu steuernden Anlage enthaltenen Hardware-Komponenten jeweils mit leistungsfähigen Datenverarbeitungskomponenten ausgestattet sind. Dies ist in den Software- Komponenten, die diese Hardware-Komponenten repräsentieren, berücksichtigt. Bei dem nicht-kaskadierten Verknüpfungsansatz ist zur Realisierung einer Ablaufsteuerung zumindest ein Aspektblock, der dem Standardsteuerungsaspekt zugeordnet ist und ein Aspektblock, der dem Verriegelungsaspekt zugeordnet ist, vorzusehen und somit bereitzustellen. Die Funktionalität, die bei dem kaskadierten Verknüpfungsansatz aufgrund der kaskadierten Verknüpfung abgedeckt ist, wird bei dem nicht- kaskadierten Verknüpfungsansatz durch die beiden vorgenannten Aspektblöcke realisiert. Ergänzend kann auch ein Aspektblock, der dem Antriebsregelungsaspekt zugeordnet ist, vorgesehen werden. Hinsichtlich der sicherheitsrelevanten Steuerungsaufgaben ist ein Aspektblock bereitzustellen, der dem Sicherheitssteuerungsas- pekt zugeordnet ist. Dies ist insofern nicht unbedingt zwingend, als beispielsweise bei einem geringen Umfang an sicherheitsrelevanten Sensoren die von diesen erzeugten Signale mittels Verundungen direkt in den Software-Komponenten verarbeitet werden können.
Bei der in Fig. 5c dargestellten obersten Hierarchieebene ist ein erster Aspektblock 248" dargestellt, der dem Standardsteuerungsaspekt zugeordnet ist. Jeweils ausgehend von der zweiten Software-Komponente 234", der dritten Software-Komponente 236" und der vierten Software-Komponente 238" werden dem ersten Aspektblock 248" Zustandssignale, sogenannte „Ready-Signale" zugeführt. Diese Zustandssignale repräsentieren den jeweiligen Zustand derjenigen Hardware-Komponente, der die jeweilige Software-Komponente entspricht. In Abhängigkeit dieser Zustandssignale werden in dem ersten Aspektblock 248" Startsignale erzeugt, von denen jeweils eines einer der Software-Komponenten 234", 236" und 238" zugeführt wird. Mit diesen Startsignalen wird der jeweiligen Software-Komponente angezeigt, dass mit der Abarbeitung der für die zugehörige Hardware-Komponente hinterlegten Arbeitsschritte begonnen werden kann. Vorteilhafterweise sind in dem ersten Aspektblock 248" drei autarke gekapselte Steuerungsfunktionen hinterlegt.
Die in Fig. 5c gewählte Darstellung, gemäß der die Ablaufsteuerung auf der Verarbeitung von Übergabesignalen, genauer gesagt der Zustandssignale und der Startsignale, basiert, soll keine einschränkende Wirkung haben. Alternativ können auch Endlagesensoren vorgesehen sein und ausgewertet werden. In diesem Fall werden dem ersten Aspektblock 248" anstelle der Zustandssignale von den Endlagesensoren erzeugte Sensorsignale zugeführt. Diese Sensorsignale zeigen an, ob bzw. welche Endlage die jeweilige Hardware-Komponente einnimmt. In Abhängigkeit dieser Sensorsignale können dann die vorstehend beschriebenen Startsignale erzeugt werden. In entsprechender Weise können die vorstehenden Ausführungen auch auf die Fig. 7c und 9c übertragen werden.
Da in der obersten Hierarchieebene lediglich ein sicherheitsrelevanter Sensor enthalten ist, ist in den Darstellungen der Fig. 5b und 5c kein Aspektblock enthalten, der dem Sicherheitssteuerungsaspekt zugeordnet ist. Dies soll keine einschränkende Wirkung haben. Selbstverständlich sind Anlagen denkbar, die in der obersten Hierarchieebene eine Vielzahl von sicherheitsrelevanten Sensoren, beispielsweise neben einem Not-Aus-Taster zusätzlich ein Lichtgitter oder eine Schutztüre aufweisen. Bei solchen Anlagen enthält die oberste Hierarchieebene dann einen Aspektblock, der dem Sicherheitssteuerungsaspekt zugeordnet ist. Entsprechendes gilt, wenn sich die Sicherheitslogik nicht allein durch eine Verundung von einzelnen Software- Komponenten zugeführten Signalen realisieren lässt, sondern eine komplexere Sicherheitslogik gefordert ist. Bei der Verundung werden die zugeführten Signale mittels einer logischen UND-Funktion verknüpft, sie werden verundet.
In einem dritten Aspektblock 252" werden Signale von den in derselben Hierarchieebene angeordneten Aspektblöcken ausgewertet. Vorteilhaftweise werden die Signale sämtlicher in derselben Hierarchieebene angeordneter Aspektblöcke ausgewertet. Ferner können dem dritten Aspektblock 252" auch Signale zugeführt werden, die von einer, vorzugsweise von allen in der Hierarchieebene angeordneten Software- Komponente erzeugt werden. Bei den Signalen kann es sich beispielsweise um von den Aspektblöcken oder den Software-Komponenten erzeugte Ausgangssignale handeln und/oder um Signale handeln, die in den Aspektblöcken oder Software- Komponenten erzeugte interne Größen repräsentieren. Die den festgestellten Zuständen entsprechenden Diagnoseinformationen werden einem vierten Aspektblock 254" zugeführt. Von zumindest einem Teil der in der obersten Hierarchieebene enthaltenen Software- Komponenten 232", 234", 236" und 238" und Aspektblöcke 248", 252" und 258" werden einem vierten Aspektblock 254" eine Vielzahl von Signalen zugeführt. Bei diesen Signalen kann es sich beispielsweise um die Zustandssignale und/oder die Startsignale oder um von dem dritten Aspektblock 252" erzeugte Ausgangssignale sowie um interne Signale der Software-Komponenten und/oder der Aspektblöcke handeln. Bei einem internen Signal kann es sich beispielsweise um einen in der zweiten Software-Komponente 234" geführten Stückzahlenzähler handeln.
Der vierte Aspektblock 254", der dem Visualisierungsaspekt zugeordnet ist, hat die Aufgabe, den Status bzw. Zustand der zu steuernden Anlage 210 und der Sicherheitssteuerung 18 anzuzeigen. Vorzugsweise werden dem vierten Aspektblock 254" von allen in der obersten Hierarchieebene angeordneten Software-Komponenten und Aspektblöcken Signale zugeführt. Im Rahmen der Anzeigefunktionalität gibt der vierte Aspektblock 254" beispielsweise Diagnoseinformationen aus. Ergänzend oder alternativ erzeugt er Daten, die der Visualisierung des mit der zu steuernden Anlage 210 abgearbeiteten Prozesses dienen und mit denen sich beispielsweise der aktuelle Bearbeitungsstand des Prozesses ablesen lässt.
Ergänzend kann der vierte Aspektblock 254" neben der Anzeigefunktionalität auch eine Bedienfunktionalität umfassen. Somit ist in dem vierten Aspektblock 254" die für die Realisierung einer HMI-Schnittstelle erforderliche Funktionalität hinterlegt. Was die Bedienfunktionalität angeht, so ist beispielsweise folgende Ausgestaltung denkbar: Mittels einer vorzugsweise interaktiv ausgestalteten Anzeigeeinheit können dem Bediener der zu steuernden Anlage 210 mehrere Entscheidungsoptionen zur Auswahl angezeigt werden, aus denen er eine durch Berühren der Anzeigefläche auswählen kann. Beispielsweise können die für die Inbetriebnahme der zu steuernden Anlage 210 erforderlichen Schritte angezeigt werden, wobei der Bediener deren Ausführung durch Berühren der Anzeigefläche quittieren muss. Sind alle diese Schritte erfolgreich durchgeführt, so wird automatisch ein Startsignal erzeugt, durch welches die Anlage 210 in Betrieb genommen wird. Ferner ist es denkbar, ein Stopp- Feld vorzusehen, durch dessen Berührung der Bediener die Anlage 210 außer Betrieb nehmen kann. Das Startsignal und das Stoppsignal werden dem ersten Aspektblock 248" zugeführt. Alternativ kann auch eine nicht-interaktive Anzeigeeinheit verwendet werden, bei der der vorstehend beschriebene manuellen Start bzw. manuelle Stopp mittels zweier Taster auslösbar ist.
Die vorstehenden Ausführungen, die die beiden Aspektblöcke 252" und 254" betreffen, können in entsprechender Weise jeweils auch auf die beiden Aspektblöcke 252 und 254 übertragen werden. Auch können diese Ausführungen auf entsprechende Aspektblöcke übertragen werden, die in einer niedrigeren Hierarchieebene enthalten sind.
Einem sechsten Aspektblock 258" werden ebenfalls die Zustandssignale zugeführt, die auch dem ersten Aspektblock 248" zugeführt werden. In Abhängigkeit dieser Zustandssignale erzeugt der sechste Aspektblock 258" für jede der Software- Komponenten 234", 236" und 238" ein jeweils zugeordnetes Verriegelungsfreigabesignal. Mit dem jeweiligen Verriegelungsfreigabesignal wird die jeweilige Software- Komponente freigegeben und bei Vorliegen eines entsprechenden Startsignals kann mit der Abarbeitung der jeweils hinterlegten Arbeitsschritte begonnen werden. Mit Hilfe der Verriegelungsfreigabesignale ist gewährleistet, dass beispielsweise eine Hardware-Komponente erst dann entsprechend der in dem Anwenderprogramm hinterlegten Steuerungsanweisungen zu arbeiten beginnt, wenn andere Hardware- Komponenten eine definierte Grundposition eingenommen haben.
Das von dem sechsten Aspektblock 258" für die jeweilige Software-Komponente 234", 236" und 238" erzeugte Verriegelungsfreigabesignal wird mit einem in der ersten Software-Komponente 232" erzeugten Freigabesignal zu einem für die jeweilige Software-Komponente geltenden Gesamtfreigabesignal verundet. Bei der Verun- dung werden für jede der Software-Komponenten 234", 236" und 238" das Verriegelungsfreigabesignal und das von der ersten Software-Komponente 232" erzeugte Freigabesignal mittels einer logischen UND-Funktion verknüpft. Bei der in Fig. 5 c dargestellten nicht-kaskadierten Verknüpfung tauschen die einzelnen Software-Komponenten keine Zustandssignale untereinander aus. Stattdessen sind ein erster Aspektblock 248", der dem Standardsteuerungsaspekt zugeordnet ist und ein sechster Aspektblock 258", dem der Verriegelungsaspekt zugeordnet ist, vorgesehen.
Fig. 5c ist beispielhaft eine strichliniert dargestellte logische Verbindung zwischen zwei Software-Komponenten, konkret zwischen den beiden Software-Komponenten 236" und 238" entnehmbar. Über solch eine logische Verbindung können Daten direkt zwischen einzelnen Software-Komponenten ausgetauscht werden. Über die konkret dargestellte logische Verbindung kann der dritten Software-Komponente 236", die der Prozessstation 214 entspricht, ein Signal "Abweichung vom Soll" zugeführt werden. Dieses Signal repräsentiert das in der Teststation 216 erzielte Prüfergebnis. Wird beispielsweise in der Teststation 216 festgestellt, dass aufgrund einer verschleißbedingten Bohrerverkürzung die gebohrten Löcher nicht mehr tief genug sind, kann somit die Prozessstation 214 dazu veranlasst werden, den Hub des Bohrzylinders entsprechend zu verlängern.
In Fig. 7c ist ein siebter Aspektblock 294" dargestellt, der dem Standardsteuerungsaspekt zugeordnet ist. Jeweils ausgehend von den Software-Komponenten 282", 284", 286" und 288" werden dem siebten Aspektblock 294" Zustandssignale zugeführt. Zusätzlich wird dem siebten Aspektblock 294" ausgehend von der achten Software- Komponente 284", die das Prüfmodul 272 repräsentiert, ein Ergebnissignal zugeführt, welches das in dem Prüfmodul 272 ermittelte Prüfergebnis repräsentiert. In Abhängigkeit der zugeführten Zustandssignale werden in dem siebten Aspektblock 294" Startsignale erzeugt, von denen jeweils eines einer der Software-Komponenten 282", 284", 286" und 288" zugeführt wird. Bei der Ermittlung der Startsignale kann das mit dem Ergebnissignal zugeführte Prüfergebnis berücksichtigt werden. Somit besteht die Möglichkeit, dass bei einem schlecht ausgefallenen Prüfergebnis die Ablaufsteuerung und somit der Prozess, der mit der zu steuernden Anlage abgearbeitet wird, zumindest in einem gewissen Teilumfang unterbrochen werden kann. Entsprechend den Ausführungen zu Fig. 5c können auch hier Endlagesensoren zum Einsatz kommen. Neben dem siebten Aspektblock 294" sind ferner ein neunter Aspektblock 298" und ein zehnter Aspektblock 300" vorgesehen. Der neunte Aspektblock 298" ist dem Diagnoseaspekt zugeordnet und der zehnte Aspektblock 300" ist dem Visualisierungsaspekt zugeordnet. Was die Signale angeht, die diesen beiden Aspektblöcken zugeführt und in diesen verarbeitet werden, so sei auf die die beiden Aspektblöcke 252" und 254" betreffenden Ausführungen verwiesen. Diese Ausführungen sind in entsprechender Weise auf die beiden Aspektblöcke 298" und 300", gegebenenfalls auf die Prozessstation 214 bezogen übertragbar.
Einem zwölften Aspektblock 304", der dem Verriegelungsaspekt zugeordnet ist, wird das in der neunten Software-Komponente 286" erzeugte Zustandssignal zugeführt. Unter Auswertung dieses Zustandssignals wird in dem zwölften Aspektblock 304" ein Verriegelungsfreigabesignal erzeugt, welches der siebten Software-Komponente 282" zugeführt wird. Einzelheiten zu der den Rundtisch 270 und das Bohrmodul 274 betreffenden Verriegelung können den Ausführungen zu dem zwölften Aspektblock 304 entnommen werden.
Von einer sechsten Software-Komponente 280" wird ein Freigabesignal erzeugt, welches den Software-Komponenten 282", 284", 286" und 288" zugeführt wird. In den Software-Komponenten 284", 286" und 288" wird dieses Freigabesignal mit dem jeweils zugeführten Startsignal verundet. Bei der Software-Komponente 282" wird bei der Verundung neben dem Startsignal und dem Freigabesignal auch noch das Verriegelungsfreigabesignal berücksichtigt.
Bei der in Fig. 9c dargestellten nicht-kaskadierten Verknüpfung tauschen die einzelnen Software-Komponenten keine Zustandssignale untereinander aus. Statt dessen sind ein dreizehnter Aspektblock 330", der dem Standardsteuerungsaspekt zugeordnet ist und ein achtzehnter Aspektblock 340", der dem Verriegelungsaspekt zugeordnet ist, vorgesehen. Der dreizehnte Aspektblock 330" ist sowohl mit einer zwölften Software- Komponente 322", die den Bohrzylinder repräsentiert, als auch mit einer dreizehnten Software-Komponente 324", die den Transferzylinder repräsentiert, als Teil einer Regelungsschleife verbunden. Dabei werden dem dreizehnten Aspektblock 330" sowohl ausgehend von der zwölften Software-Komponente 322" als auch ausgehend von der dreizehnten Software-Komponente 324" Positionssignale zugeführt. Das von der zwölften Software-Komponente 322" erzeugte Positionssignal repräsentiert die Position des Kolbens des Bohrzylinders und das von der dreizehnten Software- Komponente 324" erzeugte Positionssignal repräsentiert die Position des Kolbens des Transferzylinders. Dabei reicht es aus, beispielsweise zwei Kolbenpositionen unterscheiden zu können. Eine Grundstellung, bei der der Kolben vollständig in den Zylinder eingefahren ist und eine Arbeitsstellung, bei der der Kolben aus dem Zylinder ausgefahren ist. Diese beiden Kolbenpositionen können beispielsweise unter Verwendung zweier entsprechend in dem jeweiligen Zylinder angeordneter Sensoren erfasst werden. Alternativ zu der Erfassung lediglich zweier Kolbenpositionen kann auch der exakte Kolbenhub beispielsweise unter Verwendung eines mathematischen Modells ermittelt werden. Hierzu wird vorzugsweise der Fahrbefehl, mit dem der jeweilige Kolben verstellt wird, genauer gesagt das Verstellsignal und eine zeitliche Bedingung ausgewertet.
Für den Fall, dass die Kolbenposition mittels zweier Sensoren erfasst wird, sind hinsichtlich deren softwaretechnischer Berücksichtigung zwei Ansätze denkbar, die am Beispiel des Bohrzylinders 314 und somit der zwölften Software-Komponente 322" erläutert werden sollen. Bei einem ersten Ansatz sind die beiden Sensoren der zwölften Software-Komponente 322" zugeordnet. Die Software-Komponente und die beiden Sensoren bilden somit eine programmtechnische Einheit. Das für die beiden Sensoren vorzunehmende I/O-Mapping ist in der nächst niedrigen Hierarchieebene vorzunehmen. Bei einem zweiten Ansatz sind die beiden Sensoren der zwölften Software-Komponente 322" nicht fest zugeordnet. In diesem Fall wird das I/O- Mapping in derjenigen Hierarchieebene durchgeführt, die in Fig. 9c dargestellt ist. In dem dreizehnten Aspektblock 330" wird in Abhängigkeit des von der zwölften Software-Komponente 322" zugeführten Positionssignals ein Verstellsignal für den Bohrzylinder 314 ermittelt und der zwölften Software-Komponente 322" zugeführt. In entsprechender Weise wird in dem dreizehnten Aspektblock 330" ein Verstellsignal für den Transferzylinder 312 ermittelt, welches der dreizehntem Software- Komponente 324" zugeführt wird. Mit den beiden Verstellsignalen wird ein Ausbzw. Einfahren des jeweiligen Zylinders realisiert. Zum Aus- bzw. Einfahren werden im Zylinder angeordnete Ventile entsprechend angesteuert. Darüber hinaus wird in dem dreizehnten Aspektblock 330" ein Start/Stopp-Signal erzeugt, welches einem siebzehnten Aspektblock 338" zugeführt wird. Mit diesem Signal wird die in dem siebzehnten Aspektblock 338" hinterlegte Antriebssteuerung des Motors 310 gestartet oder beendet. Ferner wird in dem dreizehnten Aspektblock 330" ein Betriebszu- standssignal erzeugt und dem achtzehnten Aspektblock 340" zugeführt. Mit diesem Signal wird dem achtzehnten Aspektblock 340" zur Realisierung einer Verriegelungsfunktion angezeigt, ob der Motor 310 eingeschaltet oder ausgeschaltet ist bzw. ob er läuft oder nicht. Diese Information ist für die Realisierung einer Verriegelungsfunktion wichtig. Mit der Verriegelungsfunktion soll sichergestellt werden, dass weder der Bohrzylinder 314 noch der Transferzylinder 312 verfahren werden, solange der Motor 310 angesteuert ist und somit mit dem Bohrmodul 274 gebohrt wird. Aus diesem Grund werden in dem achtzehnten Aspektblock 340" entsprechende Stoppsignale erzeugt, von denen jeweils eines der zwölften Software-Komponente 322" und eines der dreizehnten Software-Komponente 324" zugeführt wird.
Es ist auch denkbar, anstelle der beiden Signale, nämlich des Start/Stopp-Signals und des Betriebszustandssignals ein einziges Signal zu verwenden, welches sowohl dem siebzehnten Aspektblock 338" als auch dem achtzehnten Aspektblock 340" zugeführt wird. Die Verwendung dieser beiden Signale ermöglicht allerdings vorteilhafterweise eine zeitliche Differenzierung. Entsprechend dem Anlaufverhalten des Motors 310 kann das Betriebszustandssignal bezogen auf das Start/Stopp-Signal zeitlich etwas verzögert erzeugt werden. Insgesamt ist in dem dreizehnten Aspektblock 330" derjenige Umfang des Anwenderprogramms 38 hinterlegt, der zum einen festlegt, wie der Transferzylinder 312 und der Bohrzylinder 314 zu bewegen sind und der zum ande- ren festlegt, wann der Motor 310 anzusteuern ist. Folglich ist die Reihenfolge definiert, in der die beiden Zylinder 312, 314und der Motor 310 anzusteuern sind,
Mit einem siebzehnten Aspektblock 338", der dem Antriebsregelungsaspekt zugeordnet ist, ist es möglich, den durch die vierzehnte Software-Komponente 326' repräsentierten Motor 310 zu regeln. Somit kann vorzugsweise die Motordrehzahl geregelt und demzufolge auf einen definierten Wert eingestellt werden. Es kann aber auch die Rotationsgeschwindigkeit oder die vom Motor erzeugte Kraft geregelt werden. Hierzu wird dem siebzehnten Aspektblock 338" ausgehend von der Software-Komponente 326" ein entsprechender Istwert zugeführt. In dem siebzehnten Aspektblock 338" wird in Abhängigkeit dieses Istwertes ein entsprechender Sollwert ermittelt, der der vierzehnten Software-Komponente 326" zugeführt wird. Der siebzehnte Aspektblock 338" und die vierzehnte Software-Komponente 326" sind als Teil einer Regelschleife miteinander verbunden. In der vierzehnten Software-Komponente 326" ist der die Regelung des Motors 310 festlegende Umfang des Anwenderprogramms 38 hinterlegt. Dabei wird der Sollwert in einen Wert für den Strom umgesetzt, mit dem der Motor 310 anzusteuern ist. Vorzugsweise sind die zur Erfassung der am Motor 310 vorliegenden Istwerte benötigten Sensoren programmtechnisch der vierzehnten Software-Komponente 326 zugeordnet. Das I/O-Mapping für diese Sensoren erfolgt dann in der nächst niedrigen Hierarchieebene. Bei diesen Sensoren kann es sich beispielsweise um Sensoren zur Erfassung der Rotationsgeschwindigkeit oder um Sensoren zur Erfassung der an den Motorwicklungen anliegenden Spannung handeln.
Entsprechend den Ausführungen zu Fig. 9b ist auch in Fig. 9c kein Aspektblock vorgesehen, der dem Sicherheitssteuerungsaspekt zugeordnet ist. Wären in dieser Hierarchieebene beispielsweise mehrere sicherheitsrelevante Sensoren vorhanden, würde auch in dieser Hierarchieebene ein Aspektblock zum Einsatz kommen, der dem Sicherheitssteuerungsaspekt zugeordnet ist.
Ferner sind in Fig. 9c ein fünfzehnter Aspektblock 334" und ein sechzehnter Aspektblock 336" dargestellt. Der fünfzehnte Aspektblock 334" ist dem Diagnoseaspekt zugeordnet und der sechzehnte Aspektblock 336" ist dem Visualisierungsaspekt zugeordnet. Was die Signale angeht, die diesen beiden Aspektblöcken zugeführt und somit in diesen verarbeitet werden, so sei auf die die beiden Aspektblöcke 252" und 254" betreffenden Ausführungen verwiesen. Diese Ausführungen sind in entsprechender Weise auf die beiden Aspektblöcke 334" und 336" anwendbar.
Von einer elften Software-Komponente 320" wird ein Freigabesignal erzeugt, welches den Software-Komponenten 322", 324" und 326" zugeführt und mit gegebenenfalls vorhandenen anderen Signalen verundet wird.
Dass bei dem gewählten Ausführungsbeispiel in der obersten Hierarchieebene neben dem Not-Aus-Taster 218 keine weiteren Sensoren vorgesehen sind, soll keine einschränkende Wirkung haben. Es sind auch zu steuernde Anlagen denkbar, die in der obersten Hierarchieebene mehrere Sensoren aufweisen. Entsprechendes gilt auch für diejenigen Hierarchieebenen, die unterhalb der obersten Hierarchieebene liegen.
Die in den Fig. 5a, 5b, 5c, 7a, 7b, 7c, 9a, 9b und 9c gewählte Darstellung, gemäß der in den einzelnen Hierarchieebenen ein eignständiger Aspektblock vorgesehen ist, der dem Diagnoseaspekt zugeordnet ist, soll keine einschränkende Wirkung haben. Alternativ ist es auch denkbar, in den Software-Komponenten und/oder den Aspektblöcken selbst jeweils eine Diagnosefunktionalität anzusiedeln.
An dieser Stelle sei darauf hingewiesen, dass die Erläuterung sowohl des kaskadierten Verknüpfungsansatzes als auch des nicht-kaskadierten Verknüpfungsansatzes unter Verwendung derselben zu steuernden Anlage 210 kein Widerspruch darstellen soll, da grundsätzlich beide Verknüpfungsansätze anwendbar sind, jedoch bei Vorliegen der vorstehend aufgeführten Gegebenheiten einer von beiden bevorzugt angewandt wird.
Vorteilhafterweise wird bei einer komplexen Anlage mit vielen verschiedenen Hardwarekomponenten für zumindest folgende Steuerungsaspekte jeweils ein Aspektteil- Programm erstellt: Standardsteuerungsaspekt zur Steuerung des nicht- sicherheitsrelevanten Prozessablaufs der Anlage unter Berücksichtigung eines Großteils der Hardwarekomponenten, Sicherheitssteuerungsaspekt zur Steuerung aller sicherheitsrelevanten Teilprozesse und Diagnoseaspekt zur Erstellung und Visualisierung von Diagnosemeldungen. Des weiteren kann für folgende Aspekte jeweils ein Aspektteilprogramm erstellt werden: Antriebsregelung, Kühlung, Zugriffsberechtigung, Wartung, Verriegelung, Handbetrieb, Datenverwaltung. Mit solchen Aspektteilprogrammen kann die Steuerung einer komplexen Anlage über viele verschiedene Hardwarekomponenten hinweg unter einem einheitlichen, aspektbezogenen Blickwinkel programmiert werden, wobei die jeweils anderen Aspekte „ausgeblendet" werden.

Claims

Patentansprüche
1. Verfahren zum Erstellen eines Anwenderprogramms (38) für eine Sicherheitssteuerung (18), die dazu ausgebildet ist, eine Anlage (210) mit einer Vielzahl von Hardware-Komponenten zu steuern, wobei die Vielzahl von Hardware- Komponenten jeweils zumindest einen Sensor und zumindest einen Aktor beinhaltet, mit folgenden Schritten:
Bereitstellen einer Vielzahl (146, 174) von Software-Komponenten für die Vielzahl von Hardware-Komponenten, wobei die Vielzahl (146, 174) von Software-Komponenten jeweils zumindest einen Logikeingang (404) und zumindest einen Logikausgang (406) aufweisen und zumindest einen Aspektblock (92, 112, 136, 180, 198, 380, 408) enthalten, wobei jeder dieser Aspektblöcke (92, 112, 136, 180, 198, 380, 408) einem von mehreren untereinander unterschiedlichen Steuerungsaspekten zugeordnet ist, wobei jeder dieser Steuerungsaspekte einen funktionalen Teilaspekt der Sicherheitssteuerung (18) repräsentiert, wobei jeder dieser Aspektblöcke (92, 112, 136, 180, 198, 380, 408) eine Anzahl (386) von Signaleingängen und eine Anzahl (388) von Signalausgängen aufweist, wobei dem jeweiligen Aspektblock (92, 112, 136, 180, 198, 380, 408) über seine Anzahl (386) von Signaleingängen eine Anzahl von Eingangssignalen zugeführt werden können und dieser Aspektblock (92, 112, 136, 180, 198, 380, 408) über seine Anzahl (388) von Signalausgängen eine Anzahl von Ausgangssignalen ausgeben kann, und wobei die Ausgangssignale in Abhängigkeit von den Eingangssignalen ermittelt werden,
Erstellen eines Komponententeilprogramms durch logisches Verknüpfen der Vielzahl (174) von Software-Komponenten, wobei zumindest ein Teil der Logikeingänge (404) und zumindest ein Teil der Logikausgänge (406) der Software-Komponenten (174) untereinander verbunden werden,
Erstellen eines Aspektteilprogramms für zumindest einen Steuerungsaspekt, wobei für zumindest einen Aspektblock (180, 198), der in der Vielzahl (174) von Software-Komponenten enthalten ist, zumindest einem Teil der Signaleingänge Sensoren zugeordnet werden, deren Sensorsignale in dem jeweiligen Aspektblock (180, 198) verarbeitet werden, und wobei zumindest einem Teil der Signalausgänge Aktoren zugeordnet werden, die mit den in dem jeweiligen Aspektblock (180, 198) ermittelten Ausgangssignalen angesteuert werden,
Zusammenfügen des Komponententeilprogramms und des Aspektteilprogramms zu dem Anwenderprogramm (38).
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass bei dem Bereitstellen der Vielzahl (146) von Software-Komponenten zumindest eine Software- Komponente (56) aus einer Menge (54) vordefinierter Software-Komponenten ausgewählt wird.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die vordefinierten Software-Komponenten (56, 58, 60, 62) jeweils eine von mehreren untereinander unterschiedlichen Hardware-Komponentenarten repräsentieren, wobei jede dieser Hardware-Komponentenarten eine Funktionalität aufweist, die für diese Hardware-Komponentenart als solche charakteristisch ist, und die jede der zu dieser Hardware-Komponentenart zugehörige Hardware- Komponente aufweist, wobei die vordefinierten Software-Komponenten (56, 58, 60, 62) jeweils diejenigen Aspektblöcke (136) enthalten, die denjenigen Steuerungsaspekten zugeordnet sind, die für diejenige Hardware- Komponentenart von Bedeutung sind, die die vordefinierte Software- Komponente (56, 58, 60, 62) repräsentiert.
4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass bei dem Bereitstellen der Vielzahl (146) von Software-Komponenten zumindest eine neue Software-Komponente (66, 68, 70) erstellt wird.
5. Verfahren nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, dass die vordefinierten Software-Komponenten (56, 58, 60, 62) und/oder die neu erstellten Software-Komponenten (66, 68, 70) jeweils entweder als Gruppenkomponente (58, 70, 110) oder als Elementarkomponente (56, 60, 62, 66, 68, 90, 134) ausgebildet sind, wobei eine Gruppenkomponente (110) zumindest einen Aspektblock (112) und zumindest eine Software-Komponente (118, 124) enthält, wobei die enthaltene Software-Komponente (118, 124) selbst wiederum als Elementarkomponente (118) oder als Gruppenkomponente (124) ausgebildet sein kann, und wobei eine Elementarkomponente (90, 134) lediglich zumindest einen Aspektblock (92, 136) enthält.
6. Verfahren nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, dass es sich bei den vordefinierten Software-Komponenten (56, 58, 60, 62) und/oder bei der neu erstellten Software-Komponente (66, 68, 70) jeweils um gekapselte Software-Komponenten handelt, an denen keine Änderungen vorgenommen werden können.
7. Verfahren nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, dass das Aspektteilprogramm Aspektblöcke (136, 180, 198) beinhaltet, die zumindest zwei der folgenden, voneinander verschiedenen Steuerungsaspekte repräsentieren: ein Standardsteuerungsaspekt, ein Sicherheitssteuerungsaspekt, ein Diagnoseaspekt, ein Visualisierungsaspekt, ein Antriebsregelungsaspekt, ein Kühlungsaspekt.
8. Verfahren nach Anspruch 7, dadurch gekennzeichnet, dass Aspektblöcke (136), die den Sichern ei tssteuerungsaspekt repräsentieren, vom Anwender nicht verändert werden können.
9. Verfahren nach einem der Ansprüche 1 bis 8, dadurch gekennzeichnet, dass für eine Vielzahl der untereinander unterschiedlichen Steuerungsaspekte jeweils ein Aspektteilprogramm erstellt wird, wobei das Erstellen der einzelnen Aspektteilprogramme getrennt voneinander erfolgt.
10. Verfahren nach einem der Ansprüche 1 bis 9, dadurch gekennzeichnet, dass in den Aspektblöcken (380, 408) jeweils ein Funktionsprogramm hinterlegt ist, welches Aspekteigenschaften einer Hardware-Komponente für denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspektblock (380, 408) zugeordnet ist, wobei es sich um diejenige Hardware-Komponente handelt, der diejenige Software-Komponente (400) entspricht, die den jeweiligen Aspektblock (380, 408) enthält, wobei zumindest einer der mehreren untereinander unterschiedlichen Steuerungsaspekte und somit die für diesen festgelegten Aspekteigenschaften die Hardware-Komponente als solche betreffen.
11. Verfahren nach einem der Ansprüche 1 bis 10, dadurch gekennzeichnet, dass zumindest ein Teil (132) der bereitgestellten Vielzahl (146) von Software- Komponenten neben einer Anzahl (112) von Aspektblöcken zusätzlich eine Anzahl von Elementarkomponenten (118) und/oder eine Anzahl von Gruppenkomponenten (124) enthält, wobei eine Gruppenkomponente (110) zumindest einen Aspektblock (112, 380) und zumindest eine Software- Komponente (118, 124, 400) enthält, wobei die enthaltene Software- Komponente (118, 124, 400) selbst wiederum als Elementarkomponente (90, 134) oder als Gruppenkomponente (110) ausgebildet sein kann, und wobei eine Elementarkomponente (90, 134) lediglich zumindest einen Aspektblock (92, 136) enthält, wobei in der Anzahl von Aspektblöcken (112) jeweils ein Funktionsprogramm hinterlegt ist, welch^s~Äsp^lϊteigenschaften "für denjenigen Steuerungsaspekt festlegt, dem der jeweilige Aspektblock (112) zugeordnet ist, wobei zumindest einer der mehreren untereinander unterschiedlichen Steuerungsaspekte und somit die für diesen festgelegten Aspekteigenschaften das Zusammenwirken zumindest eines Teils der Anzahl von Elementarkomponenten (118) und7oder zumindest eines Teils der Anzahl (124) von Gruppenkomponenten betrifft.
12. Verfahren nach einem der Ansprüche 1 bis 11, dadurch gekennzeichnet, dass das Anwenderprogramm (38) hierarchisch strukturiert ist, wobei durch die bereitgestellte Vielzahl (146, 212, 214, 216) von Software-Komponenten eine Hierarchieebene (424) festgelegt wird, bei der es sich um die oberste Hierarchieebene handelt, und wobei durch zumindest eine Software-Komponente (118, 124, 274), die in einer derjenigen Software-Komponenten (132, 214) enthalten ist, die zu der bereitgestellten Vielzahl (146, 212, 214, 216) von Software-Komponenten gehört, eine weitere, unterhalb der obersten Hierarchieebene liegende Hierarchieebene (426) festgelegt wird.
13. Verfahren nach einem der Ansprüche 1 bis 12, dadurch gekennzeichnet, dass zusätzlich zu der Vielzahl (146) von Software-Komponenten eine Anzahl (152) von Aspektblöcken bereitgestellt werden, wobei zumindest ein Teil der Software-Komponenten und zumindest ein Teil (152) der Aspektblöcke zu einer neuen Software-Komponente (158) zusammengefasst werden.
14. Verfahren nach einem der Ansprüche 1 bis 13, dadurch gekennzeichnet, dass das Anwenderprogramm (38) in eine Vielzahl von Hierarchieebenen (424, 426, 428) strukturiert ist, von denen eine ausgewählt wird, wobei beim Erstellen des Aspektteilprogramms lediglich diejenigen Aspektblöcke berücksichtigt werden, die in der ausgewählten Hierarchieebene enthalten sind.
15. Vorrichtung zum Erstellen eines Anwenderprogramms (38) für eine Sicherheitssteuerung (18) , die dazu ausgebildet ist, eine Anlage (210) mit einer Vielzahl von Hardware-Komponenten zu steuern, wobei die Vielzahl von Hard- ware-Komponenten jeweils zumindest ein Sensor und zumindest einen Aktor umfassen,
mit ersten Einheiten (12, 14, 16, 50) zum Bereitstellen einer Vielzahl (146, 174) von Software-Komponenten für die Vielzahl von Hardware-Komponenten, wobei die Vielzahl (146, 174) von Software-Komponenten jeweils zumindest einen Logikeingang (404) und zumindest einen Logikausgang (406) aufweisen und zumindest einen Aspektblock (92, 112, 136, 180, 198, 408) enthalten, wobei jeder dieser Aspektblöcke (92, 112, 136, 180, 198, 408) einem von mehreren untereinander unterschiedlichen Steuerungsaspekten zugeordnet ist, wobei jeder dieser Steuerungsaspekte einen eigenständigen Teilaspekt der Sicherheitssteuerung (18) repräsentiert, und wobei jeder dieser Aspektblöcke (92, 112, 136, 180, 198, 408) eine Anzahl (386) von Signaleingängen und eine Anzahl (388) von Signalausgängen aufweist, wobei dem jeweiligen Aspektblock (92, 112, 136, 180, 198, 408) über seine Anzahl (386) von Signaleingängen eine Anzahl von Eingangssignalen zugeführt werden können und dieser Aspektblock (92, 112, 136, 180, 198, 408) über seine Anzahl (388) von Signalausgängen eine Anzahl von Ausgangssignalen ausgeben kann, wobei die Anzahl von Ausgangssignalen zumindest in Abhängigkeit der Anzahl von Eingangssignalen ermittelt werden,
mit zweiten Einheiten (172) zum Erstellen eines Komponenten teilprogramms durch logisches Verknüpfen der Vielzahl (174) von Software-Komponenten, wobei hierzu zumindest ein Teil der Logikeingänge (404) und zumindest ein Teil der Logikausgänge (406) der Software-Komponenten (174) untereinander verbunden werden,
mit dritten Einheiten (178, 196) zum Erstellen eines Aspektteilprogramms für zumindest einen Steuerungsaspekt, wobei zumindest für einen Teil derjenigen Aspektblöcke (180, 198), die in der Vielzahl (174) von Software-Komponenten enthalten sind, jeweils zumindest einem Teil der Signaleingänge Sensoren zugeordnet werden, deren Sensorsignale in dem jeweiligen Aspektblock (180, 198) verarbeitet werden, und zumindest einem Teil der Signalausgänge Aktoren zugeordnet werden, die mit den in dem jeweiligen Aspektblock (180, 198) ermittelten Ausgangssignalen angesteuert werden, und
mit vierten Einheiten (42, 46) zum Zusammenfügen des Komponententeilpro- gramms und Aspektteilprogramms zu dem Anwenderprogramm.
16. Computerprogramm mit Programmcodemitteln zum Durchführen eines Verfahrens nach einem der Ansprüche 1 bis 14, wenn das Computerprogramm (16) auf einem Computer (12) ausgeführt wird.
PCT/EP2009/008279 2008-11-25 2009-11-20 Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung WO2010060575A1 (de)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN200980155248.2A CN102292680B (zh) 2008-11-25 2009-11-20 用于为安全控制装置创建应用程序的方法和装置
EP09796615A EP2353051A1 (de) 2008-11-25 2009-11-20 Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung
JP2011536786A JP2012510099A (ja) 2008-11-25 2009-11-20 安全制御装置用ユーザープログラムの作成方法および装置
US13/111,144 US8832667B2 (en) 2008-11-25 2011-05-19 Method and programming tool for creating a user program for a safety controller

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008060003A DE102008060003A1 (de) 2008-11-25 2008-11-25 Verfahren und Vorrichtung zum Erstellen eines Anwenderprogramms für eine Sicherheitssteuerung
DE102008060003.2 2008-11-25

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US13/111,144 Continuation US8832667B2 (en) 2008-11-25 2011-05-19 Method and programming tool for creating a user program for a safety controller

Publications (1)

Publication Number Publication Date
WO2010060575A1 true WO2010060575A1 (de) 2010-06-03

Family

ID=41785781

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/008279 WO2010060575A1 (de) 2008-11-25 2009-11-20 Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung

Country Status (6)

Country Link
US (1) US8832667B2 (de)
EP (1) EP2353051A1 (de)
JP (1) JP2012510099A (de)
CN (1) CN102292680B (de)
DE (1) DE102008060003A1 (de)
WO (1) WO2010060575A1 (de)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
ATE529789T1 (de) 2007-07-05 2011-11-15 Sick Ag Verfahren zum programmieren einer sicherheitssteuerung
EP2221679B1 (de) * 2009-02-11 2012-06-06 Siemens Aktiengesellschaft Verfahren zur logischen Verschaltung von Sicherheitskreisen in einer industriellen Automatisierungsordnung und Projektierungseinrichtung zur Durchführung des Verfahrens
JP5687563B2 (ja) * 2011-05-25 2015-03-18 株式会社東芝 プラント制御ロジック設計支援装置、プログラムおよびプラント制御ロジック設計支援方法
DE102011109888B4 (de) * 2011-08-10 2020-01-23 Phoenix Contact Gmbh & Co. Kg Verfahren und Vorrichtung zum automatischen Erstellen einer ausführbaren Sicherheitsfunktion für ein Gerät
DE102013113720A1 (de) 2013-12-09 2015-06-11 Wieland Electric Gmbh Verfahren zum Programmieren einer Sicherheitssteuerung
DE102014213716A1 (de) * 2014-07-15 2016-01-21 Robert Bosch Gmbh Verfahren und Anordnung zur Analyse und Diagnose eines Steuergeräts eines Antriebssystems
EP3088976B1 (de) * 2015-04-28 2017-11-29 Siemens Aktiengesellschaft Verfahren zum betreiben einer automatisierungseinrichtung und automatisierungseinrichtung
DE112016004638T5 (de) 2015-10-09 2018-06-21 Fisher-Rosemount Systems, Inc. System und verfahren zum repräsentieren einer ursache-wirkungs-tabelle als satz numerischer repräsentationen
DE102015120314A1 (de) 2015-11-24 2017-05-24 Pilz Gmbh & Co. Kg Verfahren zum Programmieren einer Sicherheitssteuerung
JP6458754B2 (ja) * 2016-03-14 2019-01-30 オムロン株式会社 プログラム開発支援装置、プログラム開発支援プログラムおよびプログラム開発支援方法
US10216182B2 (en) * 2016-03-31 2019-02-26 Avaya Inc. Command and control of a robot by a contact center with third-party monitoring
US10713015B2 (en) 2016-05-15 2020-07-14 Servicenow, Inc. Visual programming system
JP6747104B2 (ja) * 2016-06-30 2020-08-26 オムロン株式会社 セーフティシステム、プログラム、および方法
DE102017210488A1 (de) * 2017-06-22 2018-12-27 Siemens Aktiengesellschaft Steuerung für ein Schienenfahrzeug
DE102018120347A1 (de) * 2018-08-21 2020-02-27 Pilz Gmbh & Co. Kg Automatisierungssystem zur Überwachung eines sicherheitskritischen Prozesses
CN110489174A (zh) * 2019-08-20 2019-11-22 上海航空工业(集团)有限公司 一种用于机载软硬件匹配性加载系统实现的方法
DE102020109545A1 (de) 2020-04-06 2021-10-07 Ifm Electronic Gmbh Verfahren zum Betreiben eines Sicherheitscontrollers

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004003570A1 (de) * 2003-01-28 2005-03-10 Fisher Rosemount Systems Inc Integriertes Diagnosesystem in einer Prozessanlage mit einem Prozesssteuerungssystem und einem Sicherheitssystem

Family Cites Families (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11119808A (ja) * 1997-10-17 1999-04-30 Yokogawa Electric Corp フィールドバスを用いたプラント制御システム
DE19861281B4 (de) * 1998-09-09 2008-10-02 Halang, Wolfgang A., Prof. Dr. Dr. Elektronischer Vergleicher zweier Binärworte mit ausfallsicherheitsgerichtetem Ausgabeverhalten
DE10108962A1 (de) 2001-02-20 2002-09-12 Pilz Gmbh & Co Verfahren und Vorrichtung zum Programmieren einer Sicherheitssteuerung
US6549034B1 (en) * 2001-12-27 2003-04-15 Rockwell Automation Technologies, Inc. Programmable logic controller for safety systems with reduced cross-wiring
JP4062492B2 (ja) 2002-03-07 2008-03-19 オムロン株式会社 安全条件設定支援装置及びプログラム並びに記録媒体
US20040019393A1 (en) * 2002-07-25 2004-01-29 Eileen Heider System and method for model base control
US6975966B2 (en) 2003-01-28 2005-12-13 Fisher-Rosemount Systems, Inc. Integrated diagnostics in a process plant having a process control system and a safety system
US7324856B1 (en) * 2003-09-25 2008-01-29 Rockwell Automation Technologies, Inc. Autogeneration of code via human-machine interfaces (HMI) and self-building HMI
US7861223B1 (en) * 2004-09-27 2010-12-28 Rockwell Automation Technologies, Inc. Systems and methods that employ an extensible architecture to define configuration functionality
JP4556787B2 (ja) * 2005-06-30 2010-10-06 株式会社ジェイテクト プログラマブルコントローラの編集装置
JP4442524B2 (ja) * 2005-07-12 2010-03-31 株式会社ジェイテクト 安全ｐｌｃ
US8156232B2 (en) * 2005-09-12 2012-04-10 Rockwell Automation Technologies, Inc. Network communications in an industrial automation environment
JP2007310718A (ja) * 2006-05-19 2007-11-29 Omron Corp セーフティ・コントローラ
WO2008024507A1 (en) * 2006-08-24 2008-02-28 Siemens Energy & Automation, Inc. Devices, systems, and methods for configuring a programmable logic controller
JP4849261B2 (ja) * 2007-05-14 2012-01-11 オムロン株式会社 安全アプリケーション作成支援装置
ATE529789T1 (de) 2007-07-05 2011-11-15 Sick Ag Verfahren zum programmieren einer sicherheitssteuerung
US7679299B2 (en) * 2007-08-02 2010-03-16 Rockwell Automation Technologies, Inc. Techniques for redundancy and fault tolerance in high demand machine safety applications

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102004003570A1 (de) * 2003-01-28 2005-03-10 Fisher Rosemount Systems Inc Integriertes Diagnosesystem in einer Prozessanlage mit einem Prozesssteuerungssystem und einem Sicherheitssystem

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
141.89.226.149: "Aspektorientierte Programmierung", 24 October 2008 (2008-10-24), XP002572905, Retrieved from the Internet <URL:http://de.wikipedia.org/w/index.php?title=Aspektorientierte_Programmierung&oldid=52181624> [retrieved on 20100312] *

Also Published As

Publication number Publication date
CN102292680A (zh) 2011-12-21
EP2353051A1 (de) 2011-08-10
DE102008060003A1 (de) 2010-05-27
US20120004744A1 (en) 2012-01-05
CN102292680B (zh) 2014-04-16
US8832667B2 (en) 2014-09-09
JP2012510099A (ja) 2012-04-26

Similar Documents

Publication Publication Date Title
WO2010060575A1 (de) Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung
EP2098926B1 (de) Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
EP2367083B1 (de) Vorrichtung zur Erstellung eines Programms für eine speicherprogrammierbare Steuerung, Programmiereinrichtung und Verfahren zur Programmierung einer speicherprogrammierbaren Steuerung
EP2399174B1 (de) Verfahren und vorrichtung zum erstellen eines anwenderprogrammes für eine sicherheitssteuerung
EP1131686B1 (de) Verfahren zur steuerung technischer prozesse
EP1362269B1 (de) Verfahren und vorrichtung zum programmieren einer sicherheitssteuerung
EP2353052B1 (de) Sicherheitssteuerung und verfahren zum steuern einer automatisierten anlage
EP2356527B1 (de) Sicherheitssteuerung und verfahren zum steuern einer automatisierten anlage mit einer vielzahl von anlagenhardwarekomponenten
EP2422271B1 (de) Verfahren und vorrichtung zum erstellen eines anwenderprogramms für eine sicherheitssteuerung
EP2422243B1 (de) Sicherheitssteuerung zum steuern einer automatisierten anlage und verfahren zum erstellen eines anwenderprogramms für eine sicherheitssteuerung
EP2098925A1 (de) Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
EP1184758A2 (de) Verfahren zum Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen, im Kontext der Flow Chart Programmierung
EP2012201A1 (de) Verfahren zum Programmieren einer Sicherheitssteuerung
EP2098924B1 (de) Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
EP2363770A1 (de) Sicherheitsvorrichtung mit einer konfigurierbaren Sicherheitssteuerung
EP2422248B1 (de) System und verfahren zum verteilen von projektdaten einer sicherheitssteuerung einer automatisierten anlage auf die steuerungskomponenten
EP2098928A1 (de) Verfahren und Vorrichtung zum Programmieren und/oder Konfigurieren einer Sicherheitssteuerung
EP2126643B1 (de) Verfahren zum austausch von strukturkomponenten für ein automatisierungssystem
DE69918829T2 (de) Steuerungssystem zur steuerung von prozessgeräten
EP2360540B1 (de) Datenträger mit Schaubildern zur Konfiguration eines Antriebssystems und Rechner mit graphischer Benutzerschnittstelle
EP2495622B1 (de) Verfahren zum Betrieb eines Automatisierungssystems, Computerprogramm zur Implementierung des Verfahrens und Computersystem mit einem solchen Computerprogramm
EP4148514A1 (de) Ntegriertes diagnosesystem für sps-basierte fernwirk-aussenstationen
DE102021123596A1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
EP3647889A1 (de) Fehlersichere sequenzkontrolle von prozessen
DE10233211A1 (de) Computersystem zur Konfiguration von Firmware für ein Automatisierungsgerät

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 200980155248.2

Country of ref document: CN

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09796615

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2011536786

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE

REEP Request for entry into the european phase

Ref document number: 2009796615

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 2009796615

Country of ref document: EP