EP2250557A1 - Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente - Google Patents

Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente

Info

Publication number
EP2250557A1
EP2250557A1 EP09713697A EP09713697A EP2250557A1 EP 2250557 A1 EP2250557 A1 EP 2250557A1 EP 09713697 A EP09713697 A EP 09713697A EP 09713697 A EP09713697 A EP 09713697A EP 2250557 A1 EP2250557 A1 EP 2250557A1
Authority
EP
European Patent Office
Prior art keywords
mod
service
modules
event
oriented
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP09713697A
Other languages
English (en)
French (fr)
Inventor
Armando Walter Colombo
Joao Marco Mendes
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Schneider Electric Automation GmbH
Original Assignee
Schneider Electric Automation GmbH
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 Schneider Electric Automation GmbH filed Critical Schneider Electric Automation GmbH
Publication of EP2250557A1 publication Critical patent/EP2250557A1/de
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/54—Interprogram communication
    • G06F9/546—Message passing systems or structures, e.g. queues

Definitions

  • the invention relates to a method for controlling an interaction between modules such as communication module, control module, device-interface module of a service-oriented component, a service-oriented component such as an automation device and a software component.
  • IMS Intelligent Manufacturing Systems
  • SOA Service Oriented Architecture
  • service-oriented component Each participant in the system is referred to as a service-oriented component, and in some extensions as a service-oriented automation component, if the component has automatic controllers.
  • Components can have various tasks, such as Production, transport or monitoring and autonomous operation. As services take the lead, these components should have the ability to request services and, conversely, support the request for services from other members of the community. Services themselves are a way of providing resources and actions that may be shared, much like services in real life.
  • a set of equipment and other components of the system may under some circumstances be compared to a "living entity.”
  • a component its internal mechatronic Organizations are compared with functional organs that are responsible for specific tasks that provide "living" characteristics capable of meeting those requirements, a central question is how these functional modules or "organs" are integrated and controlled and are able to exchange events between them, thereby forming complex and effective structures.
  • Service-oriented systems are an approach to specify the environment for heterogeneous "organisms” that require interaction
  • Service business systems are known in the business world and electronic commerce in the field of industrial automation and production systems (especially regarding distributed devices) however, it is a relatively new field of research with promising prospects, and a major starting point was the EU research project SIRENA, which aimed to develop a service infrastructure for embedded real-time network applications.
  • Device Profile Forward Services (DPWS) designed to enable communication between resource-dependent embedded devices.
  • a single service-oriented control device should be ready for a variety of activities;
  • this requires a specially adapted internal frame structure or a programming framework, referred to below as a framework, which can handle the different and competing processes.
  • the object of the present invention is to further develop a method and a service-oriented component and a software component of the type mentioned at the outset in such a way that the interaction between modules is simplified in the case of different and competing processes.
  • the object is achieved according to the invention in that the interaction between the modules is event-based, wherein the event-based interaction between the modules and the synchronization of the modules is controlled via an event flow control module (Event Router Scheduler).
  • Event Router Scheduler Event Router Scheduler
  • an event sequence control module For the event-based connection and synchronization of functional modules in service-oriented components, devices and supporting applications, an event sequence control module is provided.
  • the application particularly relates to automation devices for production facilities and supporting software applications.
  • a service-oriented component is a modular structure composed of various functional modules, including the central event flow control and the required service-oriented communication module, which has the ability to communicate with other components. Because the component is a multi-threaded environment and requires data protection, there must be a mechanism for these tasks that provides each module with an interaction environment.
  • the invention ensures that the communication of automation control component modules takes place only in the case of events. This is useful for controlling the real-time synchronization of these modules and data overwrite protection.
  • each module becomes independent but complementary.
  • the approach allows the developers to program each module independently and to easily know how to process the received information.
  • the "heart" of the puzzle is the Event Router Scheduler module, which provides the following key features:
  • the event router scheduler provides an internal event-driven architecture framework that controls the flow of information for interconnected functional modules.
  • Each module can be programmed independently. This means that it is possible to remove, replace, upgrade (upgrade), add new modules, or just check how information is sent and read.
  • the event router scheduler can be applied and integrated into any software component based on the modular and functional architecture. Several areas of application are noted:
  • the present invention thus addresses an anatomy-like structure for the development of functional and reusable modules of a component as part of a service-oriented automation system.
  • the central focus is on its internal structure, and in particular on the mechanism that binds together the functional modules, referred to as Event Flow Schedulers or Event Router Schedulers.
  • the event flow control can be compared with the nervous system of a living being in the sense of transport / processing of pulses from and to different organs and thus to maintain the dynamic flow of information.
  • Intelligent behavior can be achieved by connecting these nerves to the "brain,” which provides static control based on "work-flow” processes and is also autonomous to respond to unforeseen events, undocumented situations, or internal objectives.
  • Incorporated into a service-oriented environment communication with other components can only be achieved by providing and requesting services to achieve local and global goals.
  • Figure 1 is a schematic representation of a service-oriented automation component of a service-oriented automation and production system.
  • FIG. 2 shows a schematic representation of a modular structure of a service-oriented component
  • FIG. 3 a schematic representation of the composition of a service-oriented component with event sequence control
  • FIG. 5a, b schematic representation of the reading of an event at "locked” module or "open” module
  • Fig. 6 is a schematic representation of a service-oriented component of a mechanical arm and its function.
  • FIG. 1 shows a schematic representation of a service-oriented component SOK and its integration into an automation and production environment of a production facility FS.
  • the illustrated component SOK represents a physical conveyor F and takes over the transport function (task: transport). Communication to the outside world is through services (service orientation) that are able to request or provide services as needed. Integration into the IT environment is also achieved via service orientation.
  • the component includes a set of functions (tasks: transport, monitoring, etc.) that can be used as services provided by the components.
  • service-oriented components may be considered software agents.
  • multi-agent systems are of particular interest as these systems evoke the idea of the collaborative agent community in which each of them can take autonomous actions about their environment or about the system they represent.
  • agent concepts unlike the agent concepts, the true meaning of service orientation is centered on the nature of providing services and the need to request services through a component in the system.
  • the real architecture, environment and objectives of the system are open to the user and thus the system can be adapted to different strategies to meet the requirements.
  • FIG. 2 shows the schematic structure of a component SOK in an anatomical form, comprising a plurality of "organs” (functional modules) responsible for individual tasks, as shown in FIG.
  • the event flow control EAS and the communication modules KOM-MOD are the "kernel" modules for developing a service-oriented component SOK based on the proposed anatomy, which are responsible for both the main framework of the Component (event-based inter-module interaction and integration) and external communication with other components (service-oriented inter-component communication)
  • Other modules MOD can be added to the structure according to the component requirements.
  • the communication module K0M-M0D provides the necessary functions to offer services from the associated components and to request services from other components. Other functions include, but is not limited to, discovery (discovery) and negotiation (negotiation) mechanisms.
  • the remaining modules of the component may use the communication module K0M-M0D to access these functions through pulses (events) provided by the event flow control module EAS-MOD.
  • a conveyor may provide the service "transfer” to effect the movement of pallets controlled by the logic controller module LC-MOD and invoked by the device interface module GI-MOD. Transfer "can be used by other components, but the component itself can also call external services when they are needed (eg for connection with other conveyor belts this calls the service "transfer" of another conveyor belt).
  • a suitable technological solution for implementing the service-oriented communication modules is the use of the web technology and in particular web services.
  • web service technology is quite simple and was developed to move XML (eXtended Markup Language) documents between service processes using standard Internet protocols. This simplicity helps web services achieve the higher goal of interoperability while also requiring the addition of other technologies to realize complex distributed applications.
  • DPWS Device Profiles for Web Service
  • the further modules MOD are briefly described in FIG.
  • the aim is to include the further modules to provide a service-oriented automation component SOK which is a "mediator" for any physical equipment with controllability
  • the resulting component SOK of Figure 2 represents a "smart controller" of the conveyor F, by providing several features such as control and access via the physical device, the ability to make decisions in unforeseen and undocumented situations, and also the possibility of service-oriented communication with other components.
  • a service-oriented PLC-like controller that can interpret control models (e.g., in IEC61131-3 languages) and give other commands necessary calls to these services provided.
  • device interface modules are not necessary because they do not directly instruct the devices.
  • the "nervous system" of the "anatomy” shown in Fig. 2 is managed by the event flow controller EAS (Event Router Scheduler).
  • Event Router Scheduler the event flow controller
  • Components and devices that implement several of the illustrated aspects of service orientation require a consistent anatomy to act on the various functional modules (organs) to meet the necessary requirements.
  • Other problems may arise from the asynchronously powered modules, possibly data inconsistencies and competing processes / threads.
  • a mechanism is proposed that provides an impulse (event) transfer and control feature to direct the "impulses" to different modules, thus enabling a synchronized interaction between them Event Flow Control Module (Event Router Scheduler) EAS-MOD.
  • the EAS-MOD fulfills the following goals:
  • EAS-MOD The function of EAS-MOD is comparable in some parameters to the nervous system of living things, including human beings.
  • the "environment" is detected by specific modules such as communication and device interface modules and mani- puliert.
  • the natural balance of impulses (events) of the individual modules and their integration is achieved with the aid of the event sequence control module EAS-MOD.
  • the event flow control EAS is an event handler for real-time modules SM, GIM, KM of the same application (see FIG. 3). It's like the central piece of a simple puzzle, with the puzzle pieces being the different software modules of the same program. For the most part, it is intended to handle communication between modules during other activity ("on the fly"), which means that each module can send and receive events from all others without the need for synchronization, information loss, data overwriting LC-MOD, GI-MOD To take care of KOM-MOD and other things.
  • component K is implemented in the corresponding device SOK, SOG or the software application after the necessary modules have been connected.
  • component K consists of two required modules, namely event flow control module (EAS) and communication module KOM-MOD, but also a device interface module capable of GI-MOD. To read information from the VO of the associated module or to write to the VO.
  • EAS event flow control module
  • KOM-MOD communication module
  • the main feature is the provision of an event-based interaction between the functional modules and the corresponding scheduling of events (see control and flow of events according to Fig. 4).
  • the internal pulses (events) of the component between its functional modules are managed internally by the event scheduler.
  • the event flow control allows synchronous and asynchronous event calls between all modules, which is very important for real-time applications. It also provides several additional methods for implementing more complex operations, such as events generated by other events and timed events.
  • a transmitter module only needs to send one event to a specific destination (another module), and this event scheduler routes it to its destination.
  • An event is a structure that contains all the information a module needs to identify different possible situations.
  • the structure may request a response for providing information or have an error message receiver, or an event receiver may check if it is a response. It can also be seen when an event has been sent more than once due to an error.
  • the event handler uses lists as means for transmitting and sorting events between the modules so that the number of events awaiting processing is limited only by the available memory.
  • the event flow control uses some techniques to avoid memory fragmentation, since data generation and deletion is a very common function in the modules. In some cases, when the number of events is high, the event flow control provides the opportunity to give the events different priorities. An event sent to a particular module will always be passed by all waiting events of that module which have a lower priority than the priority of the sent event.
  • the system is capable of performing both synchronous and asynchronous operations, with asynchronous operations being managed by threads.
  • the synchronous operations may be either “frozen” or “not frozen” for the recipient.
  • the operation may or may not be a "freeze module.”
  • the module will freeze until a new event arrives for that module. Subsequently, the module continues the normal process, as shown in Fig. 5a.
  • This is a process with very low CPU resource utilization, which is particularly suitable for embedded devices. However, it does not make sense for real-time multi-tasking modules because these types of modules should not be "frozen.”
  • the "non-solidified" event readers always receive an event. However, this can be an invalid event.
  • An invalid Event means that there are no events for the module so that it can continue working with other tasks. If it is a valid event, the module should continue with this. This is shown in Fig. 5b.
  • Asynchronous event triggering is also possible.
  • callbacks are used to execute this operation type because it must occur when it is called.
  • MUTEX Mutual Exclusion
  • Each module has a MUTEX for this case.
  • the remaining blocks according to FIG. 4 are responsible for adjacent tasks of the control (scheduling) and the routing of events, in particular for the management of the own module and the further modules.
  • the hardware / software abstraction allows system architecture functional transparency that can be accessed by all modules. Since the event flow control module and other modules are in a multi-functional and concurrent environment, a special EAS block TDK performs simple thread manipulation and data protection. The block is referred to as threading and data consistency block TDK.
  • the "Template / Interface for Event-based Modules" block provides T / I with a basis for creating functional modules and links them to the event flow control, each module can be independently programmed, which means that it is possible removing, exchanging, extending or adding new modules makes this very flexible, a program that uses EAS, the module ID, is the identification of the module and unique for each module, which must be known by the other modules sending an event to a specific module, which is similar to the code that the nerves carry to reach certain organs, but it is also possible to do a module based on it of its type such as "controller” or "user interface", since this way is much more convenient for a developer to achieve a module without much information.
  • Fig. 6 shows by way of example the service-oriented component of a mechanical arm and its operation.
  • the functions provided by the framework for developing and operating the component are shown.
  • the framework consists of the EAS and three modules, the logic controller LC-MOD, the device interface GI-MOD and the communication module KOM-MOD.
  • the invention provides a framework for the development of service-oriented automation systems, particularly suitable for the mechanism of transmission of events between different functional modules forming the component.
  • the adaptation of this "biologically inspired” modular structure allows the design and development of modules with unique and independent functions, but these are complementary to each other to enable the formation of complex, intelligent and “social” components.
  • the resulting component structure is characterized by a shortened development time and low integration effort into a system.
  • the invention discloses an anatomical structure for the development of functional and reusable modules of service-oriented automation components.
  • the central focus is on the internal structure and mechanism that connects the modules together and is called Event Router Scheduler.
  • the resulting software automation components are custom designed for various applications due to the inclusion and management of the specialized functional modules and provide the ability to operate in a service-oriented automation and production environment.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung bezieht sich auf ein Verfahren zur Steuerung einer Interaktion zwischen Modulen wie Kommunikations-Modul (KOM-MOD), Steuerungs-Modul (LC-MOD), Geräte-Interface-Modul (GI-MOD) einer service-orientierten Komponente (SOK). Um die Interaktion zwischen Modulen bei unterschiedlichen und konkurrierenden Prozessen zu vereinfachen, wird vorgeschlagen, dass die Interaktion zwischen den Modulen (KOM-MOD; LC-MOD; GI-MOD) ereignis-basierend erfolgt, wobei die Module (KOM-MOD; LC-MOD; GI-MOD) über ein Ereignis-Ablauf-Steuerungs-Modul (EAS-MOD) zur Bereitstellung einer Ereignis-Ablauf-Steuerung zur ereignis-basierten Verbindung und Synchronisation der Module (K0M-M0D; LC-MOD; GI-MOD) gekoppelt sind.

Description

Beschreibung
Verfahren zur Steuerung einer Interaktion zwischen Modulen einer service-orientierten Komponente sowie Service- orientierte Komponente
Die Erfindung bezieht sich auf ein Verfahren zur Steuerung einer Interaktion zwischen Modulen wie Kommunikations-Modul, Steuerungs-Modul, Geräte-Interface-Modul einer service-orientierten Komponente, eine service-orientierte Komponente wie Automatisierungsgerät sowie eine Softwarekomponente.
Produktions- und Automatisierungssysteme sind naturgemäß heterogen und bestehen aus unterschiedlichen Komponenten entsprechend ihren Aufgaben. Es ist daher vorhersehbar, dass die Spezifikationen solcher Systeme sich weg vom traditionellen zentral gesteuerten Ansatz hin zum verteilten korrespondierenden Ansatz entwickeln, welche sich den natürlichen Gegebenheiten und dem Layout des realen Systems anpassen.
Es ist somit vielversprechend, eine Ansammlung von verteilten, autonomen, intelligenten, fehler-toleranten und wieder verwendbaren Herstellungseinheiten zu haben, die als ein Set von kooperierenden Einheiten zusammenarbeiten. Jede Einheit ist fähig, dyna- misch mit jeder anderen zu interagieren, um sowohl lokale als auch globale Herstellungsziele zu erreichen, vom physikalischen Maschinen-Steuerungslevel in der Fertigungsstätte zu höheren Levels des Fabrik-Management-Systems. Diese neue Generation von Systemen werden als intelligente Herstellungs-Systeme (IMS; Intelligent Manufac- turing Systems) bezeichnet.
Eine der aufkommenden Lösungen, um die Vielzahl von Konzepten hinter IMS in brauchbare Prinzipien zu adaptieren, ist die Service- orientierte Architektur (SOA). Das Konzept SOA hat in wenigen Jahren große Bedeutung erlangt und wird ohne Zweifel einen großen Einfluss in vielen Technologiebereichen haben. Eine service-orientierte Architektur ist ein Set von architektonischen Theoremen zum Aufbau autonomer und interoperabler Systeme. Diese Annahme verdeutlicht eine der Herausforderungen von IMS, nämlich Bereitstellung von InterOperabilität zwischen autonomen Systemen.
Die Adaptierung des Service- orientierten Konzepts auf Automatisierungs- und Produk- tions-„Geschäfts-Systeme" in der Fertigungsstätte unter Beachtung der Prinzipien von IMS wird eine neue „Gemeinschaft" aus service-orientierten Automatisierungskomponenten erzeugen. Jeder Teilnehmer in dem System wird als service-orientierte Komponente bezeichnet, und in manchen Erweiterungen als service-orientierte Automatisierungskomponente, wenn die Komponente automatische Steuerungseinheiten aufweist. Komponenten können verschiedene Aufgaben haben wie z.B. Produktion, Transport oder Überwachung und autonom betrieben werden. Da Services die eigentliche Führung übernehmen, sollten diese Komponenten die Eigenschaft haben, Services anzufragen und umgekehrt die Anfrage von Services durch andere Teilnehmer der Gemeinschaft zu unterstützen. Services selbst sind eine Form der Bereitstellung von Resourcen und Aktionen, welche unter Umständen mitbenutzt werden, sehr ähnlich wie auch bei Services im realen Leben.
Bei der verteilten Automatisierung und insbesondere im Bereich von Produktionssystemen kann ein Set von Ausrüstungsgegenständen und weiteren Komponenten des Systems unter bestimmten Umständen mit einer Gemeinschaft „lebender Wesen" verglichen werden. Betrachtet man eine Komponente näher, kann ihre interne mechatronische Organisation mit funktionalen Organen verglichen werden, die für spezifische Aufgaben (Tasks) verantwortlich sind, welche „lebendige" Eigenschaften bereitstellen, die fähig sind, diese Anforderungen zu erfüllen. Eine zentrale Frage ist, wie diese funktionalen Module oder „Organe" integriert und gesteuert werden und imstande sind, Ereignisse zwischen ihnen auszutauschen und dadurch komplexe und wirkungsvolle Strukturen zu bilden.
Service-orientierte Systeme sind ein Ansatz, die Umgebung für heterogene „Organismen" zu spezifizieren, welche Interaktion benötigen. Service-Geschäftssysteme sind im Bereich der Geschäftswelt und des elektronischen Handels bekannt; im Bereich der industriellen Automations- und Produktionssystem (insbesondere betreffend verteilte Geräte) ist es jedoch ein relativ neues Forschungsgebiet mit aussichtsreichen Perspektiven. Ein bedeutender Ausgangspunkt war das EU-Forschungsprojekt SIRENA, dessen Ziel es war, eine Service-Infrastruktur für eingebettete Echtzeit-Netzwerkanwendungen zu entwickeln. Die Implementierung eines Service-Frameworks wurde in Übereinstimmung mit den „Device Profile Forward Services (DPWS)"-Spezifikationen entwickelt, um die Kommunikation zwischen ressource-abhängigen eingebetteten Geräten zu ermöglichen.
Ein wichtiger Punkt dieses Systems ist die Anordnung der Steuerung und wie deren Granularität und Verteilung beeinflusst wird. Seit der Einführung von üblichen programmierbaren Logikkontrollern (PLC; Programmable Logic Controller) wurden wesentliche Fortschritte in Forschung und Entwicklung gemacht mit dem Ziel, die Beschränkungen in Bezug auf die zentralisierte Verwendung von PLCs zu überwinden. Hierzu wurden Vorschläge unterbreitet aus den Bereichen Multi- Agenten-Systeme, Ho- lonik-Systeme und kürzlich auch service-orientierte Systeme.
Architekturen für Geräte und Steuerungs Software sind ebenfalls im Blickfeld der Forschung, üblicherweise unter Benutzung von ICE 61131-3 Sprachen, den IEC61499 Funktionsblöcken für verteilte Steuerung und Automation und andere Steuerungstechniken wie beispielsweise Petri-Netze. Für Service- orientiert verteilte Geräte ist das Steu- erung s verfahren teilweise offen für jeden Steuerungsansatz, sollte jedoch ebenfalls spezifische Anforderungen der Service-Orientierung berücksichtigen.
Durch Anbieten unterschiedlicher Funktionalitäten sollte ein einzelnes serviceorientiertes Steuerungsgerät für verschiedenartige Aktivitäten bereit sein; somit benötigt dieses eine speziell angepasste interne Rahmenstruktur oder ein Programmiergerüst, im Folgenden Framework genannt, welches die unterschiedlichen und konkurrierenden Prozesse handhaben kann.
Davon ausgehend liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Verfahren sowie eine service-orientierte Komponente und eine Softwarekomponente der eingangs genannten Art derart weiterzubilden, dass die Interaktion zwischen Modulen bei unterschiedlichen und konkurrierenden Prozessen vereinfacht wird.
Die Aufgabe wird erfindungsgemäß dadurch gelöst, dass die Interaktion zwischen den Modulen ereignis-basierend erfolgt, wobei die ereignis-basierte Interaktion zwischen den Modulen und die Synchronisation der Module über ein Ereignis-Ablauf- Steuerungs-Modul (Event Router-Scheduler) gesteuert wird.
Für die ereignis-basierte Verbindung und Synchronisation funktioneller Module in ser- vice- orientierten Komponenten, Geräten und unterstützenden Anwendungen wird ein Ereignis-Ablauf-Steuerungs-Modul zur Verfügung gestellt.
Dieses kann in modulare service-orientierte Komponenten, welche z.B. verteilte Automatisierungsgeräte unterstützen, integriert werden, und einen Framework für die Kommunikation zwischen den funktionellen Modulen, welche die Komponente bilden, bereitstellen. Die Anwendung bezieht sich insbesondere auf Automatisierungsgeräte für Fertigungs statten und unterstützende Software- Anwendungen.
Eine service-orientierte Komponente ist eine modulare Struktur, die sich aus verschiedenen funktionalen Modulen zusammensetzt, einschließlich der zentralen Ereignis- Ablauf-Steuerung und des benötigten service-orientierten Kommunikationsmoduls, welches die Fähigkeit besitzt, die Kommunikation mit anderen Komponenten zu ermöglichen. Da die Komponente eine multi-threading-fähige Umgebung ist und Datenschutz benötigt, muss für diese Aufgaben ein Mechanismus vorhanden sein, der den einzelnen Modulen eine Interaktionsumgebung bietet.
Durch die Erfindung wird erreicht, dass die Kommunikation von Automatisierungssteu- erungs-Komponentenmodulen nur bei Ereignissen erfolgt. Dies ist hilfreich, um die Echtzeitsynchronisation dieser Module und den Datenüberschreibschutz zu steuern. Somit wird jedes Modul unabhängig, aber komplementär. Der Ansatz gestattet den Entwicklern, jedes Modul unabhängig zu programmieren und auf einfache Weise zu wissen, wie die empfangene Information zu verarbeiten ist.
Wird die Steuerungskomponente aus mehreren Modulen gebildet, die asynchron agieren und verschiedene Prozesse und/oder Threads verwenden können, wird ein spezielles Modul benötigt, um alle Module miteinander zu verbinden und Datennebenläufigkeit (data concurrency) zu wahren. Zu diesem Zweck ist das „Herz" des Puzzles das Ereignis-Ablauf-Steuerungs-Modul (Event-Router-Scheduler-Modul), das die folgenden Hauptmerkmale zur Verfügung stellt:
> Gestattet Ereignisübertragung zwischen jedem Modul, was es einem komplexen Interaktions-Mechanismus ermöglicht, einfache Basisfunktionen zu benutzen;
> Gemeinsamer Ereignis-Ablauf-Steuerungsmechanismus für integrierte funktionale Module;
> Priorisierte Puffer für Ereignisse bei Auftreten von hohem Ereignisaufkommen;
> Thread-Management und Datenschutzeinrichtungen;
> Allgemeines Interface, um verschiedene Modultypen anzuschließen. Echtzeitanwendungen werden von Tag zu Tag komplexer. Speziell Anwendungen von Maschinensteuerungen werden zur Handhabung elektronischer Komponenten geschaffen, um Informationen an einen Supervisor-Rechner wie Personal-Computer zu senden, um mit anderen Steuerungen zu kommunizieren und so weiter. Die Verarbeitung des gesamten Informationsflusses kann sehr komplex sein; zudem sollen in der industriellen Automatisierung Fehler, langjährige Entwicklungen oder häufige Maschinenumpro- grammierung vermieden werden.
Durch die Anwendung werden folgende Vorteile erreicht:
Die Ereignis-Ablauf-Steuerung (Event-Router-Scheduler) stellt einen internen eventgesteuerten Architekturrahmen zur Verfügung, durch den der Informations- fluss für miteinander verbundene funktionale Module gesteuert wird.
Einfachere funktionale Moduldefinition/-trennung und Integration in die Komponente durch Verwendung der zentralen Ereignis-Ablauf-Steuerung (Event-Router- Scheduler).
Jedes Modul kann unabhängig programmiert werden. Das bedeutet, dass es möglich ist, Module zu entfernen, zu ersetzen, nachzurüsten (Upgrade), neue hinzuzufügen oder nur zu prüfen, wie Informationen gesendet und gelesen werden.
Support für individuell gefertigte funktionale Module zu jedem Zweck.
Die Ereignis-Ablauf-Steuerung (Event-Router-Scheduler) kann in jeder Softwarekomponente angewandt und integriert werden, die auf der modularen und funktionalen Architektur basiert. Auf mehrere Anwendungsgebiete wird hingewiesen:
> Funktionale Struktur für service-orientierte integrierte Geräte.
> Entwicklungstools, die den Zugriff auf service-orientierte Geräte automatisieren und deren interne Architektur diese Konzepte einschließt. > Entwicklung virtueller Softwarekomponente zur Umgebungssimulation.
> Überwachung von Tools und Komponenten, die Informationen von anderen Komponenten sammeln.
> Unterstützung der Entwicklung von Software-Agenten und Multi-Agenten- Sy stemen.
Die vorliegende Erfindung befasst sich folglich mit einer anatomieähnlichen Struktur für die Entwicklung von funktionalen und wieder verwendbaren Modulen einer Komponente als Teil eines Service- orientierten Automations Systems. Der zentrale Blickpunkt ist auf deren interne Struktur und insbesondere auf den Mechanismus gerichtet, der die funktionalen Module zusammenbindet, welcher als Ereignis-Ablauf-Steuerung oder Event Router-Scheduler bezeichnet wird. Die Ereignis-Ablauf-Steuerung kann verglichen werden mit dem Nervensystem eines Lebewesens im Sinne von Transport/Abwicklung von Impulsen von und zu unterschiedlichen Organen und somit zur Aufrechterhaltung des dynamischen Informationsflusses. Intelligentes Verhalten kann erreicht werden, wenn diese Nerven mit dem „Gehirn" verbunden werden, welches statische Steuerung, basierend auf „Work-Flow" Prozessen, bereitstellt und ebenfalls autonom ist, um auf unvorhergesehene Ereignisse, undokumentierte Situationen oder interne Zielsetzungen zu reagieren. Eingebunden in eine Service- orientierte Umgebung kann eine Kommunikation mit anderen Komponenten nur durch Zurverfügungstellung und Anfrage von Services erreicht werden, um lokale und globale Zielsetzungen zu erreichen.
Weitere Einzelheiten, Vorteile und Merkmale der Erfindung ergeben sich nicht nur aus den Ansprüchen, den diesen zu entnehmenden Merkmalen - für sich und/oder in Kombination -, sondern auch aus der nachfolgenden Beschreibung von den Zeichnungen zu entnehmenden bevorzugten Ausführungsbeispielen.
Es zeigen: Fig. 1 eine schematische Darstellung einer service-orientierten Automatisierungskomponente eines service-orientierten Automatisierungs- und Produktionssystems;
Fig. 2 schematische Darstellung einer modularen Struktur einer service- orientierten Komponente;
Fig. 3 schematische Darstellung der Zusammensetzung einer service- orientierten Komponente mit Ereignis-Ablauf-Steuerung;
Fig. 4 verschiedene Typen des Sendens von Ereignis-Nachrichten durch ein
Modul über die Ereignis-Ablauf-Steuerung;
Fig. 5a, b schematische Darstellung des Lesens eines Ereignisses bei „gesperrtem" Modul bzw. „offenem" Modul;
Fig. 6 schematische Darstellung einer service-orientierten Komponente eines mechanischen Arms und dessen Funktion.
Fig. 1 zeigt eine schematische Darstellung einer service-orientierten Komponente SOK und deren Integration in eine Automations- und Produktionsumgebung einer Fertigungsstätte FS. Die dargestellte Komponente SOK stellt einen physikalischen Förderer F dar und übernimmt die Transportfunktion (Aufgabe: Beförderung). Die Kommunikation zur Außenwelt erfolgt über Services (Service-Orientierung), die imstande sind, Services bei Bedarf anzufragen oder zur Verfügung zu stellen. Die Integration in die IT- Umgebung wird ebenfalls über Service-Orientierung erreicht. Die Komponente umfasst ein Set von Funktionen (Tasks) (Tasks: Transport, Überwachung etc.), die als Services, welche von den Komponenten zur Verfügung gestellt werden, benutzt werden können.
Eine Interaktion zwischen den Komponenten erfolgt nach dem Zwei- Wege-Prinzip im Sinne von Anfrage des Service und Bereitstellung des Services. Es wird erwartet, dass in der Produktion und Automatisierung heterogene Komponenten zusammenarbeiten zum gegenseitigen Vorteil und dem Erreichen der globalen Zielsetzung. Dies kann als „Symbiose" bezeichnet werden, ähnlich zu den Interaktionen zwischen verschiedenen biologischen Arten (Spezies), wobei jedoch letztlich das globale Ziel beachtet werden muss.
In einigen Situationen können service-orientierte Komponenten als Software-Agenten angesehen werden.
Darüber hinaus sind Multi-Agenten-Systeme von besonderem Interesse, da diese Systeme die Idee der kollaborativen Agentengemeinschaft hervorbringen, in welcher jeder von ihnen autonome Aktionen über ihre Umgebung oder über das System, welches sie repräsentieren, übernehmen kann. Auf der anderen Seite und im Gegensatz zu den Agentenkonzepten zentriert sich der wahre Sinn der Service-Orientierung in der Eigenschaft des Anbietens von Services und in der Notwendigkeit der Anfrage von Services durch eine Komponente in dem System. Die wirkliche Architektur, Umgebung und Zielsetzungen des Systems sind für den Anwender offen und somit kann das System an unterschiedliche Strategien zum Erreichen der Anforderungen angepasst werden.
Die Spezifikation einer internen Anatomie von Komponenten, welche deren Entwicklung vereinfacht, bleibt noch offen. Da service-orientierte Komponenten unterschiedliche und manchmal konkurrierende Aktivitäten ausführen können, kann es aber hilfreich sein, eine funktionale und unabhängige Struktur in Betracht zu ziehen zugunsten der Wiederverwendbarkeit und einfachen Entwicklung.
Jede service-orientierte Komponente SOK kann unabhängig und unterschiedlich implementiert werden. Die einzige Anforderung ist, dass die Komponente ihre Funktionen als Services S anbietet und Kommunikationsprotokoll und Verfahren zu befolgen sind. Um imstande zu sein, diese Komponenten in einer einfachen, jedoch funktionalen Weise zu konstruieren und zu entfalten, wird ein „Framework" ähnlich einer Anatomie vorgeschlagen. Fig. 2 zeigt die schematische Struktur einer Komponente SOK in einer anatomischen Form, mehrere „Organe" (funktionale Module) umfassend, die für individuelle Tasks verantwortlich sind, wie in Fig. 2 dargestellt: Logik-Controller LC-MOD, Entschei- dungs- und Ausnahme-Handler EAH-MOD, Kommunikation K-MOD, Geräte-Interface GI-MOD und Ereignis-Ablauf-Steuerung (Event-Router-Scheduler) EAS-MOD. Diese Module sind in der Steuerungskomponente SOK entsprechend Ihres Bedarfs enthalten und unter Verwendung verschiedener Technologien möglicherweise implementiert. Es ist ebenfalls möglich, andere Module MOD für diverse Funktionalitäten zu entwickeln und zu integrieren, wenn diese die Regeln, welche von dem „Framework" für die Integration (Aufgaben des Event-Router-Schedulers) respektiert werden.
Die Ereignis-Ablauf-Steuerung EAS und die Kommunikations-Module KOM-MOD sind die „Kernel"-Module, um eine service-orientierte Komponente SOK basierend auf der vorgeschlagenen Anatomie zu entwickeln. Diese sind verantwortlich, sowohl einerseits für den Haupt-Framework der Komponente (ereignis-basierte Inter-Modul- Interaktion und Integration) und externe Kommunikation mit anderen Komponenten (service-orientierte Inter- Komponenten-Kommunikation). Weitere Module MOD können zu der Struktur gemäß den Komponentenanforderungen hinzugefügt werden.
Genauer gesagt stellt das Kommunikations-Modul K0M-M0D die notwendigen Funktionen zur Verfügung, um Services von den assoziierten Komponenten anzubieten und Services von anderen Komponenten anzufragen. Andere Funktionen schließen u.a. Auf- findungs- (Discovery) und Verhandlungs- (Negotiation) Mechanismen ein. Die verbleibenden Module der Komponente können das Kommunikations-Modul K0M-M0D benutzen zum Zugriff auf diese Funktionen durch Impulse (Ereignisse), welche durch das Ereignis-Ablauf-Steuerungs-Modul EAS-MOD bereitgestellt werden. Als Beispiel kann ein Förderband den Service „Transfer" bereitstellen, um die Bewegung von Paletten zu bewirken, welcher durch das Logik-Controller-Modul LC-MOD gesteuert wird und durch das Geräte-Interface-Modul GI-MOD aufgerufen wird. Der Service "Transfer" kann von anderen Komponenten benutzt werden, jedoch kann die Komponente selbst ebenfalls externe Services aufrufen, wenn diese benötigt werden (z.B. zur Verbindung mit anderen Förderbändern ruft diese den Service „Transfer" eines anderen Förderbands auf).
Eine geeignete technologische Lösung zur Implementierung der service-orientierten Kommunikationsmodule ist die Verwendung der Web-Technologie und insbesondere Web-Services. Im Grunde ist die Web-Service-Technologie recht einfach und wurde entwickelt, um XML (eXtended Markup Language) Dokumente zwischen Service- Prozessen zu bewegen, welche Standard-Internetprotokolle benutzen. Diese Einfachheit verhilft Web-Services, das höhere Ziel der InterOperabilität zu erreichen und bedeutet gleichzeitig, dass es notwendig ist, andere Technologien hinzuzufügen, um komplexe verteilte Anwendungen zu realisieren. Es wurde ein Profil spezifiziert, um Web- Services auf Geräte-Level zu adaptieren, welches als „Device Profile for Web-Service (DPWS)" bekannt ist.
Die weiteren Module MOD sind in Fig. 2 kurz beschrieben. Ziel ist es, die weiteren Module einzuschließen, um eine service-orientierten Automatisierungskomponente SOK bereitzustellen, welche „Mittler" für beliebiges physikalisches Equipment mit Steuerungsfähigkeit ist. Zum Beispiel repräsentiert die resultierende Komponente SOK gemäß Fig. 2 einen „Smart Controller" des Förderbandgeräts F, durch Bereitstellung mehrerer Eigenschaften wie beispielsweise Steuerung und Zugriff über das physikalische Gerät, die Fähigkeit zur Entscheidung in unvorhergesehen und undokumentierten Situationen und ebenfalls die Möglichkeit der service-orientierten Kommunikation mit anderen Komponenten. Ein weiteres Beispiel ist ein service-orientierter PLC-ähnlicher Controller, welcher Steuerungsmodelle (z.B. in IEC61131-3 Sprachen) interpretieren kann und anderen Komponenten über den Aufruf von diesen bereitgestellten Services notwendige Befehle erteilt. In diesem Fall sind Geräte-Interface-Module nicht notwendig, da diese nicht direkt die Geräte anweisen.
Schließlich wird das „Nervensystem" der in Fig. 2 dargestellten „Anatomie" durch die Ereignis-Ablauf-Steuerung EAS (Event-Router-Scheduler) gemanagt. Diese wird nachfolgend genauer erläutert. Komponenten und Geräte, die mehrere der dargestellten Aspekte der Service- Orientierung implementieren, benötigen eine einheitliche Anatomie, um mit den verschiedenen Funktionsmodulen (Organen) zu handeln, um die notwendigen Anforderungen zu erfüllen. Andere Probleme können von den asynchron betriebenen Modulen herrühren, möglicherweise Dateninkonsistenzen und konkurrierende Prozesse/Threads. Für diesen Zweck wird ein Mechanismus vorgeschlagen, der ein Impuls (Ereignis) Übertra- gungs- und Steuerungs-Merkmal bereitstellt, um die „Impulse" zu verschiedenen Modulen zu leiten und somit eine synchronisierte Interaktion zwischen diesen zu ermöglichen. Das Herz dieser Komponente ist das Ereignis-Ablauf-Steuerungs-Modul (Event- Router-Scheduler) EAS-MOD.
Das EAS-MOD erfüllt die folgenden Ziele:
• gemeinsamer Ereignis-Ablauf/Steuerungs-Mechanismus für die Interaktion und Integration von Modulen;
• Bereitstellung einiger transparenter Funktionen zur Bildung und Führung von Modulen;
• geeignet für Softwareanwendungen, die sowohl für herkömmliche PCs als auch für eingebettete Systeme entwickelt wurden;
• hohe Leistungsfähigkeit, insbesondere in kritischen Situationen und Zielansprache „targeting" Echtzeitanwendung;
• Verwendung von z.B. C-Sprachen, mit dem Ziel des Ausgleichs zwischen Leistungsfähigkeit, Portabilität und Merkmalen;
• Handlungs Sicherheit und Management von Daten-Nebenläufigkeit;
• einfache Verwendbarkeit durch Entwickler im Sinne des Aufbaus von Modulen und wie Ereignisse ausgeführt werden.
Die Funktion des EAS-MOD ist in einigen Parametern vergleichbar mit dem Nervensystem von Lebewesen, einschließlich menschlicher Lebewesen.
Im Fall von service-orientierten Komponenten SOK wird die „Umwelt" durch spezifische Module wie z.B. Kommunikations- und Geräte-Interfacemodule erfasst und mani- puliert. Das natürliche Gleichgewicht von Impulsen (Ereignissen) der einzelnen Module und deren Integration wird mit Hilfe des Ereignis-Ablauf-Steuerungs-Moduls EAS- MOD erreicht.
Die Ereignis-Ablauf-Steuerung EAS ist ein Ereignis-Handler für in Echtzeit betriebene Module SM, GIM, KM derselben Anwendung (siehe Fig. 3). Es ist wie das zentrale Stück eines einfachen Puzzles, wobei die Puzzle- Teile die verschiedenen Softwaremodule desselben Programms sind. Größenteils wird beabsichtigt, die Kommunikation zwischen Modulen während anderer Aktivität („on the fly") zu handhaben; dies bedeutet, dass jedes Modul Ereignisse senden und von allen anderen empfangen kann ohne sich um Synchronisation, Informationsverlust, Datenüberschreibung LC-MOD, GI- MOD, KOM-MOD und anderes kümmern zu müssen.
Eine Komponente K wird in das entsprechende Gerät SOK, SOG oder die Softwareanwendung implementiert, nachdem die notwendigen Module verbunden wurden. In Fig. 3 besteht die Komponente K aus zwei benötigten Modulen, nämlich Ereignis-Ablauf- Steuerungs-Modul (EAS) und dem Kommunikations-Modul KOM-MOD, aber auch aus einem Geräte-Interface-Modul, das GI-MOD fähig ist, Informationen von dem VO des zugehörigen Moduls zu lesen bzw. an den VO zu schreiben.
Das Hauptmerkmal ist die Bereitstellung einer ereignis-basierten Interaktion zwischen den funktionalen Modulen und die entsprechende Ablauf-Steuerung von Ereignissen (siehe Steuerung und Ablauf von Ereignissen gem. Fig. 4). Vom praktischen Standpunkt aus betrachtet werden die internen Impulse (Ereignisse) der Komponente zwischen ihren funktionalen Modulen durch die Ereignis-Ablauf-Steuerung intern gemanagt. Die Ereignis-Ablauf-Steuerung erlaubt synchrone und asynchrone Ereignisaufrufe zwischen allen Modulen, was für Echtzeitanwendungen sehr wichtig ist. Ferner bietet diese mehrere zusätzliche Verfahren zur Realisierung komplexerer Abläufe, wie Ereignisse, welche durch andere Ereignisse und zeitgesteuerte Ereignisse erzeugt werden. In der einfachsten Form muss ein Sendermodul nur ein Ereignis zu einem spezifischen Ziel (anderes Modul) aussenden und diese Ereignis-Ablauf-Steuerung routet dieses zu seinem Ziel. Es existieren ebenfalls andere Optionen zum Senden und zur Verarbeitung von Ereignissen wie beispielsweise „Ereignis erwartet Rückantwort" und „Multicast" (Gruppenruf) eines Ereignisses zu mehreren Zielmodulen, wie in Fig. 4 dargestellt. Ein Ereignis ist eine Struktur mit allen Informationen, die ein Modul benötigt, um ver- schiedne mögliche Situationen zu erkennen. Neben der Standardinformation zur angeforderten Aktion und den zugehörigen Parametern kann die Struktur eine Rückantwort für die Bereitstellung einer Information anfragen oder einen Fehlernachrichtenreceiver aufweisen oder ein Ereignis-Empfänger kann überprüfen, ob es eine Rückantwort ist. Ebenfalls ist erkennbar, wenn ein Ereignis mehr als einmal aufgrund eines Fehlers gesendet wurde.
Die Ereignis-Ablauf-Steuerung verwendet Listen als Mittel zur Übertragung und Sortierung von Ereignissen zwischen den Modulen, so dass die Anzahl von Ereignissen, welche auf Verarbeitung warten, nur durch den verfügbaren Speicher begrenzt ist. Die Ereignis-Ablauf-Steuerung verwendet einige Techniken zur Vermeidung der Fragmentierung des Speichers, da die Generierung und Löschung von Daten eine sehr häufig verwendete Funktion in den Modulen ist. In manchen Fällen, wenn die Anzahl der Ereignisse hoch ist, bietet die Ereignis-Ablauf-Steuerung die Möglichkeit, den Ereignissen unterschiedliche Prioritäten zu geben. Ein zu einem bestimmten Modul gesendetes Ereignis wird immer von allen wartenden Ereignissen dieses Moduls durchgelassen, welche eine niedrigere Priorität haben als die Priorität des gesendeten Ereignisses.
Das System ist in der Lage, sowohl synchrone als auch asynchrone Operationen auszuführen, wobei asynchrone Operationen durch Threads gemanagt werden. Die synchronen Operationen können für den Empfänger entweder „erstarrt" (frozen) oder „nicht erstarrt" (non frozen) sein. Zum Beispiel kann beim Lesen des Ereignisses die Operation ein „Freeze Modul" sein oder nicht. Im Fall des „Freeze-Modus" erstarrt das Modul, bis ein neues Ereignis für dieses Modul ankommt. Anschließend führt das Modul das normale Verfahren fort, wie in Fig. 5a dargestellt. Dies ist ein Verfahren mit sehr geringer CPU Ressourcenauslastung, was insbesondere für eingebettete Geräte geeignet ist. Jedoch ist es nicht sinnvoll für Echtzeit- Multi-tasking-Module, da diese Art von Modulen nicht „erstarrt" werden soll. Andererseits empfangen die „nicht erstarrten" Ereignisleser immer ein Ereignis. Jedoch kann dies ein ungültiges Ereignis sein. Ein ungültiges Ereignis bedeutet, dass es keine Ereignisse für das Modul gibt, so dass es mit anderen Tasks weiterarbeiten kann. Wenn es ein gültiges Ereignis ist, sollte das Module mit diesen fortfahren. Das ist in Fig. 5b dargestellt.
Asynchrone Ereignis-Triggerung ist ebenfalls möglich. Hierbei werden Rückfragen (call backs) verwendet, um diesen Operationstyp auszuführen, da dieser auftreten muss, wenn dieser aufgerufen wird. Jedoch wird das Ereignis aufgrund von Datenschutz nicht unmittelbar getriggert, und es sollte nur auftreten, wenn das Modul einen MUTEX (Mutual Exclusion = wechselseitiger Ausschluss) aktiviert, um Rückrufe (call backs) zu erlauben, welche möglicherweise die Daten des Moduls ändern. Jedes Modul hat einen MUTEX für diesen Fall.
Die verbleibenden Blöcke gemäß Fig. 4 sind verantwortlich für angrenzende Tasks der Steuerung (Scheduling) und des Ablaufs (Routing) von Ereignissen, insbesondere für das Management des eigenen Moduls und der weiteren Module. Die Hardware / Softwareabstraktion erlaubt eine Funktionstransparenz der Systemarchitektur, auf die durch alle Module zugegriffen werden kann. Da das Ereignis-Ablauf-Steuerungs-Modul und andere Module sich in einer multi-funktionalen und konkurrierenden Umgebung befinden, führt ein spezieller Block TDK des EAS einfache Thread-Manipulation und Datenschutz durch. Der Block wird als Threading- und Daten-Konsistenz-Block TDK bezeichnet.
Schließlich stellt der Block „Template/Interface für ereignis-basierte Module" T/I eine Basis zur Erzeugung funktionaler Module zur Verfügung und verbindet diese zu der Ereignis-Ablauf-Steuerung. Jedes Modul kann unabhängig programmiert werden. Dies bedeutet, dass es möglich ist, dieses zu entfernen, auszutauschen, zu erweitern oder neue Module hinzuzufügen. Dadurch wird ein Programm, welches EAS nutzt, sehr flexibel. Die Modul-ID ist die Identifikation des Moduls und für jedes Modul eindeutig. Diese Variable müssen die weiteren Module kennen, um ein Ereignis zu einem spezifischen Modul zu senden. Dies ist vergleichbar mit dem Code, den die Nerven tragen, um bestimmte Organe zu erreichen. Jedoch ist es ebenfalls möglich, ein Modul aufgrund seines Typs wie „Controller" oder „User Interface" aufzusuchen, da dieser Weg für einen Entwickler viel praktischer ist, um ein Modul ohne viel Information zu erreichen.
Fig. 6 zeigt beispielhaft die service-orientierte Komponente eines mechanischen Arms und dessen Betriebsweise. Die durch das Framework bereitgestellten Funktionen zur Entwicklung und zum Betrieb der Komponente sind dargestellt. Das Framework besteht aus dem EAS und drei Modulen, dem Logik-Controller LC-MOD, Geräte-Interface GI- MOD sowie Kommunikations-Modul KOM-MOD.
Durch die Erfindung wird eine Rahmenstruktur bzw. ein Programmiergerüst (Framework) zur Entwicklung service-orientierter Automations Systeme bereitgestellt, insbesondere geeignet für den Mechanismus der Übertragung von Ereignissen zwischen unterschiedlichen funktionalen Modulen, welche die Komponente bilden. Die Adaption dieser „biologisch inspirierten" modularen Struktur macht das Design und die Entwicklung von Modulen mit eindeutigen und unabhängigen Funktionen möglich. Diese sind jedoch komplementär zueinander, um die Bildung komplexer, intelligenter und „sozialer" Komponenten zu ermöglichen. Die resultierende Komponentenstruktur zeichnet sich durch eine verkürzte Entwicklungszeit und einen geringen Aufwand bei der Integration in ein System aus.
Zusammenfassend ist festzustellen, dass sich Automatisierungs- und Produktionssysteme zu autonomen und kollaborativen Komponenten entwickeln, welche die Idee von Geschäfts-Systemen anwenden. Ein einziges Mitglied dieses Systems ist verantwortlich für unterschiedliche und konkurrierende Aktivitäten und somit ist eine speziell ange- passte Analyse notwendig, welche die unterschiedlichen Anforderungen ausgleicht. Die Erfindung offenbart eine anatomische Struktur für die Entwicklung von funktionalen und wieder verwendbaren Modulen von service-orientierten Automatisierungskomponenten. Die zentrale Aufmerksamkeit liegt auf der internen Struktur und dem Mechanismus, der die Module miteinander verbindet und Event-Router-Scheduler genannt wird. Die resultierenden Softwareautomatisierungskomponenten werden benutzerspezifisch für verschiedene Anwendungen aufgrund des Einschlusses und Management der spezialisierten funktionalen Module ausgeprägt und bieten die Möglichkeit, in einer serviceorientierten Automations- und Produktionsumgebung zu arbeiten.

Claims

PatentansprücheVerfahren zur Steuerung einer Interaktion zwischen Modulen einer service-orientierten Komponente sowie Service- orientierte Komponente
1. Verfahren zur Steuerung einer Interaktion zwischen Modulen wie Kommunikations-Modul (KOM-MOD), Steuerungs-Modul (LC-MOD), Geräte-Interface- Modul (GI-MOD) einer service-orientierten Komponente (SOK), dadurch gekennzeichnet, dass die Interaktion zwischen den Modulen (KOM-MOD; LC-MOD; GI-MOD) ereignis-basierend erfolgt, wobei die Module (K0M-M0D; LC-MOD; GI-MOD) über ein Ereignis-Ablauf-Steuerungs-Modul (EAS-MOD) zur Bereitstellung einer Ereignis-Ablauf-Steuerung zur ereignis-basierten Verbindung und Synchronisation der Module (K0M-M0D; LC-MOD; GI-MOD) gekoppelt sind.
2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die ereignis-basierte Interaktion unabhängig von einer Synchronisation zwischen den Modulen (K0M-M0D; LC-MOD; GI-MOD) sowie unabhängig von Informationsverlust und Datenüberschreibung erfolgt.
3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Module (K0M-M0D; LC-MOD; GI-MOD) miteinander gekoppelt und anschließend in die service-orientierte Komponente (SOK) wie Automatisierungsgerät oder Software eingesetzt werden.
4. Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass die Ereignis-Nachrichten entsprechend ihrer Priorität in einem Speicher zwischengespeichert werden.
5. Service-orientierte Hard- und/oder Software-Komponente (SOK) wie Automatisierungsgerät oder Softwareanwendung mit modularer Struktur, umfassend zumindest ein service-orientiertes Kommunikations-Modul (KOM-MOD), ein Steuerungs-Modul (LC-MOD) sowie eine Geräte-Interface-Modul (GI-MOD), dadurch gekennzeichnet, dass die Service-orientierte Komponente (SOK) ein Ereignis-Ablauf-Steuerungs- Modul (EAS-MOD) aufweist, welches einen Framework zur Bereitstellung eines Ereignis-Ablauf-Steuerungsmechanismus zur ereignis-basierten Verbindung und Synchronisation der Module (KOM-MOD; LC-MOD; GI-MOD) aufweist.
6. Service-orientierte Komponente nach Anspruch 5, dadurch gekennzeichnet, dass die service-orientierte Komponente (SOK) Multi-threading-Fähigkeiten aufweist.
7. Service-orientierte Komponente nach Anspruch 5 oder 6, dadurch gekennzeichnet, dass die Module (K0M-M0D; LC-MOD; GI-MOD) Softwaremodule desselben Programms sind.
8. Service-orientierte Komponente nach einem der Ansprüche 5-7, dadurch gekennzeichnet, dass die service-orientierte Komponente (SOK) einen piroritäts-basierten Speicher für mit Priorität versehene Ereignis-Nachrichten aufweist.
9. Softwarekomponente mit einem Computerprogramm, das Softwaremittel zur Durchführung eines Verfahrens nach einem der Ansprüche 1 - 8 aufweist, wenn die Softwarekomponente in einem Automatisierungsgerät ausgeführt wird.
EP09713697A 2008-02-29 2009-02-27 Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente Withdrawn EP2250557A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008002785A DE102008002785A1 (de) 2008-02-29 2008-02-29 Event-Router-Scheduler-Modul für die eventbasierte Verbindung und Synchronisation funktioneller Module in serviceorientierten Komponenten, Geräten und unterstützenden Anwendungen
PCT/EP2009/052421 WO2009106638A1 (de) 2008-02-29 2009-02-27 Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente

Publications (1)

Publication Number Publication Date
EP2250557A1 true EP2250557A1 (de) 2010-11-17

Family

ID=40790894

Family Applications (1)

Application Number Title Priority Date Filing Date
EP09713697A Withdrawn EP2250557A1 (de) 2008-02-29 2009-02-27 Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente

Country Status (6)

Country Link
US (1) US20110055849A1 (de)
EP (1) EP2250557A1 (de)
JP (1) JP2011513822A (de)
CN (1) CN102265260B (de)
DE (1) DE102008002785A1 (de)
WO (1) WO2009106638A1 (de)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH705456A1 (de) * 2011-08-31 2013-03-15 Ferag Ag Computerisiertes Maschinensteuerungssystem.
JP7087402B2 (ja) 2018-01-19 2022-06-21 富士フイルムビジネスイノベーション株式会社 処理装置、処理システム、及びプログラム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6470386B1 (en) * 1997-09-26 2002-10-22 Worldcom, Inc. Integrated proxy interface for web based telecommunications management tools
US6691302B1 (en) * 2000-05-31 2004-02-10 Siemens Information & Communications Networks, Inc. Interfacing a service component to a native API
US7035944B2 (en) * 2001-09-19 2006-04-25 International Business Machines Corporation Programmatic management of software resources in a content framework environment
US20040177335A1 (en) * 2003-03-04 2004-09-09 International Business Machines Corporation Enterprise services application program development model
US7581205B1 (en) * 2003-09-30 2009-08-25 Nextaxiom Technology, Inc. System and method of implementing a customizable software platform
CN101208649B (zh) * 2005-04-25 2010-12-08 因文西斯系统公司 用于处理制造环境所引起的生产事件的系统和方法
JP4868799B2 (ja) * 2005-08-31 2012-02-01 キヤノン株式会社 サーバ装置及びイベント通知方法
CN100476649C (zh) * 2006-08-16 2009-04-08 中山大学 一种车载智能控制装置和方法
CN1975778A (zh) * 2006-11-03 2007-06-06 中山大学 一种数字家庭物品查找装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
EDWARD CURRY ED - ED : QUSAY H MAHMOUD: "CHAPTER 1: Message-Oriented Middleware", 1 January 2004, MIDDLEWARE FOR COMMUNICATIONS, JOHN WILEY & SONS, LTD, PAGE(S) 1 - 28, ISBN: 978-0-470-86206-3, XP007911233 *

Also Published As

Publication number Publication date
US20110055849A1 (en) 2011-03-03
JP2011513822A (ja) 2011-04-28
CN102265260B (zh) 2015-08-19
CN102265260A (zh) 2011-11-30
WO2009106638A1 (de) 2009-09-03
DE102008002785A1 (de) 2009-10-15

Similar Documents

Publication Publication Date Title
DE60038705T2 (de) Verfahren und vorrichtung für die aktivitäts-basierte zusammenarbeit eines rechnersystems, ausgestattet mit einem kommunikations-manager
DE112016006786T5 (de) Ressourcenorchestrierungsbrokerage für Internet-Der-Dinge-Netzwerke
WO2003050680A2 (de) System und verfahren zur kommunikation zwischen softwareapplikationen, insbesondere mes-applikationen
DE10206902A1 (de) Engineeringverfahren und Engineeringsystem für industrielle Automatisierungssysteme
DE102006051189A1 (de) Verfahren und System zum Ausführen und Konfigurieren von Applikationen abhängig von einer Einsatzumgebung
EP2342607A1 (de) Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system
EP2100198A1 (de) Steuerungssystem sowie verfahren zur konfiguration eines steuerungssystems
LU93299B1 (de) Ablaufsteuerung von Programmmodulen
WO2007012499A2 (de) Generische ki-architektur für ein multiagenten-system
WO2009101212A1 (de) Verfahren und system zur einbindung von service-orientierten automatisierungskomponenten einer fertigungsstätte in eine flexible it-unternehmensarchitektur
EP2250557A1 (de) Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente
WO2024046817A1 (de) Dds-fähiger controller
EP1442340A1 (de) Bereitstellung von informationen in einem automatisierungssystem
DE102006051188A1 (de) Flexibles Verschaltungssystem
Grolik et al. Dispositive Supply-Web-Koordination durch Multiagentensysteme
EP2090948B1 (de) Verfahren zum Betrieb eines Automatisierungssystems
DE112007002327T5 (de) Persistente Sperren auf Ressourcen zur Steuerung der Nebenläufigkeit
DE102004011201A1 (de) Verfahren zum Management und zur Überwachung des Betriebs mehrerer in wenigstens ein Kommunikationsnetz eingebundener verteilter Hard- und/oder Softwaresysteme sowie System zur Durchführung des Verfahrens
Mordinyi Managing complex and dynamic software systems with space-based computing
DE102016121542A1 (de) Ablaufsteuerung von Programmmodulen
Kenzler et al. Segment Routing v6 (SRv6) Network Programming
DE60308325T2 (de) Informationswegeleitung
DE102019203874A1 (de) Verfahren und Vorrichtungen für eine Lastzuweisung und Überwachung für eine zuzuweisende versorgungssicherheitskritische Ressource in einem Netzwerk
EP4390581A1 (de) Verfahren und engineeringsystem zur projektierung und programmierung einer industriellen automatisierungsanordnung mit einer anzahl automatisierungskomponenten
DE3301282A1 (de) Verfahren und vorrichtung zur uebertragung von nachrichten zwischen automatisierungsmitteln

Legal Events

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

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20100922

AK Designated contracting states

Kind code of ref document: A1

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

AX Request for extension of the european patent

Extension state: AL BA RS

RIN1 Information on inventor provided before grant (corrected)

Inventor name: MENDES, JOAO MARCO

Inventor name: COLOMBO, ARMANDO WALTER

DAX Request for extension of the european patent (deleted)
17Q First examination report despatched

Effective date: 20141201

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

Free format text: STATUS: THE APPLICATION IS DEEMED TO BE WITHDRAWN

18D Application deemed to be withdrawn

Effective date: 20150414