WO2010028760A1 - Automatisierungssystem mit frameworkbasierter steuerung - Google Patents

Automatisierungssystem mit frameworkbasierter steuerung Download PDF

Info

Publication number
WO2010028760A1
WO2010028760A1 PCT/EP2009/006332 EP2009006332W WO2010028760A1 WO 2010028760 A1 WO2010028760 A1 WO 2010028760A1 EP 2009006332 W EP2009006332 W EP 2009006332W WO 2010028760 A1 WO2010028760 A1 WO 2010028760A1
Authority
WO
WIPO (PCT)
Prior art keywords
automation system
functional units
objects
function
specific
Prior art date
Application number
PCT/EP2009/006332
Other languages
English (en)
French (fr)
Inventor
Ralf Förster
Original Assignee
Khs Ag
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 Khs Ag filed Critical Khs Ag
Priority to US13/058,918 priority Critical patent/US8676354B2/en
Priority to EP09778258A priority patent/EP2324399A1/de
Publication of WO2010028760A1 publication Critical patent/WO2010028760A1/de

Links

Classifications

    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/042—Programme control other than numerical control, i.e. in sequence controllers or logic controllers using digital processors
    • G05B19/0426—Programming the control sequence
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B2219/00—Program-control systems
    • G05B2219/20—Pc systems
    • G05B2219/23—Pc programming
    • G05B2219/23255—Object oriented programming, OOP

Definitions

  • the present invention relates to an automation system with a number of objects to be controlled, wherein the automation system comprises a framework-based control for controlling basic functions of at least one object of the number of objects by means of object-specific functional units, wherein the control is object-independent and standardized interfaces for the communication technology integration of the object-specific functional units by means of preconfigured function calls.
  • Maintainers At the same time there is a desire of the customers for shorter delivery times with higher functionality and greater flexibility of the products.
  • a reduction of the resulting time and cost pressure requires a simplification and acceleration of the development process.
  • the current development and programming tools of automation technology do not provide sufficient support for consistently supporting and optimizing an entire development cycle of an automation system from initial planning to commissioning and acceptance by the customer.
  • the product lines usually comprise several (1 to about 10) different units or machines, which are connected to one another via transport modules, so that a product can pass through the individual machines in succession.
  • Each of these machines has a specific task to perform, such as cleaning, filling, or packaging a corresponding product.
  • one approach is to generate and provide a large proportion of reusable components for the automation of such product lines to one eventually minimize the development and modification costs of the corresponding product lines.
  • this can include, in particular, modularization of the respective controller.
  • a corresponding object-oriented structured control should contribute.
  • an automation system with a number of objects to be controlled comprising a framework-based control for controlling basic functions of at least one object of the number of objects by means of object-specific functional units.
  • the control is object-independent and also includes standardized interfaces for communication-technical integration of the object-specific functional units by means of preconfigured function calls.
  • Each functional unit is assigned to at least one of the objects and configured by means of object-specific control functions for controlling the respective basic function of the respectively assigned object.
  • each object from the number of objects is mapped or virtualized in the controller by means of the assigned object-specific functional units, and the objects of the number of objects are at least during an operating state of the automation system.
  • each of the functional units comprises a simulation module integrated in the respective functional unit with at least one simulation function and is optionally configured to execute the object-specific control function or to execute the at least one simulation function.
  • This system may, for example, be a production line with different objects, such as machines, platforms or other hardware components, each capable of performing at least one basic function.
  • Basic functions in this context are simple functional steps of an object, such as, for example, an opening and closing of valves or an activation or deactivation of an engine.
  • the control system for the automation system is based on a so-called "framework.”
  • This framework provides a frame structure that is object-independent, meaning that this object-independent frame structure can be executed universally and thus used for different objects, in each case the basic functions
  • object-specific functional units are used that are provided and integrated via preconfigured function calls, the object-specific functional units being stored externally preconfigured and designed specifically for the respective object the functional units the object-specific control functions, which enable a control of the respective basic function of the respective object and therefore individually adapted to the object and the respective basic function have to be.
  • the functional units are thus assigned to at least one specific object for which they have been configured. Of course, if several matching objects are used in the automation system, the corresponding functional unit can be used several times for each of these objects.
  • the described separation of the object-independent control of the object-specific functional units thus means that the respective object-specific functional units are not stored in the actual framework source code of the controller. This has only at predefined places corresponding function calls as interfaces, which are then assigned to the object-specific functional units or are assigned. Thus, the controller does not need to know the functional units themselves.
  • the objec- ject-specific functional units accordingly interchangeable.
  • the object-specific functional units specify, in particular, when, for example, which basic function should perform which task for which time period. They thus provide a control function specially designed for the respective object, which coordinate the basic functions controlled by the frame structure accordingly.
  • each object of the automation system to be controlled is imaged and virtualized in its control.
  • This means that all the hardware components or objects to be controlled are fully taken into account in the control, at least to the extent of the basic functions to be controlled, and can be addressed and controlled by them.
  • the entire control over the objects to be controlled is therefore in the control, so that at least during operation of the automation system, the objects are accessible and controllable only by the framework-based control means of the functional units. This is particularly important for the aspect of the simulation discussed below.
  • This aspect is also relevant for a change of objects of the automation system, since due to the structure, only the functional units of the changed objects must be individually adapted, but the framework-based control can remain unchanged. This aspect will be explained in more detail below.
  • each functional unit comprises a simulation module with at least one simulation function and is optionally configured to execute the object-specific control function or to execute the at least one simulation function.
  • each functional unit has a simulation property and a selection can be made as to whether the control function or the simulation function integrated in the functional unit is to be executed.
  • the simulation function can be configured in such a way that in a simulation operation the functional unit or the simulation module intercepts and processes commands for controlling the assigned object and provides signals which are provided in a normal operation by the object to be controlled.
  • the simulation module thus has the task of simulating the existence of the real object to the superordinate instances of the control, so that these higher-level instances supposedly communicate with the simulated object via the control, without noticing that this addressed object does not actually exist or does not actually exist addressed but only simulated.
  • This makes it possible to simulate any object of the automation system without a simulation. tion function in the framework-based control itself. Of course, several objects can be simulated simultaneously, so that it is also possible to simulate the entire automation system if necessary.
  • the automation system is defined in the functional unit, whether the execution of the object-specific control function or the execution of the at least one simulation function is selected.
  • the simulation can thus be carried out without knowledge of the control.
  • criteria for this selection for example, external events or corresponding parameterizations can be provided.
  • several simulation functions can be provided in the respective simulation module, which can be selected as needed for different simulation scenarios or combined with each other. Also, for example, several simulation functions can be combined in a library and stored in the respective simulation module. The aspect of the simulation is discussed below in more detail and in more general terms.
  • the integration of the object-specific functional units occurs at a start of the automation system, i. at the start time of the system.
  • the functional units are read into the controller based on configuration parameters or inserted into their source code and then started the controller.
  • the framework-based control comprises preconfigured function calls, which function as entry points or as interfaces for the communication-technical integration of the object-specific functional units.
  • the corresponding positions of the function calls must therefore be identified and designed or specified and preconfigured when the controller is created.
  • an implementation, for example, of a standard algorithm into the controller takes place, such as, for example, an implementation of the so-called OMAC model (Open Modular Architecture Control), which is identical for all machines.
  • OMAC model Open Modular Architecture Control
  • the pure framework-based control component at any time for any number of different machines of a production line separated from object-specific functional units for all objects, for example. As part of an "update" or an update. There is no danger of making changes in the external object-specific functional units or function-specific modules, since these are arranged outside the framework-based control.
  • object-oriented programming has already proven to be advantageous in the general programming languages of general software development, such as C ++ and Java, because with their help complex problems can be clearly structured and mastered with little error.
  • OOP object-oriented programming
  • object-oriented programming is not just the use of a different (hence object-oriented) programming language, but a consistent implementation of a particularly structured way of working. Therefore, an object-oriented approach can be achieved even with hitherto lack of support in the field of automation by applying a suitable object-oriented operation using currently available tools.
  • this "artificial" separation of flow logic and data or data structures i. of dynamics and statics initially avoided by both formally. virtually, be united into a single entity.
  • This unit forms a so-called "object.”
  • object usually causes a mere resorting and partial copying of a corresponding source text of the controller.
  • objects can be combined to form new objects.
  • the object-oriented implementation usually realized as one Object-oriented programming, therefore, allows objects to contain other objects and build relationships with one another, for example, a drive declared as an object can contain multiple engines that also represent objects, allowing assemblies, machine parts, or functional units to become more complex virtual devices For example, it is possible to graphically represent these units as a tree-like structure in the context of a structure plan, so that an object-oriented implementation of the control can be carried out in an equivalent manner, so that the resulting structure structure reflects the real machine structure.
  • Patterns basically allow programs and systems with similar structure. This means that familiarization with existing systems is facilitated since software design and structures can be virtually standardized according to the patterns if, when using different development environments and programming languages, the implementation is as uniform as possible and language-specific special solutions to ensure portability are avoided.
  • MMI connections i. standardized interfaces for operating a system via corresponding visualization systems, for purposes of parameterization or emergency stop treatment.
  • DAP pattern an exemplary so-called "DAP pattern” as an example of an architectural pattern for an automation system that is formed by a hierarchy of components with three layers, the corresponding controller thus being made up of a number of components
  • program parts are stored in so-called “libraries” for reuse in accordance with the prior art.
  • libraries typically include a large number of functions to handle a particular topic, such as graphics, math, communication, or motion aspects.
  • functions such as graphics, math, communication, or motion aspects.
  • Libraries generally non-deterministic and context-independent. This means that the libraries comprise a collection of different parts of the program, which are not necessarily explicitly tailored to the specific application. Furthermore, these libraries must be "learned" and the corresponding Program code be included. As a result, the program code of the controller is increased and thus increasingly complex. It also needs to change the control when making changes to the library. An independent processing to be performed is therefore not possible. So libraries are designed for any context, which of course makes them more variable and non-specific.
  • the automation area allows targeted forming of components, for example, in a product line and thus provides a specific context, which usually changes only slightly.
  • a product line from the automation area there is a special focus on the products that are created or are to be generated on the product line.
  • the components can no longer be viewed completely independently of each other, but always within the scope of the entire product line, since there is a certain interplay of direct or indirect nature between the components and must therefore be taken into account.
  • the components of the product line can be divided into three categories according to the underlying approach of the architectural pattern shown in FIG. 1:
  • Platform components provide so-called basic services within each application of the product line and abstract the underlying hardware. They represent the most common components and are comparable to so-called “device” drivers with standardized interfaces. The type of platform components used in each product line depends on the application area of the product line: typical examples of the platform's services Components are communicating with
  • Hardware components such as motors, pumps or valves.
  • a platform component (device driver), for example, encapsulates the hardware-specific properties of the motor for the application of the motor and, via an idealized interface, provides access to its basic functions, such as a start and stop function. Access to the platform components here has only the so-called plant components, which are arranged at a next higher hierarchical level. These plant components contain the basic flow logic for example, a product line as a composition of a number of platform components and possibly other equipment components.
  • controllers They are therefore also referred to as "controllers.”
  • a change of an underlying platform or an exchange of individual components therefore requires only changes to the platform components, since the plant components based on them communicate via standardized interfaces with the respective platform components
  • System components are therefore generic and have no specific reference to the products manufactured on the product line. The system components themselves are controlled by higher-level domain components for controlling the entire system behavior or product line.
  • the domain components thus contain a corresponding application logic for more complex applications up to an actual machine logic. You only use or control the aforementioned system components or other domain components to control the entire specific system behavior. They also represent control components that, like the plant components, control subordinate components. Each of the three components mentioned can therefore be equipped with an object-oriented programmed framework-based control, whereby, for example, the objects each consist of the subordinate components and therefore differ from the objects of other components. The control itself does not have to be changed. Only the object-specific functional units are adapted to the respective objects.
  • the function calls for controlling the subordinate components should always refer to the correspondingly subordinate hierarchy level, but should not skip over several hierarchy levels, so that a clear grouping of the child components to objects.
  • communication relationships take place only in the vertical direction.
  • a tree-like structuring of the model becomes visible. This structuring is oriented close to the corresponding hardware structure, so that between
  • Hardware and software is an analogy that allows a simple and easy understanding of the respective software model. This structure is made possible in particular by an object-oriented procedure for programming as described above. Analogous to the relationship of the individual hardware components, functions of objects are thus controlled by higher-level objects. The above-described aspect of the simulation is discussed below in addition to general form. Accordingly, objects can be simulated by means of the simulation module and signals or commands of the controller for controlling basic functions of at least one object of the automation system can be received by the respective simulation module.
  • the hierarchy level of the hardware controlled by the platform components can be replaced by the simulation module, for example in the form of a correspondingly equipped arithmetic unit or else in the form of a corresponding source code or program (part), so that the respective platform components can communicate with the simulation module. All parent components above the platform components will not be affected by this replacement and will therefore resume normal operation.
  • a higher hierarchical layer can also be replaced and simulated accordingly.
  • DEV_ The classes that represent a physical element begin with the prefix "DEV_" in the following description: They form both an abstraction layer of the hardware (device driver) and the simulation elements, which is illustrated in FIG can such a "DEV” element in several
  • MotoM .SetSpeed Initiation of a MotoM .SetSpeed
  • MotoM .Start End; End;
  • the value "TRUE”, which corresponds to a permanently active light barrier, is permanently set in a simulation.Of course, this simulation part can be developed and perfected in real time as desired and in the course of further development of machines.
  • a splitting off of the simulation component (referred to below as part 2) as a simulation function of the simulation module from the control function (part 1) of the functional unit has the advantage that the simulation component, if necessary, such as when splitting the machine to the customer, split off can be.
  • a separation into two parts for example, can be as follows:
  • CALL Simulation () "in Part 1 could therefore be used, for example, by a so-called compiler switch as a switch of the form"#ifdef WithSimulation ". sabled or switched off. Setting this switch eliminates the simulation from the software.
  • simulation functions can be combined in one library.
  • different libraries can also include different simulation scenarios or simulation scenarios can be controlled by external events or parameterizations. This aspect is particularly advantageous for a continuous testing in the further development of the entire control or the software, since any combinations, subsystem formations and processes, in particular of fault conditions, are possible, which can be repeated as often and in any order.
  • continuous development of the simulation or test "cases" or scenarios enables full coverage of all relevant test functions in the long term, allowing tests to be reproduced at any time and automatically executed and evaluated over long periods of time.
  • the interfaces are further provided for the communication technology integration of function-specific modules for the respective object.
  • additional modules can thus be executed by the framework-based control in the same way.
  • the modules can, for example, provide new functionalities for the controller, which, for example, can consider and integrate individual wishes of customers. For example, a customer can have their own programs executed without having to intervene in the framework source code of the controller, for example, to collect meter readings. to trigger notifications of error conditions or to program customer-specific controls, etc. Thus, no error can be built into the controller in this way, which possibly leads, for example, to undesired behavior of the corresponding object.
  • the at least one object may comprise at least one automated machine.
  • a so-called "object” of the controller can combine one or more machines into a virtual unit, so that the complete production line can be grouped together as a single object, which is formed from objects or individual machines, which in turn are aggregated from other objects which can be composed of platform components and their parts, for example.
  • the automation system comprises at least one product line with a number of objects that are designed as automated machines.
  • the framework-based controller may have a structure that reflects a structure of the automated machines of the automation system.
  • each machine or parts of the respective machine can be identified as a single object or as individual objects in the controller, so that a structure of the automation system coincides with the structure of the controller.
  • access to the controller can be protected. This can be done, for example, by means of a password or other suitable access-limiting measures, whereby the framework-based control is protected against unwanted manipulation.
  • machine-specific elements such as the object-specific functional units or the function-specific modules, remain unaffected and can be changed or adapted.
  • a source code or source code of the framework-based control is automatically generated.
  • a method for testing an automation system with a framework-based control as described above wherein the automation system has a framework-based control for controlling tion of basic functions of at least one object of the number of objects by means of object-specific functional units.
  • the control is object-independent and includes standardized interfaces for communication-technical integration of the object-specific functional units by means of preconfigured function calls.
  • the method also includes a first selecting step for selectively performing an object-specific control function or executing the at least one simulation function by the functional unit.
  • the first selection step is performed by the functional unit.
  • Automation system for controlling basic functions of at least one object of the automation system by means of a framework-based control, wherein the control is executed object-independent, provided with the following steps:
  • the present description also covers a computer program with program code that performs all the steps of the method for the framework-based control of an automation system when the computer program is executed on a computer or a corresponding computing unit.
  • FIG. 1 shows a possible architectural pattern with three hierarchical layers in a schematic representation
  • FIG. 2 shows a schematic structure of an embodiment of a framework-based control
  • FIG. 3 shows a section of an embodiment of a framework-based one
  • Figure 4 shows a further structure of the framework-based control in a schematic representation.
  • FIG. 1 shows an architectural pattern or pattern using the example of a so-called "DAP pattern", which may be based on a framework-based control and which consists of a component hierarchy comprising three component layers 12, 13, 14 and a subordinate hardware layer 11.
  • the hardware layer 11 consists of a motor 11a and a light barrier 11b, each of which is formed by a so-called platform component 12a or 12 b, which are arranged in the layer of the platform components 12. These in turn are controlled by a plant component 13a, which is arranged in the plant layer 13. Higher up is the so-called domain component 14a, which controls the system component 13a and which in turn is arranged in the domain layer 14.
  • the respective component of a particular layer of the illustrated hierarchy is controlled only by the component directly above it.
  • An overall control over several hierarchical layers is not provided, since this would disturb the intended modular structure of the component hierarchy.
  • This restriction explicitly refers only to an overall controller that would bypass intermediate components.
  • a platform component can also be controlled directly by a domain component without hindering the intended modular structure.
  • FIG. 2 shows an example of a framework-based controller 21 for an automation system 20.
  • This framework-based controller 21 is based on a so-called "state machine” 22, which is formed by a standard algorithm that is designed identically for various machines can and controls basic functions 23 of an object or a machine, for example, the defined method to a specific position ("set position"), the activation or monitoring of a light barrier ("light curtain xy") or the control of a drive ( "Drive on", “Drive off”) and can be extended by any other functions ("Fkt n”)
  • This status model can, for example, comply with the so-called "OMAC” (or Weihenstephan) standard.
  • the OMAC standard Open Modular Architecture Controls
  • the framework-based control which is identical for all machines of a product line or plant and defines an object-independent plant layer. From this implementation are machine-specific functions or object-specific
  • FIG. 3 shows a section of a source code of an embodiment of a framework-based control ("SW framework code”) for an automation system which starts a state change from a state “idle” to a state “starting” ").
  • Function calls (“CaII before_Change ()” and “CaII after_Change ()" are inserted at defined points of the framework-based control, which allow the control to be separated from various function, object, or platform-specific functions (“Function before_Change () "and” Function af ter_Change () "), which are stored in the externally arranged object-specific functional units or function-specific modules (" machine-specific code "), thus introducing additional source code or source code for these functions
  • the function calls must be declared.This declaration takes place outside of the framework source code.Thus, if this procedure is adhered to consistently, the functional, object or platform-specific basically see functions in external packages or files be stored.
  • An implementation of the framework-based control can thus be carried out independently of a creation of the object-specific functional units or the function-specific modules. After object-independent completion of the framework-based control, integration of the machine-specific functionalities by means of the object-specific functional units can then take place via function calls to be provided in each case at previously identified points.
  • the framework-based control itself remains untouched.
  • interfaces to external systems such as MMI, ERP, or error handling, as well as hardware interfaces.
  • a customer can have their own programs executed without having to intervene in the framework source code of the controller in order to For example, to query counter readings, trigger notifications in error conditions or to program customer-specific controls, etc.
  • each layer of the hierarchy structure has its own function calls. These are independent of function calls of other layers and are shown schematically in FIG. In principle, not all function calls must actually be able to communicate with an object-specific functional unit; it is also possible to execute these as so-called "empty" function calls which have no function or are linked to an object-specific functional unit or a function-specific module at a later time can.
  • Figure 4 shows a further structure of a controller for an automation system in a schematic representation.
  • a framework-based control (43) as an object-independent part forms an object-independent plant layer (41).
  • physical elements or objects (not shown) of the underlying automation system namely a light barrier, a motor and a temperature sensor are each represented by an equivalent in a so-called platform level
  • Each functional unit (44, 45, 46, 47, 48) each has a number of
  • the functional units (44, 45, 46, 47, 48) may each have a simulation module (45b), which is shown only in the functional unit (45) for a better overview, but in principle in all functional units (44, 45, 46, 47, 48) can be provided.
  • the platform level (42) is formed by means of the functional units
  • the functional units (44, 45, 46, 47, 48) can be in direct contact with the framework-based control by means of standardized interfaces
  • controller (43) wants to communicate with a hardware element, it does not use an input or output of the hardware, for example, by setting or resetting a bit, but it becomes the functional unit provided for this hardware (44, 45, 46, 47, 48) by calling the corresponding control function (44a, 45a, 46a) of the functional unit (44, 45, 46, 47, 48).
  • An underlying source code can, for example, be constructed in such a way:
  • Source text of the framework-based control (43) must be a direct reference to the actually installed elements or objects. Any physical connection between hardware and software is rather in the platform layer (42), i. in the functional units (44, 45, 46, 47, 48) hidden.

Landscapes

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

Abstract

Es wird ein Automatisierungssystem mit einer Anzahl von zu steuernden Objekten bereitgestellt, wobei das Automatisierungssystem eine frameworkbasierte Steuerung (21 ) zur Steuerung von Grundfunktionen (23) mindestens eines Objekts der Anzahl von Objekten mittels objektspezifischer Funktionseinheiten (25) umfasst, wobei die Steuerung (21) objektunabhängig ausgeführt ist und standardisierte Schnittstellen (26) zur kommunikations-technischen Einbindung der objektspezifischen Funktionseinheiten (25) mittels vorkonfigurierter Funktionsaufrufe umfasst, wobei jede Funktionseinheit (25) mindestens einem der Objekte zugeordnet und mittels objektspezifischer Steuerfunktionen zum Ansteuern der jeweiligen Grundfunktion (23) des jeweils zugeordneten Objekts konfiguriert ist, wobei jedes Objekt aus der Anzahl von Objekten mittels der zugeordneten objektspezifischen Funktionseinheiten (25) in der Steuerung (21) virtualisiert ist und die Objekte der Anzahl von Objekten mindestens während eines Betriebszustandes des Automatisierungssystems ausschließlich von der frameworkbasierten Steuerung (21) mittels der objektspezifischen Funktionseinheiten (25) ansprechbar und steuerbar sind, und jede der Funktionseinheiten (25) ein in der jeweiligen Funktionseinheit (25) integriertes Simulationsmodul mit mindestens einer Simulationsfunktion umfasst und wahlweise zum Ausführen der objektspezifischen Steuerfunktion oder zum Ausführen der mindestens einen Simulationsfunktion konfiguriert ist. Außerdem werden ein Verfahren zum Test eines Automatisierungssystems mit einer frameworkbasierten Steuerung sowie ein Verfahren zur frameworkbasierten Steuerung eines entsprechenden Automatisierungssystems vorgeschlagen.

Description

Automatisierungssystem mit frameworkbasierter Steuerung
[0001 ] Die vorliegende Erfindung betrifft ein Automatisierungssystem mit einer Anzahl von zu steuernden Objekten, wobei das Automatisierungssystem eine frameworkbasierte Steuerung zur Steuerung von Grundfunktionen mindestens eines Objekts der An- zahl von Objekten mittels objektspezifischer Funktionseinheiten umfasst, wobei die Steuerung objektunabhängig ausgeführt ist und standardisierte Schnittstellen zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten mittels vorkonfigurierter Funktionsaufrufe umfasst.
[0002 ] Aufgrund einer ständig steigenden Komplexität und zunehmend divergie- render Modellvarianten von automatisierten Anlagen bzw. Automatisierungssystemen nehmen Kosten für deren Wartung, Weiterentwicklung und Verwaltung stetig zu. Ebenso steigen die Kosten und der Zeitbedarf für eine Erstellung immer größerer und komplexerer
Steuerungsprogramme sowie die hierzu notwendige Ausbildung von Programmierern und
Instandhaltern. Gleichzeitig besteht ein Wunsch der Kunden nach kürzeren Lieferzeiten bei gleichzeitig höherer Funktionalität und größerer Flexibilität der Produkte.
[0003 ] Eine Verringerung des hieraus entstehenden Zeit- und Kostendrucks erfordert eine Vereinfachung und Beschleunigung des Entwicklungsprozesses. Hierzu bieten die gängigen Entwicklungs- und Programmierwerkzeuge der Automatisierungstechnik jedoch keine ausreichende Unterstützung, um einen gesamten Entwicklungszyklus eines Au- tomatisierungssystems von der ersten Planung bis zur Inbetriebnahme und Abnahme durch den Kunden durchgängig zu unterstützen und zu optimieren.
[0004 ] Im Bereich der Automatisierungstechnik besteht daher ein Bestreben, Analyse-, Design-, Dokumentations- und Codierungswerkzeuge bis hin zu Codegeneratoren und automatischen Testsystemen aus dem eigentlich fernen Bereich der Programmier- hochsprachen der allgemeinen Softwareentwicklung für den Automatisierungsbereich zu nutzen, die im Bereich der allgemeinen Softwareentwicklung bereits erfolgreich zu Optimierungen beigetragen haben. Hierbei haben sich insbesondere objektorientierte Programmiersprachen und Werkzeuge als vorteilhaft erwiesen. Diese sind jedoch im Bereich der Automatisierungstechnik praktisch unbekannt, da es hier keine vergleichbaren Pendants gibt und die Werkzeuge der allgemeinen Softwareentwicklung in der Regel nicht identisch übernommen werden können. [0005] Dies liegt darin begründet, dass im Bereich der Automatisierungstechnik bisher hauptsächlich sogenannte speicherprogrammierbare Steuerungen (SPS) eingesetzt werden, deren Programmiersprachen keine den Programmierhochsprachen der allgemeinen Softwareentwicklung vergleichbare objektorientierte Sprachkonzepte bzw. entspre- chende Werkzeuge umfassen. Teilweise gibt es bereits Bestrebungen, objektorientierte Sprachmerkmale (Sprachfeatures) und Werkzeuge auch in den Programmiersprachen der SPS, wie z.B. IEC 61131 ST, aufzunehmen. Erste Bemühungen diese Technologie im Automatisierungsbereich einzusetzen, werden bspw. mit dem Software-Entwicklungssystem „CodeSys 3.0" des Unternehmen 3S Smart Software Solutions GmbH unternommen, das sich momentan jedoch noch in der Entwicklungs- und Erprobungsphase befindet.
[0006] In der Automatisierungstechnik werden in der Regel gesamte Produktlinien mit entsprechenden Steuerungen ausgestattet. Hierbei umfassen die Produktlinien meist mehrere (1 bis ca. 10) verschiedene Aggregate bzw. Maschinen, die miteinander über Transportmodule verbunden sind, so dass ein Produkt die einzelnen Maschinen nacheinander durchlaufen kann. Jede einzelne dieser Maschinen hat eine spezifische Aufgabe zu erfüllen, wie bspw. Reinigen, Füllen, bzw. Verpacken eines entsprechenden Produkts. Trotz dieser unterschiedlichen Aufgaben der einzelnen Maschinen und damit auch unterschiedlichen Anforderungen an eine jeweilige Steuerung der Maschinen und somit unterschiedlichen Steuerungen innerhalb einer entsprechenden Produktlinie besteht ein Ansatz darin, für die Automatisierung derartiger Produktlinien einen großen Anteil von wiederverwendbaren Komponenten zu generieren und bereitzustellen, um einen eventuell erforderlichen Entwicklungs- und Änderungsaufwand der entsprechenden Produktlinien zu minimieren. Dies kann neben einer Verwendung gleicher mechanischer und elektronischer Bauteile in den Maschinen und einer Modularisierung der Maschinen zur Verwendung gleichartiger Module in verschiedenen Maschinen insbesondere auch eine Modularisierung der jeweiligen Steuerung umfassen. Hierzu soll eine entsprechend objektorientiert strukturierte Steuerung beitragen.
[ 0007] Es ist somit ein Ziel, Vorteile der objektorientierten Programmiersprachen in der Automatisierungstechnik nutzbar zu machen und verfügbare objektorientierte Werk- zeuge (sogenannte OO-Tools) und entsprechende Mechanismen für die Automatisierungstechnik zu übernehmen. Es besteht daher die Absicht, Steuerungen für die Automatisierungstechnik objektorientiert zu konzipieren, obwohl die verwendeten Programmiersprachen diesen Ansatz nicht explizit unterstützen. [0008] Des weiteren weist die Programmierung von Maschinen im Bereich der Automatisierungssysteme den Nachteil auf, dass selbst einfache Programmfunktionen oft erst dann getestet werden können, wenn die eigentliche, zu programmierende Maschine (weitestgehend) fertig gestellt ist. Um dies zu umgehen, werden üblicherweise Testumge- bungen erstellt, in denen Teile der Programme isoliert getestet werden können. Diese Tests beziehen sich jedoch größtenteils auf einzelne Baugruppen, so dass das Zusammenwirken mehrerer Baugruppen bis hin zu komplexen Funktionen oder gar einer vollständigen Maschine bisher kaum möglich ist. Zwar gibt es auch spezialisierte Programme, doch setzten diese SpezialWissen des Benutzers voraus, benötigen eine hinreichend ge- nau Beschreibung der Maschine und ihres Verhaltens und müssen darüber hinaus über geeignete Kommunikationsmittel (üblicherweise entweder direkte Simulationen der Ein- und Ausgaben (lO's) oder proprietäre Protokolle) mit der Steuerung verbunden werden. Dies ist sehr aufwändig und wird bisher lediglich in Einzelfällen für einzelne Spezialma- schinen oder zu Demonstrationszwecken durchgeführt. Jedoch ist diese Vorgehensweise für eine effiziente Inbetriebnahme oder Software-Änderungen, insbesondere für den Einzelmaschinenbau im Bereich der Automatisierungssysteme nicht praktikabel.
[0009] Es ist somit außerdem ein Ziel, eine einfache Simulations- und Testfunktion für Einzelmaschinen und Automatisierungssysteme bzw. deren Komponenten bereitzustellen.
Zusammenfassung der Erfindung
[ 0010 ] Hierzu wird erfindungsgemäß ein Automatisierungssystem mit einer Anzahl von zu steuernden Objekten bereitgestellt, wobei das Automatisierungssystem eine frameworkbasierte Steuerung zur Steuerung von Grundfunktionen mindestens eines Ob- jekts der Anzahl von Objekten mittels objektspezifischer Funktionseinheiten umfasst. Die Steuerung ist objektunabhängig ausgeführt und umfasst außerdem standardisierte Schnittstellen zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten mittels vorkonfigurierter Funktionsaufrufe. Jede Funktionseinheit ist mindestens einem der Objekte zugeordnet und mittels objektspezifischer Steuerfunktionen zum Ansteu- ern der jeweiligen Grundfunktion des jeweils zugeordneten Objekts konfiguriert. Des weiteren ist jedes Objekt aus der Anzahl von Objekten mittels der zugeordneten objektspezifischen Funktionseinheiten in der Steuerung abgebildet bzw. virtualisiert und die Objekte der Anzahl von Objekten sind mindestens während eines Betriebszustandes des Automatisie- rungssystems ausschließlich von der frameworkbasierten Steuerung mittels der objektspezifischen Funktionseinheiten ansprechbar und steuerbar. Außerdem umfasst jede der Funktionseinheiten ein in der jeweiligen Funktionseinheit integriertes Simulationsmodul mit mindestens einer Simulationsfunktion und ist wahlweise zum Ausführen der objektspezifi- sehen Steuerfunktion oder zum Ausführen der mindestens einen Simulationsfunktion konfiguriert.
[0011 ] Es wird somit ein Automatisierungssystem mit mit einer Anzahl von zu steuernden Objekten beschrieben. Dieses System kann bspw. eine Produktionslinie mit unterschiedlichen Objekten sein, wie beispielsweise Maschinen, Plattformen oder anderen Hardware-Komponenten, die jeweils mindestens eine Grundfunktion ausführen können. Unter Grundfunktionen sind in diesem Zusammenhang einfache Funktionsschritte eines Objekts, wie bspw. ein Öffnen und Schließen von Ventilen oder ein An- oder Abschalten eines Motors, zu verstehen. Des weiteren basiert die Steuerung für das Automatisierungssystem auf einem sog. „Framework". Dieses Framework stellt eine Rahmenstruktur bereit, die objektunabhängig ausgeführt ist. Dies bedeutet, dass diese objektunabhängige Rahmenstruktur universell ausgeführt und somit für unterschiedliche Objekte eingesetzt werden kann, um jeweils die Grundfunktionen der entsprechenden Objekte (mittelbar) anzusteuern. Zur direkten Ansteuerung der Objekte bzw. deren Grundfunktionen kommen objektspezifische Funktionseinheiten zum Einsatz, die über vorkonfigurierte Funktionsaufrufe bereitgestellt und eingebunden werden, wobei die objektspezifischen Funktionseinheiten extern vorkonfiguriert hinterlegt und speziell für das jeweilige Objekt konzipiert sind. Hierzu umfassen die Funktionseinheiten die objektspezifischen Steuerfunktionen, die ein Ansteuern der jeweiligen Grundfunktion des jeweiligen Objekts ermöglichen und daher individuell an das Objekt und die jeweilige Grundfunktion angepasst sein müssen. Die Funktionsein- heiten sind somit mindestens einem speziellen Objekt zugeordnet, für das sie konfiguriert wurden. Werden mehrere übereinstimmende Objekte in dem Automatisierungssystem verwendet, so kann die entsprechende Funktionseinheit natürlich mehrmals für jedes dieser Objekte eingesetzt werden.
[0012 ] Die beschriebene Trennung der objektunabhängigen Steuerung von den objektspezifischen Funktionseinheiten bedeutet also, dass die jeweiligen objektspezifischen Funktionseinheiten nicht im eigentlichen Framework-Quelltext der Steuerung hinterlegt sind. Diese weist lediglich an vordefinierten Stellen entsprechende Funktionsaufrufe als Schnittstellen auf, denen dann die objektspezifischen Funktionseinheiten zuzuordnen sind bzw. zugeordnet werden. Somit muss die Steuerung die Funktionseinheiten selbst nicht kennen. Je nach anzusteuerndem Objekt bzw. anzusteuernden Objekten sind die ob- jektspezifischen Funktionseinheiten entsprechend austauschbar. Die objektspezifischen Funktionseinheiten geben insbesondere vor, wann bspw. welche Grundfunktion welche Aufgabe für welche Zeitdauer ausführen soll. Sie stellen damit eine speziell für das jeweilige Objekt konzipierte Steuerungsfunktion bereit, die die durch die Rahmenstruktur gesteu- erten Grundfunktionen entsprechend koordinieren.
[0013 ] Mittels der objektspezifischen Funktionseinheiten und der definierten Schnittstellen wird jedes anzusteuernde Objekt des Automatisierungssystems in deren Steuerung abgebildet und virtualisiert. Dies bedeutet, dass alle zu steuernden Hardware- Komponenten bzw. Objekte zumindest im Umfang der zu steuernden Grundfunktionen vollständig in der Steuerung berücksichtigt sind und über diese ansprechbar und steuerbar sind. Es gibt also keine zu steuernde Hardware-Komponente bzw. kein zu steuerndes Objekt auf die bzw. auf das von außerhalb der Steuerung zugegriffen werden soll. Die gesamte Kontrolle über die zu steuernden Objekte liegt also bei der Steuerung, so dass zumindest während eines Betriebs des Automatisierungssystems die Objekte ausschließlich von der frameworkbasierten Steuerung mittels der Funktionseinheiten ansprechbar und steuerbar sind. Dies ist insbesondere für den nachfolgend diskutierten Aspekt der Simulation von Bedeutung. Auch für einen Wechsel von Objekten des Automatisierungssystems ist dieser Aspekt relevant, da aufgrund des Aufbaus lediglich die Funktionseinheiten der geänderten Objekte individuell angepasst werden müssen, jedoch die frameworkbasierte Steuerung unverändert bleiben kann. Dieser Aspekt wird nachfolgend noch detaillierter dargelegt.
[0014 ] Darüber hinaus umfasst jede Funktionseinheit ein Simulationsmodul mit mindestens einer Simulationsfunktion und ist wahlweise zum Ausführen der objektspezifischen Steuerfunktion oder zum Ausführen der mindestens einen Simulationsfunktion konfiguriert. Dies bedeutet, dass jede Funktionseinheit eine Simulationseigenschaft aufweist und eine Auswahl getroffen werden kann, ob die in der Funktionseinheit integrierte Steuerfunktion oder die Simulationsfunktion ausgeführt werden soll. Die Simulationsfunktion kann derart gestaltet sein, dass in einem Simulationsbetrieb die Funktionseinheit bzw. das Simulationsmodul Befehle zur Ansteuerung des zugeordneten Objekts abfängt, verarbeitet und Signale bereitstellt, die in einem Normalbetrieb von dem zu steuernden Objekt bereitge- stellt werden. Dem Simulationsmodul kommt also die Aufgabe zu, den übergeordneten Instanzen der Steuerung das Vorhandensein des realen Objekts zu simulieren, so dass diese übergeordneten Instanzen vermeintlich über die Steuerung mit dem simulierten Objekt kommunizieren, ohne zu bemerken, dass dieses angesprochene Objekt nicht real existiert oder nicht tatsächlich angesprochen sondern lediglich simuliert wird. Dadurch ist es mög- lieh, jedes beliebige Objekt des Automatisierungssystems zu simulieren, ohne eine Simula- tionsfunktion in der frameworkbasierten Steuerung selbst vorzusehen. Selbstverständlich können auch mehrere Objekte gleichzeitig simuliert werden, so dass es auch möglich ist, bei Bedarf die gesamte Automatisierungsanlage zu simulieren.
[0015 ] Entsprechend einer Ausführungsform des Automatisierungssystems wird in der Funktionseinheit definiert, ob das Ausführen der objektspezifischen Steuerfunktion oder das Ausführen der mindestens einen Simulationsfunktion ausgewählt wird. Dies bedeutet, dass nicht die frameworkbasierte Steuerung vorgibt, ob eine Simulation des zugeordneten Objekts ablaufen oder das Objekt tatsächlich angesprochen und gesteuert werden soll, sondern die entsprechende Funktionseinheit dies selbst entscheidet. Die Simula- tion kann somit ohne Kenntnis der Steuerung durchgeführt werden. Als Kriterien für diese Auswahl können bspw. externe Ereignisse oder entsprechender Parametrierungen vorgesehen sein. Alternativ ist es aber ebenso möglich, eine entrsprechende Auswahl über die frameworkbasierte Steuerung vorzugeben. Des weiteren können selbstverständlich mehrere Simulationsfunktionen in dem jeweiligen Simulationsmodul vorgesehen sein, die je nach Bedarf für unterschiedliche Simulationsszenarien ausgewählt oder auch miteinander kombiniert werden können. Auch können bspw. mehrere Simulationsfunktionen in einer Bibliothek zusammengefasst und in dem jeweiligen Simulationsmodul hinterlegt werden. Der Aspekt der Simulation wird nachfolgend noch im Detail und in allgemeinerer Form diskutiert.
[0016] Gemäß einer Ausführungsform erfolgt die Einbindung der objektspezifischen Funktionseinheiten bei einem Start des Automatisierungssystems, d.h. zur Startzeit des Systems. Hierbei werden die Funktionseinheiten anhand von Konfigurationsparametern in die Steuerung eingelesen oder in deren Quelltext eingefügt und anschließend die Steuerung gestartet.
[0017] Wie voranstehend dargestellt, umfasst die frameworkbasierte Steuerung vorkonfigurierte Funktionsaufrufe, die als Eintrittspunkte bzw. als Schnittstellen zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten fungieren. Die entsprechenden Positionen der Funktionsaufrufe müssen daher bei der Erstellung der Steuerung identifiziert und ausgebildet bzw. spezifiziert und vorkonfiguriert werden. An- schließend erfolgt eine Implementierung bspw. eines Standardalgorithmus in die Steuerung, wie bspw. eine Implementierung des sogenannten OMAC-Models (Open Modular Architecture Control), der für alle Maschinen identisch ist. Somit kann eine einfache Übertragbarkeit auf andersartige Objekte realisiert werden. [0018] Da die frameworkbasierte Steuerung unabhängig von dem tatsächlichen Objekt ist, kann bei einer Änderung, Erweiterung oder Fehlerbeseitigung der reine frameworkbasierte Steuerungsanteil jederzeit für eine beliebige Anzahl unterschiedlicher Maschinen einer Produktionslinie getrennt von objektspezifischen Funktionseinheiten für alle Objekte bspw. im Rahmen eines "Updates" bzw. einer Aktualisierung modifiziert werden. Es besteht hierbei keine Gefahr Änderungen in den externen objektspezifischen Funktionseinheiten oder funktionsspezifischen Modulen vorzunehmen, da diese außerhalb der frameworkbasierten Steuerung angeordnet sind.
[0019 ] Eine Implementierung der frameworkbasierten Steuerung folgt hierzu dem voranstehend beschriebenen Ansatz der objektorientierten Programmierung, nach dem Komponenten des Automatisierungssystems zu (virtuellen) Objekten zusammenge- fasst werden können. Wie ebenfalls voranstehend beschrieben, hat sich die objektorientierte Programmierung (OOP) bereits in den Programmierhochsprachen der allgemeinen Softwareentwicklung, wie C++ und Java, als vorteilhaft erwiesen, da mit ihrer Hilfe komple- xe Problemstellungen übersichtlich strukturiert und fehlerarm beherrscht werden können. Diese Vorteile ergeben sich unter anderem aus der daraus begründeten Art und Weise des Herangehens an Aufgabenstellungen, deren Strukturierung und einem entsprechenden anschließenden Entwicklungsprozess. Somit ist die objektorientierte Programmierung nicht einfach nur die Verwendung einer anderen - mithin objektorientierten - Programmierspra- che, sondern eine konsequente Umsetzung einer besonders strukturierten Arbeitsweise. Daher kann eine objektorientierte Vorgehensweise auch bei bislang mangelnder Unterstützung im Automatisierungsbereich durch Anwendung einer geeigneten objektorientierten Arbeitsweise mit Hilfe derzeit vorhandener Werkzeuge erzielt werden. •
[0020] In bisherigen konventionellen, nicht objektorientierten Programmierspra- chen des Automatisierungsbereichs wird üblicherweise zwischen einem eigentlichen Programm (Anweisungsteil) und (statischen) Daten unterschieden. Eine Ablauflogik wird durch eine kontrollierte Folge von Aufrufen zuvor passend definierter Funktionen gesteuert. Eine Entscheidung, mit welchem Objekt (bspw. mit welchem Motor) zu welchem Zeitpunkt welche Grundfunktion ausgeführt werden soll, wird durch eine Übergabe einer entsprechen- den Datenstruktur an eine jeweilig dafür eigens definierte Funktion getroffen.
[0021] Dies führt in der Regel dazu, dass eine entsprechende Ablauflogik und zu verwendende Datenstrukturen getrennt voneinander behandelt, modelliert und dokumentiert werden. Ein Maschinenmodell findet sich daher teilweise in einer Ablauflogik, die des- sen dynamischen Teil darstellt, und teilweise in den Datenstrukturen, die dessen statischen Teil darstellen, wieder.
[0022 ] Bei einer objektorientierten Implementierung der Steuerung des Automatisierungssystems wird diese "künstliche" Trennung von Ablauflogik und Daten bzw. Daten- Strukturen, d.h. von Dynamik und Statik zunächst dadurch vermieden, dass beide formal d.h. virtuell, zu einer Einheit zusammengeschlossen werden. Diese Einheit bildet ein sogenanntes „Objekt". Dies bewirkt jedoch in der Regel eine reine Umsortierung und abschnittsweise Vervielfältigung eines entsprechenden Quelltexts der Steuerung. Um dies zu verhindern, können Objekte zu neuen Objekten zusammengeschlossen werden. Die ob- jektorientierte Implementierung, meist realisiert als eine objektorientierte Programmierung, erlaubt es somit, dass Objekte andere Objekte enthalten und Beziehungen zueinander aufbauen können. Beispielsweise kann ein als Objekt deklarierter Antrieb mehrere Motoren, die ebenfalls jeweilige Objekte darstellen, umfassen. Auf diese Weise lassen sich Baugruppen, Maschinenteile oder Funktionseinheiten zu komplexeren virtuellen Einheiten zusammenfassen. Beispielsweise ist es möglich, diese Einheiten im Rahmen eines Strukturplans als baumartige Struktur graphisch darzustellen. Eine objektorientierte Implementierung der Steuerung kann dementsprechend äquivalent ausgeführt werden, so dass die so entstehende Steuerungsstruktur die reale Maschinenstruktur widerspiegelt.
[0023 ] Dies bietet den Vorteil einer einfacheren Dokumentation, da zu der phy- sisch vorliegenden Hardware der Maschinenstruktur eine entsprechende Steuerungsstruktur und Implementierung besteht, so dass eine Generierung einer objektorientierten Steuerung vereinfacht wird. Eine Anwendung abstrakter Klassen, Schnittstellen (Interfaces), Polymorphie und dynamische Bindungen, wie sie aus der allgemeinen objektorientierten Programmierung bekannt sind, sind bisher für Programmierungen im Automatisierungsbereich nicht möglich. Jedoch kann in der Automatisierungstechnik auf derartige Möglichkeiten, wie z.B. eine dynamische Speicherverwaltung, virtuelle Methoden oder abstrakte Klassen, verzichtet bzw. können diese teilweise durch eine automatische Quelltextgenerierung ersetzt werden, da sich eine Steuerung in der Regel auf konkrete und bekannte Objekte mit konkreten Adressen und Funktionen bezieht, so dass eine dynamische Anpassung im Allge- meinen nicht notwendig ist.
[0024 ] In der allgemeinen Softwareentwicklung kommen bei einer objektorientierten Programmierung seit einiger Zeit sogenannte Patterns bzw. Muster zum Einsatz, die häufig auftretende Entwurfsprobleme und dazu universell verwendbare generische Lösungsschemata beschreiben. Während sogenannte „Architektur-Pattems" sich auf die Ar- chitektur von Softwaresystemen beziehen, abstrahieren sogenannte „Design-Patterns" (Entwurfsmuster) weniger stark und beziehen sich eher auf eine Softwarecodierung.
[0025] Eine entsprechende Verwendung und ein entsprechender Umgang mit diesen Patterns im Automatisierungsbereich ermöglicht im Vergleich zu bisherigen Steue- rungen eine deutliche Verbesserung einer Kommunikationsstruktur und somit mehr Präzision, schnelleres Verständnis und weniger Fehlerquellen. Patterns erlauben grundsätzlich Programme und Systeme mit gleichartiger Struktur. Dies bedeutet, dass eine Einarbeitung in vorhandene Systeme erleichtert wird, da Softwaredesign und Strukturen gemäß den Patterns quasi vereinheitlicht werden können, wenn bei Verwendung unterschiedlicher Ent- Wicklungsumgebungen und Programmiersprachen auf eine möglichst einheitliche Implementierung geachtet wird und sprachspezifische Sonderlösungen zur Gewährleistung einer Übertragbarkeit vermieden werden.
[0026 ] Eine Abgrenzung zwischen einer Anwendung von Patterns und einer gewöhnlichen Umsetzung von bisher bekannten Standardisierungen besteht darin, dass Pat- terns mehr Freiraum für Interpretationen und der Art einer Implementierung von Funktionen lassen. Vielmehr stellen sie eine mögliche Vorstufe zur Standardisierung dar oder helfen bei der Strukturierung und Implementierung ähnlicher Aufgabenstellungen. Neben einer Steuerung von Maschinenkomponenten, können des weiteren auch spezielle Patterns für Fehlerbehandlungen, sog. MMI Anbindungen, d.h. standardisierte Schnittstellen zur Bedie- nung einer Anlage über entsprechende Visualisierungssysteme, zu Zwecken einer Para- metrisierung oder einer Not-Aus Behandlung vorgesehen werden.
[0027] In Figur 1 ist ein beispielhaftes sogenanntes „DAP Pattern" als Beispiel für ein Architekturmuster für ein Automatisierungssystem dargestellt, das durch eine Komponentenhierarchie mit drei Schichten gebildet wird. Die entsprechende Steuerung ist so- mit aus einer Anzahl von Komponenten aufgebaut, wobei die jeweiligen Komponenten grundsätzlich in andere Steuerungen bzw. Programme übertragbar sind. Im Gegensatz dazu werden gemäß dem Stand der Technik in der Regel Programmteile in sogenannten „Bibliotheken" zur Wiederverwendung hinterlegt. Diese Bibliotheken umfassen in der Regel eine große Anzahl von Funktionen zur Behandlung eines bestimmten Themas, wie bspw. Grafik-, Mathematik-, Kommunikations- oder Bewegungsaspekte. Jedoch sind derartige
Bibliotheken in der Regel nicht deterministisch und kontextunabhängig aufgebaut. Dies bedeutet, dass die Bibliotheken eine Sammlung von verschiedenen Programmteilen umfassen, die jedoch nicht zwangsläufig explizit auf den vorliegenden Anwendungsfall zugeschnitten sind. Des weiteren müssen diese Bibliotheken „erlernt" und im entsprechenden Programmcode eingebunden werden. Hierdurch wird der Programmcode der Steuerung vergrößert und damit zunehmend komplexer. Auch muss damit die Steuerung geändert werden, wenn Änderungen an der Bibliothek vorzunehmen sind. Eine unabhängig voneinander vorzunehmende Bearbeitung ist somit nicht möglich. Bibliotheken werden also für beliebige Kontexte entworfen, wodurch sie selbstverständlich variabler und unspezifischer gestaltet sein müssen.
[0028 ] Im Gegensatz dazu ermöglicht der Automatisierungsbereich ein gezieltes Bilden von Komponenten bspw. in einer Produktlinie und gibt somit einen spezifischen Kontext vor, der sich in der Regel nur wenig ändert. Bei einer Produktlinie aus dem Auto- matisierungsbereich liegt ein spezieller Fokus auf den Produkten, die auf der Produktlinie entstehen bzw. zu generieren sind. Hierbei können die Komponenten per Definition nicht mehr vollkommen unabhängig voneinander betrachtet werden, sondern stets im Rahmen der gesamten Produktlinie, da ein gewisses Zusammenspiel direkter oder indirekter Art zwischen den Komponenten besteht und demnach zu berücksichtigen ist. Die Komponen- ten der Produktlinie lassen sich nach dem zugrundeliegenden Ansatz des in Figur 1 dargestellten Architekturpatterns in drei Kategorien einteilen:
1. Plattform-Komponenten
2. Anlagen-Komponenten
3. Domänen-Komponenten
Plattform-Komponenten erbringen sogenannte Basisdienste innerhalb jeder Anwendung der Produktlinie und abstrahieren die zugrundeliegende Hardware. Sie stellen die allgemeinsten Komponenten dar und sind mit sogenannten „Device"-Treibern mit standardisierten Schnittstellen vergleichbar. Die Art der jeweils in der Produktlinie zum Einsatz kommenden Plattform-Komponenten hängt von dem Anwendungsfeld der Produktlinie ab. Ty- pische Beispiele für die Dienste der Plattform-Komponenten sind die Kommunikation mit
Hardware-Komponenten, wie beispielsweise Motoren, Pumpen oder Ventilen. Eine Plattform-Komponente (Device-Treiber) kapselt bspw. für den Anwendungsfall des Motors die hardwarespezifischen Eigenschaften des Motors ab und liefert über ein idealisiertes Interface den Zugriff auf dessen Grundfunktionen wie bspw. eine Start- und Stopfunktion. Zugriff auf die Plattform-Komponenten haben hierbei ausschließlich die sogenannten Anlagen-Komponenten, die auf einer nächsthöheren Hierarchiestufe angeordnet sind. [0029] Diese Anlagen-Komponenten enthalten die prinzipielle Ablauflogik für beispielsweise eine Produktlinie als Komposition einer Anzahl von Plattform-Komponenten und ggf. weiteren Anlagen-Komponenten. Sie werden daher auch als „Controller" bezeichnet. Ein Wechsel einer zugrunde liegenden Plattform oder ein Austausch einzelner Bauteile erfordert daher ausschließlich Änderungen an den Plattform-Komponenten, da die darauf aufbauenden Anlagen-Komponenten über standardisierte Schnittstellen mit den jeweiligen Plattform-Komponenten kommunizieren. Die Anlagen-Komponenten sind daher allgemein und ohne spezifischen Bezug zu den auf der Produktlinie hergestellten Produkten. Die Anlagen-Komponenten selbst werden durch übergeordnete Domänen-Komponenten zur Steuerung des gesamten Anlagenverhaltens bzw. der Produktlinie kontrolliert.
[0030 ] Die Domänen-Komponenten enthalten somit eine entsprechende Anwendungslogik für komplexere Anwendungsfälle bis hin zu einer eigentlichen Maschinenlogik. Sie benutzen bzw. steuern ausschließlich die vorangenannten Anlagen-Komponenten oder andere Domänen-Komponenten zur Steuerung des gesamten spezifischen Anlageverhal- tens. Sie stellen somit ebenfalls Steuerungs-Komponenten dar, die, wie die Anlagen- Komponenten, untergeordnete Komponenten steuern. Jede der drei genannten Komponenten kann daher mit einer objektorientiert programmierten frameworkbasierten Steuerung ausgestattet werden, wobei beispielsweise die Objekte jeweils aus den untergeordneten Komponenten bestehen und sich daher gegenüber den Objekten anderer Komponen- ten unterscheiden. Die Steuerung selbst muss hierbei nicht verändert werden. Lediglich die objektspezifischen Funktionseinheiten werden an die jeweiligen Objekte angepasst.
[0031] Für eine klare Strukturierung und zur Ermöglichung einer Wiederver- wendbarkeit, Austauschbarkeit und Wartbarkeit sollten sich die Funktionsaufrufe zur Steuerung der untergeordneten Komponenten jeweils immer auf die entsprechend untergeordne- te Hierarchiestufe beziehen, jedoch nicht mehrere Hierarchiestufen überspringen, so dass eine klare Gruppierung der untergeordneten Komponenten zu Objekten ermöglicht wird. Gemäß diesen Vorgaben finden in einem nach dem in Figur 1 beschriebenen DAP Pattern strukturierten Modell Kommunikationsbeziehungen nur in vertikaler Richtung statt. Bereits in diesem Modell wird eine baumartige Strukturierung des Modells sichtbar. Diese Struktu- rierung orientiert sich nahe an der entsprechenden Hardwarestruktur, so dass zwischen
Hard- und Software eine Analogie besteht, die ein einfaches und leichtes Verständnis des jeweiligen Softwaremodells ermöglicht. Dieser Aufbau wird insbesondere durch eine voranstehend dargestellte objektorientierte Vorgehensweise zur Programmierung ermöglicht. Analog zu der Beziehung der einzelnen Hardware-Komponenten werden somit Funktionen von Objekten durch übergeordnete Objekte gesteuert. [0032 ] Der voranstehend bereits beschriebene Aspekt der Simulation wird nachfolgend ergänzend in allgemeiner Form diskutiert. Demnach können Objekte mittels des Simulationsmoduls simuliert und Signale oder Befehle der Steuerung zur Steuerung von Grundfunktionen mindestens eines Objekts des Automatisierungssystems von dem jeweili- gen Simulationsmodul empfangen werden. Beispielsweise kann hierbei die Hierarchieebene der von den Plattform-Komponenten angesteuerten Hardware durch das Simulationsmodul, bspw. in Form einer entsprechend ausgerüsteten Recheneinheit oder aber in Form eines entsprechenden Quelltextes bzw. Programm(teil)s ersetzt werden, so dass die jeweiligen Plattform-Komponenten mit dem Simulationsmodul kommunizieren können. Alle übergeordneten Komponenten oberhalb der Plattform-Komponenten werden von diesem Austausch nicht beeinflusst und verrichten daher ihren normalen Betrieb. Selbstverständlich kann ebenso eine höhere Hierarchieschicht ersetzt und entsprechend simuliert werden.
[0033 ] Dieser Aspekt der Simulation geht also davon aus, dass jedes physikalische Gerät einer Maschine (voranstehend als Objekt bezeichnet), das durch Software „er- reichbar" und somit entweder aktiviert und/oder abgefragt (oder beides) werden kann, bei Bedarf direkt in dieser Software simuliert werden kann. Jedes physikalische Element der Hardware erhält also ein unmittelbares Äquivalent in der Software, das voranstehend bspw. als Funktionseinheit bezeichnet wurde. Somit wird bspw. jede Lichtschranke durch einen Programmabschnitt bzw. Quelltextabschnitt „DEV_Lichtschranke", jeder Tempera- turgeber durch ein „DEV_Temperature", jeder Motor durch ein „DEV_Motor" usw. abgebildet. Softwaretechnologisch muss ein Element bzw. Objekt, das mehrfach in der Maschine bzw. dem Automatisierungssystem verbaut wurde, natürlich nur einmal als Funktionseinheit programmiert und anschließend entsprechend häufig instanziiert werden. Diese Programmierung entspricht der Bildung einer Klasse, wie sie ebenfalls voranstehend bereits eingeführt wurde. Die Instanziierung beliebig vieler Elemente dieser Klasse entspricht somit der Vereinbarung von Variablen dieser Klasse.
[ 0034 ] Die Klassen, die ein physikalisches Element repräsentieren, beginnen in der nachfolgenden Beschreibung mit dem Präfix „DEV_". Sie bilden sowohl eine Abstraktionsschicht der Hardware (Device-Treiber) als auch die Simulationselemente. Anschaulich ist dies in Figur 4 dargestellt. Sinnvollerweise kann ein solches „DEV"-Element in mehrere
Dateien aufgeteilt sein, sodass z.B. der Simulations-Teil als Simulationsmodul leicht von der eigentlichen Steuerungssoftware der Funktionseinheit getrennt werden kann. Wann immer also die Steuerung mit einem Hardware-Element kommuniziert, wird nicht ein Ein- oder Ausgang der Hardware, bspw. durch Setzen oder Rücksetzen eines Bits o.a., benutzt, sondern es wird das für diese Hardware vorgesehene Device durch Aufruf der für das Hardware-Element sinnvollen Methode verwendet. Es wird also die entsprechende Steuerfunktion der Funktionseinheit eingesetzt. Ein zugrundeliegender Quelltext bzw. Programmabschnitt kann bspw. derart aufgebaut sein:
Lichtschrankel : DEV_Lichtschranke;
MotoM : DEV_MOTOR;
Begin
If Lichtschrankel. isθn() then begin
MotoM .SetSpeed (...); MotoM .Start(...); End; End;
[0035] Auf diese Weise findet an keiner Stelle des eigentlichen Quelltexts bzw. Sourcecodes ein direkter Bezug zu den tatsächlich verbauten Elementen bzw. Objekten statt. Jede physikalische Verbindung zwischen Hard- und Software ist in der Plattform- Schicht, d.h. in den Funktionseinheiten, versteckt. Da alle sog. „Devices" von einer abstrak- ten Basisklasse „DEV_Generic" erben bzw. von dieser abgeleitet sind, haben alle „Devices" sowohl einen Namen zur Identifikation, eine physikalische IO-Adressen als auch ein sog. „Flag" bzw. einen Schalter zum Ein- und Ausschalten der Simulation. Ist also keine reale Maschine (d.h. kein Objekt) vorhanden, oder wird aus anderen Gründen eine Simulation gewünscht, so können die Devices bei entsprechender Konfiguration selbst entschei- den, wie sie sich verhalten werden. Im beispielhaften Fall einer Lichtschranke könnte sich dies wie folgt darstellen:
DEV_Lichtschranke
Methode isON()
If not Simulation then begin
Return lO Adress; /* return tatsächlichen Wert der Lichtschranke */ Else I* Simulation aktiv */
Return TRUE; /* simuliere ständig eingeschaltete Lichtschranke */ End_if;
[0036] In diesem Fall wird also bei einer Simulation permanent der Wert „TRUE" gesetzt, der einer dauerhaft aktiven Lichtschranke entspricht. Dieser Simulationsteil kann in der Realität natürlich beliebig aufwändig und im Laufe der Weiterentwicklung von Maschinen immer weiter entwickelt und perfektioniert werden.
[0037] Eine Abspaltung des Simulationsanteils (nachfolgend als Teil 2 bezeichnet) als Simulationsfunktion des Simulationsmoduls von der Steuerfunktion (Teil 1) der Funktionseinheit bietet den Vorteil, dass der Simulationsanteil bei Bedarf, wie bspw. bei einer Auslieferung der Maschine an den Kunden, abgespalten werden kann. So kann sich eine Trennung in zwei Teile bspw. wie folgt darstellen:
TeiM : Methode isON()
If not Simulation then begin
Return IO_Adress; /* return tatsächlichen Wert der Lichtschranke */ Else /* Simulation aktiv */ #ifdef WithSimulation
CALL Simulation (); #endif
End_if;
Teil 2: SimulationO /* Simulation aktiv */
Return TRUE; /* simuliere ständig eingeschaltete Lichtschranke */ End_if;
[0038 ] In diesem Fall kann allerdings das Simulationsmodul als Teil 2 nicht ein- fach entfallen, da ansonsten ein Compiler beim Compilieren eine Fehlermeldung auswerfen würde, da nun ein entsprechend vorgesehener Aufruf der Simulationsfunktion „CALL SimulationO" nicht mehr gültig wäre. Der Aufruf „CALL Simulation()" in Teil 1 könnte daher bspw. durch einen sog. Compiler-Switch als Schalter der Form „#ifdef WithSimulation" di- sabled bzw. ausgeschaltet werden. Ein Setzen dieses Schalters eliminiert damit die Simulation aus der Software.
[0039] Des weiteren können, wie voranstehend bereits beschrieben, mehrere Simulationsfunktionen in einer Bibliothek zusammengefasst werden. Darüber hinaus kön- nen verschiedene Bibliotheken auch unterschiedliche Simulations-Szenarien umfassen oder Simulations-Szenarien durch externe Ereignisse oder Parametrierungen gesteuert werden. Dieser Aspekt ist insbesondere für ein kontinuierliches Testen bei der Weiterentwicklung der gesamten Steuerung bzw. der Software vorteilhaft, da hierbei beliebige Kombinationen, Teilsystembildungen und Abläufe insbesondere von Fehlerzuständen möglich sind, die beliebig oft und in beliebiger Reihenfolge wiederholt werden können. Dadurch ist mit Hilfe einer kontinuierlichen Weiterentwicklung der Simulations- bzw. Test-„Cases" bzw. -Szenarien auch langfristig eine vollständige Abdeckung aller relevanten Test-Funktionen möglich. Tests können jederzeit reproduziert und über lange Zeiträume automatisch ausgeführt und ausgewertet werden.
[ 0040 ] Ein weiterer Vorteil ergibt sich aus der Tatsache, dass diese Art des Tes- tens zu Beginn bzw. in einem ersten Schritt auch keine vollständige Maschinenbeschreibung voraussetzt, da diese aus sich selbst heraus mit der Instanziierung der Objekte aus den Klassen entsteht. Die in den oberen Schichten angesiedelten Elemente „wissen" nichts von der tatsächlichen Hardware und verhalten sich gemäß ihrer vorgesehenen Aufgaben völlig normal. Darüber hinaus bringt eine Änderung der Maschine auch eine direkte Änderung der Simulation mit sich, sofern es sich um Änderungen an den Objekten des Automatisierungssystems, wie bspw. der Aktorik, Sensorik oder Transportelementen („Motion") etc., handelt.
[0041 ] Gemäß einer anderen Ausführungsform sind die Schnittstellen des Weiteren zur kommunikationstechnischen Einbindung von funktionsspezifischen Modulen für das jeweilige Objekt vorgesehen.
[ 0042 ] Neben den objektspezifischen Funktionseinheiten können somit auf gleiche Art und Weise zusätzliche Module von der frameworkbasierten Steuerung ausgeführt werden. Die Module können beispielsweise neue Funktionalitäten für die Steuerung bereitstellen, die z.B. individuelle Wünsche von Kunden berücksichtigen und integrieren können. So kann ein Kunde z.B. eigene Programme ausführen lassen ohne in den Framework- Quelltext der Steuerung eingreifen zu müssen, um beispielsweise Zählerstände abzufra- gen, Benachrichtigungen bei Fehlerzuständen auszulösen oder um kundeneigene Steuerungen zu programmieren usw.. Somit kann auf diese Weise kein Fehler in die Steuerung eingebaut werden, der ggf. z.B. zu unerwünschtem Verhalten des entsprechenden Objekts führt.
[0043 ] Außerdem kann das mindestens eine Objekt mindestens eine automatisierte Maschine umfassen. Hierbei kann ein sog. „Objekt" der Steuerung eine oder mehrere Maschinen zu einer virtuellen Einheit vereinen. Letztlich kann so die komplette Produktionslinie als ein einziges Objekt zusammengefaßt werden, das aus Objekten bzw. einzelnen Maschinen gebildet wird, die wiederum aus weiteren Objekten aggregiert werden, die sich beispielsweise aus Plattform-Komponenten und deren Teilen zusammensetzen können.
[0044 ] Entsprechend einer anderen Ausführungsform umfasst das Automatisierungssystem mindestens eine Produktlinie mit einer Anzahl von Objekten, die als automatisierte Maschinen ausgeführt sind.
[ 0045] Ferner kann die frameworkbasierte Steuerung eine Struktur aufweisen, die eine Struktur der automatisierten Maschinen des Automatisierungssystems widerspiegelt. Hierbei kann, wie voranstehend bereits beschrieben, jede Maschine oder Teile der jeweiligen Maschine als einzelnes Objekt bzw. als einzelne Objekte in der Steuerung identifiziert sein, so dass eine Struktur des Automatisierungssystems mit der Struktur der Steu- erung übereinstimmt.
[0046] Des Weiteren kann ein Zugriff auf die Steuerung geschützt sein. Dies kann bspw. mittels eines Kennworts bzw. Passworts oder anderer geeigneter zugriffsbeschränkender Maßnahmen erfolgen, wodurch die frameworkbasierte Steuerung vor einer unerwünschten Manipulation geschützt wird. Jedoch bleiben maschinenspezifische EIe- mente, wie die objektspezifischen Funktionseinheiten oder die funktionsspezifischen Module, hiervon unberührt und können verändert bzw. angepasst werden.
[ 0047 ] Entsprechend einer weiteren Ausführungsform ist ein Quelltext bzw. Quellcode der frameworkbasierte Steuerung automatisch generierbar.
[0048 ] Außerdem wird ein Verfahren zum Test eines Automatisierungssystems mit einer frameworkbasierten Steuerung gemäß der voranstehenden Beschreibung bereitgestellt, wobei das Automatisierungssystem eine frameworkbasierte Steuerung zur Steue- rung von Grundfunktionen mindestens eines Objekts der Anzahl von Objekten mittels objektspezifischer Funktionseinheiten umfasst. Die Steuerung ist objektunabhängig ausgeführt und umfasst standardisierte Schnittstellen zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten mittels vorkonfigurierter Funktionsaufrufe. Das Verfahren umfasst außerdem einen ersten Auswahlschritt zum wahlweisen Ausführen einer objektspezifischen Steuerfunktion oder Ausführen der mindestens einen Simulationsfunktion durch die Funktionseinheit.
[0049] Gemäß einer Ausführungsform wird der erste Auswahlschritt von der Funktionseinheit durchgeführt.
[0050 ] Des weiteren wird ein Verfahren zur frameworkbasierten Steuerung eines
Automatisierungssystems zum Steuern von Grundfunktionen mindestens eines Objekts des Automatisierungssystems mittels einer frameworkbasierten Steuerung, wobei die Steuerung objektunabhängig ausgeführt ist, mit den folgenden Schritten bereitgestellt:
- Einlesen von objektspezifischen Funktionseinheiten durch die Steuerung zu einer Startzeit des Automatisierungssystems mittels Funktionsaufrufen über standardisierte
Schnittstellen zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten,
- Auswählen mindestens einer in den Funktionseinheiten umfassten objektspezifischen Steuerfunktion oder mindestens einer in Simulationsmodulen der Funktions- einheiten integrierten Simulationsfunktion,
- Ausführen der mindestens einen gewählten Funktion.
[0051 ] Die vorliegende Beschreibung deckt auch ein Computerprogramm mit Programmcode ab, das alle Schritte des Verfahrens zur frameworkbasierten Steuerung eines Automatisierungssystems durchführt, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit ausgeführt wird.
[0052 ] Des Weiteren deckt die vorliegende Beschreibung ein Computerprogrammprodukt mit Programmcodemitteln ab, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens zur frameworkbasierten Steuerung eines Automatisierungssystems durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit ausgeführt wird. [0053 ] Weitere Vorteile und Ausgestaltungen der Erfindung ergeben sich aus der Beschreibung und den beiliegenden Zeichnungen.
[0054 ] Es versteht sich, dass die voranstehend genannten und die nachstehend noch zu erläuternden Merkmale nicht nur in der jeweils angegebenen Kombination, son- dem auch in anderen Kombinationen oder in Alleinstellung verwendbar sind, ohne den Rahmen der vorliegenden Erfindung zu verlassen.
[0055] Die Erfindung ist anhand eines Ausführungsbeispieles in der Zeichnung schematisch dargestellt und wird im folgenden unter Bezugnahme auf die Zeichnungen ausführlich beschrieben.
Kurzbeschreibung der Zeichnungen
Figur 1 zeigt ein mögliches Architekturpattern bzw. -muster mit drei Hierarchie- Schichten in schematischer Darstellung,
Figur 2 zeigt einen Aufbau einer Ausführungsform einer frameworkbasierten Steuerung in schematischer Darstellung,
Figur 3 zeigt einen Ausschnitt einer Ausführungsform einer frameworkbasierten
Steuerung als Auszug eines zugrundeliegenden Quellcodes.
Figur 4 zeigt einen weiteren Aufbau der frameworkbasierten Steuerung in schematischer Darstellung.
Ausführliche Beschreibung
[0056] Figur 1 zeigt ein Architekturpattern bzw. -muster am Beispiel eines sogenannten „DAP Pattern", das einer frameworkbasierten Steuerung zugrunde liegen kann und das aus einer Komponentenhierarchie besteht, die drei Komponentenschichten 12,13,14 und eine untergeordnete Hardwareschicht 11 umfasst. In der Praxis können durchaus auch deutlich mehr als drei Komponentenschichten verwendet werden, um weitere Abstraktionen zu ermöglichen. Die Hardwareschicht 11 besteht aus einem Motor 11a und einer Lichtschranke 11 b, die jeweils von einer sogenannten Plattform-Komponente 12a bzw. 12b gesteuert werden, die in der Schicht der Plattform-Komponenten 12 angeordnet sind. Diese wiederum werden von einer Anlagen-Komponente 13a gesteuert, die in der Anlagenschicht 13 angeordnet ist. Übergeordnet befindet sich die sogenannte Domain- Komponente 14a, die die Anlagen-Komponente 13a steuert und ihrerseits in der Domain- Schicht 14 angeordnet ist. Wie aus der schematischen Darstellung ersichtlich ist, wird die jeweilige Komponente einer bestimmten Schicht der dargestellten Hierarchie jeweils nur von der direkt darüber angeordneten Komponente gesteuert. Eine übergreifende Steuerung über mehrere Hierarchieschichten ist nicht vorgesehen, da hierdurch der beabsichtigte modulare Aufbau der Komponentenhierarchie gestört werden würde. Diese Einschrän- kung bezieht sich explizit nur auf eine übergreifende Steuerung, die zwischengeordnete Komponenten übergehen würde. Selbstverständlich kann durchaus eine Plattform- Komponente auch direkt von einer Domänen-Komponente angesteuert werden, ohne die vorgesehene modulare Struktur zu behindern.
[0057 ] Figur 2 zeigt ein Beispiel für eine frameworkbasierte Steuerung 21 für ein Automatisierungssystem 20. Diese frameworkbasierte Steuerung 21 basiert auf einer sogenannten „State-Maschine" 22, die von einem Standardalgorithmus gebildet wird, die bzw. der für verschiedenartige Maschinen identisch ausgebildet sein kann und Grundfunktionen 23 eines Objekts bzw. einer Maschine steuert. Diese Grundfunktionen können bspw. das definierte Verfahren an eine bestimmte Position ("Setze Position"), das Ansteuern oder Überwachen einer Lichtschranke ("Lichtschr. xy") oder das Steuern eines Antriebs ("Antrieb an", "Antrieb aus") umfassen und lassen sich um beliebige weitere Funktionen ("Fkt n") erweitern. Dieses Status-Modell kann bspw. dem sog. „OMAC"- (bzw. Weihenstephan-) Standard entsprechen.
[0058 ] Der OMAC-Standard (Open Modular Architecture Controls) beschreibt mögliche Zustände einer Maschine sowie mögliche Zustandsübergänge und Aktionen zusammen mit ihren jeweiligen Vor- und Nachbedingungen. Auf diese Weise kann mit Hilfe der frameworkbasierten Steuerung eine Standardimplementierung für die zugrundeliegende State-Maschine realisiert und bereitgestellt werden, die für alle Maschinen einer Produktlinie bzw. Anlage identisch ist und eine objektunabhängige Anlagenschicht definiert. Von dieser Implementierung sind maschinenspezifische Funktionen bzw. objektspezifische
Funktionseinheiten 25 in einer objektspezifischen Plattformschicht zu trennen. Diese werden über standardisierte Schnittstellen 26 mittels vorkonfigurierter Funktionsaufrufe kommunikationstechnisch eingebunden und erlauben eine Integration von kundenspezifischen Implementierungen, wie bspw. kundeneigene Anwendungen ("APL"), oder Funktionen zur Fehlerbehebung ("ERP"). Dabei verhält sich bspw. eine Etikettiermaschine bei einem Übergang von einem Zustand "starting" zu einem Zustand "execute" aufgrund der ablaufenden Funktionen anders als eine Packmaschine. Auch kann der "execute" Zustand selbst bei den jeweiligen Maschinen unterschiedlich ausgeführt sein. Daher ist die Implementierung der State-Maschine von der Implementierung der objektspezifischen Funktionseinhei- ten der jeweiligen Maschine zu trennen. Dasselbe gilt für funktionsspezifische Module 27 und Erweiterungen sowie für entsprechende Schnittstellen zur Hardware (Devices). Im Gegensatz zu einer Softwareprogrammierung mit einer objektorientierten Programmiersprache werden diese Funktionalitäten nicht durch Verwendung von abstrakten Klassen und Interfaces umgesetzt, sondern werden im Bereich der Automatisierungstechnik identifiziert und separat implementiert, wie in der nachfolgenden Figur 3 dargestellt.
[0059] Figur 3 zeigt einen Ausschnitt eines Quellcodes einer Ausführungsform einer frameworkbasierten Steuerung ("SW-Framework Code") für ein Automatisierungssystem, das einen Zustandswechsel von einem Zustand "idle" ("stillstehend") zu einem Zustand "starting" ("starten") darstellt. Hierbei sind an definierten Stellen der frameworkbasier- ten Steuerung Funktionsaufrufe ("CaII before_Change()" und CaII after_Change()") eingefügt. Diese erlauben eine Trennung der Steuerung von verschiedenen funktions-, objekt- bzw. plattformspezifischen Funktionen ("Function before_Change()" und "Function af- ter_Change()"), die in den extern angeordneten objektspezifischen Funktionseinheiten bzw. funktionsspezifischen Modulen ("Maschinen-spez. Code") hinterlegt sind. Auf diese Weise wird das Einbringen von zusätzlichem Quelltext bzw. Quellcode für diese Funktionen in die frameworkbasierte Steuerung vermieden. Um Fehlermeldungen eines Compilers an diesen Schnittstellen zu vermeiden, müssen die Funktionsaufrufe deklariert werden. Diese Deklaration findet außerhalb des Framework-Quellcodes statt. Bei einer konsequenten Einhaltung dieser Vorgehensweise können somit die funktions-, objekt- bzw. plattformspezifi- sehen Funktionen grundsätzlich in externen Paketen bzw. Dateien ausgelagert werden.
[0060] Eine Realisierung der frameworkbasierten Steuerung kann somit unabhängig von einer Erstellung der objektspezifischen Funktionseinheiten bzw. der funktionsspezifischen Module erfolgen. Nach einer objektunabhängigen Fertigstellung der frameworkbasierten Steuerung kann dann eine Einbindung der maschinenspezifischen Funktio- nalitäten mittels der objektspezifischen Funktionseinheiten über jeweils an vorab identifizierten Stellen vorzusehenden Funktionsaufrufe erfolgen. Die frameworkbasierte Steuerung selbst bleibt hierbei unberührt. Dies gilt natürlich auch für eine Implementierung von Schnittstellen zu externen Systemen, wie bspw. MMI, ERP, oder eine Fehlerbehandlung sowie Hardwareschnittstellen. So kann ein Kunde z.B. eigene Programme ausführen las- sen, ohne in den Framework-Quellcode der Steuerung eingreifen zu müssen, um bei- spielsweise Zählerstände abzufragen, Benachrichtigungen bei Fehlerzuständen auszulösen oder um kundeneigene Steuerungen zu programmieren usw. Somit können auf diese Weise Fehlerquellen in der Steuerung minimiert werden, die ggf. z.B. zu unerwünschtem Verhalten des entsprechenden Objekts führen. Innerhalb der frameworkbasierten Steue- rung hat jede Schicht der Hierarchiestruktur, wie sie in Figur 1 dargestellt ist, eigene Funktionsaufrufe. Diese sind von Funktionsaufrufen anderer Schichten unabhängig und sind in Figur 2 schematisch dargestellt. Hierbei müssen grundsätzlich nicht alle Funktionsaufrufe tatsächlich mit einer objektspezifischen Funktionseinheit in Verbindung treten können, es ist ebenso möglich, diese als sogenannte "leere" Funktionsaufrufe auszuführen, die ohne Funktion sind bzw. zu einem späteren Zeitpunkt mit einer objektspezifischen Funktionseinheit oder einem funktionsspezifischen Modul verknüpft werden können.
[0061] Figur 4 zeigt einen weiteren Aufbau einer Steuerung für ein Automatisierungssystem in schematischer Darstellung. Hierin bildet eine frameworkbasierte Steuerung (43) als objektunabhängiger Teil eine objektunabhängige Anlagenschicht (41). In der dar- gestellten Ausführungsform werden physikalische Elemente bzw. Objekte (nicht dargestellt) des zugrundeliegenden Automatisierungssystems, nämlich eine Lichtschranke, ein Motor und ein Temperaturgeber jeweils durch ein Äquivalent in einer sog. Plattformebene
(42) in Form einer Funktionseinheit (44, 45, 46, 47, 48) abgebildet bzw. virtualisiert und zur Identifizierung beispielhaft mit dem Prävix „DEV" als Kurzform für „Device" gekennzeichnet.
[ 0062] Jede Funktionseinheit (44, 45, 46, 47, 48) weist jeweils eine Anzahl von
Steuerfunktionen (44a, 45a, 46a) zur Ansteuerung der realen Objekte (nicht dargestellt) auf. Des weiteren können die Funktionseinheiten (44, 45, 46, 47, 48) jeweils ein Simulationsmodul (45b) aufweisen, das zur besseren Übersicht lediglich in der Funktionseinheit (45) dargestellt ist, grundsätzlich aber in allen Funktionseinheiten (44, 45, 46, 47, 48) vor- gesehen werden kann. Somit bildet die Plattformebene (42) mittels der Funktionseinheiten
(44, 45, 46, 47, 48) sowohl eine Abstraktionsschicht der Hardware (Device-Treiber) als auch die Simulationselemente. Die Funktionseinheiten (44, 45, 46, 47, 48) können mittels standardisierter Schnittstellen in direktem Kontakt mit der frameworkbasierten Steuerung
(43) stehen. Ebenso können Funktionseinheiten (45) aber auch mit anderen Funktionsein- heiten (44, 46, 47, 48) in Kontakt stehen.
[0063 ] Wann immer also die Steuerung (43) mit einem Hardware-Element kommuniziert will, wird nicht ein Ein- oder Ausgang der Hardware, bspw. durch Setzen oder Rücksetzen eines Bits o.a., benutzt, sondern es wird die für diese Hardware vorgesehene Funktionseinheit (44, 45, 46, 47, 48) durch Aufruf der entsprechenden Steuerfunktion (44a, 45a, 46a) der Funktionseinheit (44, 45, 46, 47, 48) eingesetzt. Ein zugrundeliegender Quelltext kann bspw. derart aufgebaut sein:
Lichtschrankel : DEV_Lichtschranke; Motort : DEVJVIOTOR;
Begin
If Lichtschrankel. isθn() then begin
Motorϊ.SetSpeed (...);
Motor1.Start(...); End; End;
[0064 ] Dieser Aufbau beitet den Vorteil, dass an keiner Stelle des eigentlichen
Quelltext der frameworkbasierten Steuerung (43) ein direkter Bezug zu den tatsächlich verbauten Elementen bzw. Objekten stattfinden muss. Jede physikalische Verbindung zwischen Hard- und Software ist vielmehr in der Plattform-Schicht (42), d.h. in den Funktionseinheiten (44, 45, 46, 47, 48), versteckt.

Claims

Patentansprüche
1. Automatisierungssystem mit einer Anzahl von zu steuernden Objekten, wobei das Automatisierungssystem eine frameworkbasierte Steuerung (21) zur Steuerung von Grundfunktionen (23) mindestens eines Objekts der Anzahl von Objekten mittels objektspezifischer Funktionseinheiten (25) umfasst, wobei die Steuerung (21) objektunabhängig ausgeführt ist und standardisierte Schnittstellen (26) zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten (25) mittels vorkonfigurierter Funktionsaufrufe umfasst, wobei jede Funktionseinheit (25) mindestens einem der Objekte zugeordnet und mittels objektspezifischer Steuerfunktionen zum Ansteuern der jeweiligen Grundfunktion (23) des jeweils zugeordneten Objekts konfiguriert ist, wobei jedes Objekt aus der Anzahl von Objekten mittels der zugeordneten objektspezifischen Funktionseinheiten (25) in der Steuerung (21) virtualisiert ist und die Objekte der Anzahl von Objekten mindestens während eines Betriebszustandes des Automatisierungssystems ausschließlich von der frameworkbasierten Steuerung (21) mittels der objektspezifischen Funktionseinheiten (25) ansprechbar und steuerbar sind, und jede der Funktionseinheiten (25) ein in der jeweiligen Funktionseinheit (25) integriertes Simulationsmodul mit mindestens einer Simulationsfunktion umfasst und wahlweise zum Ausführen der objektspezifischen Steuerfunktion oder zum Ausführen der mindestens einen Simulationsfunktion konfiguriert ist.
2. Automatisierungssystem nach Anspruch 1, wobei in der Funktionseinheit (25) definiert wird, ob das Ausführen der objektspezifischen Steuerfunktion oder das Ausführen der mindestens einen Simulationsfunktion ausgewählt wird.
3. Automatisierungssystem nach Anspruch 1 oder 2, wobei die Schnittstellen (26) des weiteren zur kommunikationstechnischen Einbindung von funktionsspezifischen Modulen (27) für das jeweilige Objekt vorgesehen sind.
4. Automatisierungssystem nach Anspruch 1 bis 3, wobei das mindestens eine Objekt mindestens eine automatisierte Maschine umfasst.
5. Automatisierungssystem nach einem der Ansprüche 1 bis 4, wobei das Automatisierungssystem mindestens eine Produktlinie mit einer Anzahl von Objekten umfasst, die als automatisierte Maschinen ausgeführt sind.
6. Automatisierungssystem nach einem der Ansprüche 1 bis 5, wobei die frameworkbasierte Steuerung eine Struktur aufweist, die eine Struktur der automatisierten Maschinen des Automatisierungssystems widerspiegelt.
7. Automatisierungssystem nach einem der Ansprüche 1 bis 6, wobei ein Zugriff auf die Steuerung (21) geschützt ist.
8. Automatisierungssystem nach einem der Ansprüche 1 bis 7, wobei ein Code der frameworkbasierten Steuerung (21) automatisch generierbar ist.
9. Verfahren zum Test eines Automatisierungssystems mit einer frameworkbasierten Steuerung nach einem der Ansprüche 1 bis 8, wobei das Automatisierungssystem die frameworkbasierte Steuerung zur Steuerung von Grundfunktionen (23) mindestens eines Objekts der Anzahl von Objekten mittels objektspezifischer Funktionseinheiten (25) umfasst, wobei die Steuerung (21) objektunabhängig ausgeführt ist und standardisierte Schnittstellen (26) zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten (25) mittels vorkonfigurierter Funktionsaufrufe umfasst,
wobei das Verfahren einen ersten Auswahlschritt zum wahlweisen Ausführen einer objektspezifischen Steuerfunktion oder Ausführen der mindestens einen Simulationsfunktion durch die Funktionseinheit (25) umfasst.
10. Verfahren nach Anspruch 9, wobei der erste Auswahlschritt von der Funktionseinheit (25) durchgeführt wird.
11. Verfahren zur frameworkbasierten Steuerung eines Automatisierungssystems zum Steuern von Grundfunktionen (23) mindestens eines Objekts des Automatisierungssystems mittels einer frameworkbasierten Steuerung (21), wobei die Steuerung (21) objektunabhängig ausgeführt ist, mit den folgenden Schritten:
Einlesen von objektspezifischen Funktionseinheiten (25) durch die Steuerung zu einer Startzeit des Automatisierungssystems mittels Funktionsaufrufen über standardisierte Schnittstellen (26) der Steuerung zur kommunikationstechnischen Einbindung der objektspezifischen Funktionseinheiten (25),
Auswählen mindestens einer in den Funktionseinheiten (25) umfassten objektspezifischen Steuerfunktion oder mindestens einer in Simulationsmodulen der Funktionseinheiten (25) integrierten Simulationsfunktion,
Ausführen der mindestens einen gewählten Funktion.
12. Computerprogramm mit Programmcodemitteln, um alle Schritte eines Verfahrens nach Anspruch 11 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit ausgeführt wird.
13. Computerprogrammprodukt mit Programmcodemitteln, die auf einem computerlesbaren Datenträger gespeichert sind, um alle Schritte eines Verfahrens nach Anspruch 11 durchzuführen, wenn das Computerprogramm auf einem Computer oder einer entsprechenden Recheneinheit ausgeführt wird.
PCT/EP2009/006332 2008-09-09 2009-09-02 Automatisierungssystem mit frameworkbasierter steuerung WO2010028760A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/058,918 US8676354B2 (en) 2008-09-09 2009-09-02 Automation system having framework based controller
EP09778258A EP2324399A1 (de) 2008-09-09 2009-09-02 Automatisierungssystem mit frameworkbasierter steuerung

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008047238A DE102008047238A1 (de) 2008-09-09 2008-09-09 Frameworkbasierte Steuerung für Automatisierungssysteme
DE102008047238.7 2008-09-09

Publications (1)

Publication Number Publication Date
WO2010028760A1 true WO2010028760A1 (de) 2010-03-18

Family

ID=41171023

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/006332 WO2010028760A1 (de) 2008-09-09 2009-09-02 Automatisierungssystem mit frameworkbasierter steuerung

Country Status (4)

Country Link
US (1) US8676354B2 (de)
EP (1) EP2324399A1 (de)
DE (1) DE102008047238A1 (de)
WO (1) WO2010028760A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2711794A1 (de) * 2012-09-25 2014-03-26 dSPACE digital signal processing and control engineering GmbH Verfahren zur zeitweiligen Separierung von Objektdaten von Entwurfsmodellen

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CA2797234A1 (en) * 2010-05-01 2011-11-10 Core Technology Limited Process execution components
DE102011089014A1 (de) * 2011-01-19 2012-07-19 Dr. Johannes Heidenhain Gmbh Numerische Steuerung
DE102013013184A1 (de) * 2013-08-08 2015-02-12 Audi Ag Kommunikationseinrichtung für ein Fahrzeug
EP3401744B1 (de) * 2017-05-12 2021-07-21 Tetra Laval Holdings & Finance S.A. Automatisierungsrahmen und verfahren zu seinem steuerung

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE19949558A1 (de) * 1999-10-14 2001-04-19 Heidenhain Gmbh Dr Johannes Steuerungsprogramm für eine numerische Werkzeugmaschine mit einer wiederverwendbaren Softwarestruktur
US6268853B1 (en) * 1999-09-30 2001-07-31 Rockwell Technologies, L.L.C. Data structure for use in enterprise controls
EP1182529A2 (de) * 2000-08-03 2002-02-27 Siemens Aktiengesellschaft Industrielle Steuerung auf der Basis Technologischer Objekte

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6556950B1 (en) * 1999-09-30 2003-04-29 Rockwell Automation Technologies, Inc. Diagnostic method and apparatus for use with enterprise control
DE10132036C2 (de) * 2001-07-03 2003-08-14 Siemens Ag Automatisierungssystem und Verfahren mit Funktionen in einer Auszeichnungssprache
DE10161064A1 (de) 2001-12-12 2003-07-03 Siemens Ag System und Verfahren zur Kommunikation zwischen Softwareapplikationen, insbesondere MES-Applikationen
DE10161140A1 (de) 2001-12-12 2003-07-03 Siemens Ag System und Verfahren zum Verfolgen und/oder Auswerten des Informationsaustausches
DE10342909A1 (de) * 2003-09-17 2005-04-21 Bosch Gmbh Robert Simulator für wenigstens ein Steuergerät-Software-Modul
US8024068B2 (en) * 2006-08-04 2011-09-20 Hurco Companies, Inc. Machine tool control system
US8407706B2 (en) * 2006-12-28 2013-03-26 Sap Ag Framework for parallel business object processing
US8341593B2 (en) * 2008-10-23 2012-12-25 Sap Ag Integrated development framework for composite applications

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6268853B1 (en) * 1999-09-30 2001-07-31 Rockwell Technologies, L.L.C. Data structure for use in enterprise controls
DE19949558A1 (de) * 1999-10-14 2001-04-19 Heidenhain Gmbh Dr Johannes Steuerungsprogramm für eine numerische Werkzeugmaschine mit einer wiederverwendbaren Softwarestruktur
EP1182529A2 (de) * 2000-08-03 2002-02-27 Siemens Aktiengesellschaft Industrielle Steuerung auf der Basis Technologischer Objekte

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
GEORG SÜSS: "Framework - Basis eines Automatisierungssystems", ETZ. ELEKTROTECHNISCHE ZEITSCHRIFT, vol. 119, no. 21, 1998, pages 22 - 25, XP001539579 *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2711794A1 (de) * 2012-09-25 2014-03-26 dSPACE digital signal processing and control engineering GmbH Verfahren zur zeitweiligen Separierung von Objektdaten von Entwurfsmodellen
US9600606B2 (en) 2012-09-25 2017-03-21 Dspace Digital Signal Processing And Control Engineering Gmbh Method for the temporary separation of object data of design models

Also Published As

Publication number Publication date
US8676354B2 (en) 2014-03-18
DE102008047238A1 (de) 2010-04-15
US20120022669A1 (en) 2012-01-26
EP2324399A1 (de) 2011-05-25

Similar Documents

Publication Publication Date Title
EP2422243B1 (de) Sicherheitssteuerung zum steuern einer automatisierten anlage und verfahren zum erstellen eines anwenderprogramms für eine sicherheitssteuerung
DE10335989B4 (de) Online-Änderungen von CIL-Code-Programmen für die Industrieautomatisierung
DE102009047025B3 (de) Echtzeit-Laufzeitsystem und Funktionsmodul für ein solches Laufzeitsystem
EP1184758A2 (de) Verfahren zum Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen, im Kontext der Flow Chart Programmierung
WO2013004389A1 (de) Verfahren und vorrichtung zur programmierung und konfigurierung einer speicherprogrammierbaren steuereinrichtung
DE19639424A1 (de) Entwurfsverfahren für die Anlagentechnik und rechnergestütztes Projektierungssystem zur Verwendung bei diesem Verfahren
EP2324399A1 (de) Automatisierungssystem mit frameworkbasierter steuerung
EP2407842B1 (de) Verfahren zur Inbetriebnahme von Maschinen oder Maschinen einer Maschinenserie und Projektierungssystem
EP1137972B1 (de) Automatisierungssystem zur lösung einer prozesstechnischen aufgabenstellung und verfahren hierzu
EP1634130B1 (de) Vorrichtung und verfahren zur programmierung und/oder ausführung von programmen für industrielle automatisierungssysteme
EP3807728A1 (de) Prozesssteuerungseinheit und verfahren zum interprozessualen austausch von prozessvariablen
EP1950635B1 (de) Verfahren zum Betrieb eines Automatisierungssystems
EP3812885A1 (de) Integrierte simulationscode- und produktionscodegenerierung
DE102018204952A1 (de) Testverfahren eines mechatronischen Systems
WO2003075156A2 (de) Verfahren zur generierung eines automatisierungsprogramms
EP2998805A1 (de) Verfahren und Vorrichtung zur Erzeugung eins Überwachungs-Funktionsbausteins für die Überwachung einer Automatisierungsanordnung
DE102004012315A1 (de) Verfahren zur automatischen Anpassung von Software
LU500646B1 (de) Technik zur Bereitstellung einer Diagnosefunktionalität für eine auf einer speicherprogrammierbaren Steuerung basierenden Anwendung
EP2787403A1 (de) Verfahren zum automatischen Erstellen eines Automatisierungsprogramms aus einer technologischen Beschreibung einer Automatisierungslösung
WO2001075535A2 (de) Zustandssteuerung von technischen systemen
EP1184760B1 (de) Verfahren zur Steuerung und/oder Regelung eines technischen Prozesses
DE10038439A1 (de) Verfahren zum Debuggen von Programmen für industrielle Steuerungen, insbesondere Bewegungssteuerungen, im Kontext der Flow Chart Programmierung
EP1393137B1 (de) Verfahren zum festlegen von automatisierten prozessen
DE102005008136A1 (de) Entwicklungssystem für Prozessleitsysteme sowie zugehöriges Verfahren und Computerprogrammprodukt
EP2085879A1 (de) Verfahren zum Betrieb eines Programmiergerätes, Computerprogramm zur Implementierung des Verfahrens und nach dem Verfahren arbeitendes Programmiergerät oder Programmiergeräte mit einem solchen Computerprogramm

Legal Events

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

Ref document number: 09778258

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2009778258

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13058918

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE