WO2010043629A1 - Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system - Google Patents

Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system Download PDF

Info

Publication number
WO2010043629A1
WO2010043629A1 PCT/EP2009/063366 EP2009063366W WO2010043629A1 WO 2010043629 A1 WO2010043629 A1 WO 2010043629A1 EP 2009063366 W EP2009063366 W EP 2009063366W WO 2010043629 A1 WO2010043629 A1 WO 2010043629A1
Authority
WO
WIPO (PCT)
Prior art keywords
services
agent
service
agents
software
Prior art date
Application number
PCT/EP2009/063366
Other languages
English (en)
French (fr)
Inventor
Armando Walter Colombo
Joao Marco Mendes
Paulo Leitao
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
Priority to US13/123,762 priority Critical patent/US20120029656A1/en
Priority to EP09752312A priority patent/EP2342607A1/de
Publication of WO2010043629A1 publication Critical patent/WO2010043629A1/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/418—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM]
    • G05B19/41845—Total factory control, i.e. centrally controlling a plurality of machines, e.g. direct or distributed numerical control [DNC], flexible manufacturing systems [FMS], integrated manufacturing systems [IMS] or computer integrated manufacturing [CIM] characterised by system universality, reconfigurability, modularity
    • 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/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5038—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering the execution order of a plurality of tasks, e.g. taking priority or time dependency constraints into consideration
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02P—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN THE PRODUCTION OR PROCESSING OF GOODS
    • Y02P90/00—Enabling technologies with a potential contribution to greenhouse gas [GHG] emissions mitigation
    • Y02P90/02—Total factory control, e.g. smart factories, flexible manufacturing systems [FMS] or integrated manufacturing systems [IMS]

Definitions

  • the invention relates to a method for developing a multi-agent system according to the preamble of claim 1 and to a multi-agent system according to the preamble of claim 2.
  • IAS In a publication by Prof. dr. Peter Göhner: "Agent Systems in Automation”; University of Stuttgart; 2005, IAS describes the structure of various automation systems, including agent-oriented automation systems, where agents fulfill automation functions, and agent-oriented automation systems free interaction of actions between agents, and the exchange of functional and behavioral information through abstract interactions. The nature of the interaction is not explained in detail in the article.
  • the agent defines a software unit with a defined goal, with autonomous behavior to reach the goal, with the ability to interact with an environment and other agents.
  • an agent includes an image of the relevant environment, defined goals, and capabilities.
  • agent-oriented programming languages such as Agent-O
  • conventional programming languages such as JADE or LS / TS.
  • agent frameworks / platforms such as JADE or LS / TS.
  • Agent frameworks and platforms are said to be implemented in traditional programming languages such as JAVA.
  • the agent frameworks and platforms provide agent generation tools, lifecycle management and persistence, libraries for various behavioral strategies, agent communication platforms such as languages such as ACL, Logs and agent interaction tools, such as directory services (yellow pages).
  • the invention relates to the field of distributed intelligent systems covering a significant range of application areas, such as telecommunications, industrial automation, manufacturing systems, and also vertical IT enterprise integration, from strategic business levels to device level.
  • the invention addresses the need to develop flexible and intelligent systems that support the requirements for modularity, reconfigurability, reusability, distribution, and heterogeneity.
  • SOA Service Oriented Architecture
  • Interoperability or full compatibility is facilitated by a clear abstraction of the interface or communication interface, which presents a service to its environment through the implementation of the service.
  • Basic interaction patterns of a device level SOA can be described by means of five functional levels: addressing, finding, writing, control, event.
  • Devices are characterized as either controlling or controlled devices, but a given device can embody both roles and enable "peer-to-peer” interactions, as well as device-level service-oriented protocols, such as UPnP (Universal Plug and Play).
  • UPnP Universal Plug and Play
  • DPWS Device Profiles for Web Services
  • DPWS The DPWS specifications define an architecture in which devices have two types of services: hosting services and hosted services. “Hosted Services” are mostly functionally dependent on their “hosting” device for discovery, and in addition to hosted services, DPWS specifies a set of built-in services:
  • Discovery Services Used by a device that connects to a network to spread the word and discover other devices.
  • Methoda Data Exchange Services Provides dynamic access to a hosted service of the device and its metadata, such as WSDL or XML schema definitions.
  • a "controlled” device is simply referred to as a “device,” while a “controlling” device is referred to as a "client.”
  • a DPWS protocol stack has the following structure:
  • WSDL Web Services Discription Language
  • SOAP the protocol for transporting service-related messages formatted in accordance with their corresponding WSDL definitions
  • WS-Addressing is tightly connected to the SOAP and concentrates all addressing information into the header of the SOAP message wrapper, allowing the message content to be transmitted over any transport protocol (HTTP, SMTP, TCP, UDP, ...)
  • WS-Policy is used to express rules in connection with the Web Service in the form of "Policy Assertions”, which complete the WSDL description of the service "WS-Metadata Exchange” allows the dynamic retrieval of metadata associated with the web service (description, schema and policy), thus providing a web service self-checking mechanism
  • WS-Security is an optional set of mechanisms for securing end-to-end message integrity, confidentiality, and authenticity.
  • DPWS protocol stack integrates all the standards presented above.
  • DPWS Web Service complements "Discovery” and "Preventing" protocols. For example
  • WS-Discovery is a protocol for "plug-and-play" discovery of network-connected resources. It defines a multicast protocol for searching for and finding devices. Once found, the device shows the services it provides.
  • WS-Eventing defines a "publish-subscribe" event-handling protocol that allows a web service to exchange event-related messages with other web services.
  • WS-Eventing is intended to implement a range of applications, from device-oriented to enterprise-scaled-published-subscribed systems, in the upper part of the same substrate.
  • each DPWS-based service has a specific WSDL description. This description is device specific; Thus, different device types have different WSDL descriptions with few similarities.
  • the DPWS service code relies on various functions to handle messages. These functions depend on the DPWS description of a particular service. For one service to communicate with another in this context, both services must implement each other's specific functions. Therefore, every WDSL Description Each time a new service has been designed, compiled to generate a server code and a client code.
  • the object of the present invention is to refine a method for developing a multi-agent system and a multi-agent system such that software agents can be used independently of the technology, thereby improving the modularity, reconfigurability and interoperability in heterogeneous environments ,
  • the object is achieved according fiction, by a method with the features of claim 1 and by a service-oriented multi-agent system with the features of claim 2.
  • Multi-agent systems MAS
  • SoA service-oriented architectures
  • MAS Multi-agent systems
  • SoA service-oriented architectures
  • the present invention specifies a technology-independent method for developing multi-agent systems, which is guided by service orientation and used to manage and solve heterogeneous and concurrent automation and production schedules and problems.
  • the idea introduces a new approach to develop modular, pluggable, flexible and reconfigurable systems, especially for industrial automation and manufacturing systems, based on the concept of multi-agent systems (MAS) and service-oriented architectures (SoA).
  • MAS multi-agent systems
  • SoA service-oriented architectures
  • the approach is characterized by the use of a set of distributed autonomous and cooperative entities, the agents, using SoA principles that allow for increased modularity, reconfigurability, and interoperability in heterogeneous environments.
  • SoMAS service-oriented multi-agent systems
  • the idea describes a method for developing a multi-agent system oriented to offering and requesting services to meet industrial and production goals.
  • the approach differs from traditional multi-agent systems in the form of:
  • Agents are service-oriented: individual goals of agents can be complemented by services provided by others. Internal properties of agents can be offered as services for others to call.
  • a key feature is the reusability of services of an agent that is not only used and applied to a single problem type for which it was developed can be reused but also for different applications.
  • the idea represents a reference model in which communication and development technology is open.
  • any suitable technology can be used to develop the concepts presented by the reference model.
  • web service technologies can be adapted for resource access via services, and C ++ or Java languages can be used to develop the agents.
  • the idea is formulated in a reference model that provides the general foundations for specifying a service-oriented multi-agent system for solving problems and achieving goals in industrial automation and production.
  • the aim of the patent proposal is to provide a new approach to the development of distributed, intelligent systems that present modularity, flexibility, reconfigurability and interoperability capabilities, combined with the best features of MAS and SoA paradigms.
  • Transparency as agents can be developed using a variety of methods and technologies, as interaction patterns are defined and common standards.
  • Fig. 4 Composition of modules for forming types of
  • FIG. 1 An underlying model of the invention is shown in Fig. 1, which is explained below:
  • Modular / V granted, Service-based The system includes software and hardware components.
  • Software components are generally agents with specified functions (tasks) and can also represent / control hardware components. Resources and functions of agents and other software components are represented as services.
  • Service-oriented software agents A software agent is a unit that acts for a user or a device and has the ability to solve its own goals.
  • a software agent is a unit that acts for a user or a device and has the ability to solve its own goals.
  • Several additional concepts include the degree of autonomy of agents, as well as their learning and intelligence abilities.
  • a multi-agent system is used when complex objectives are created from separated individual problems that can be resolved by individual agents and their collaboration, reducing the complexity of the entire problem.
  • the introduced extension requires a service-oriented approach to the agents. In this case, the agents are guided by their own needs and motivation to solve their problems, but can also supplement their needs by calling services provided by other agents and also have the ability to provide community services.
  • FIG. 2 shows a schematic overview of service-oriented agents and service-oriented multi-agent systems.
  • each agent is internally independent and different (for example, by using different technology, for example different
  • Request / Deployment Services Problems and sub-issues are resolved by agents who should collaborate. Collaboration is achieved by providing services through agents (if they have the properties) and requesting them (if agents have needs).
  • Agents can understand what the information associated with services and other elements is.
  • a conventional manufacturing scenario involves several system components that can be characterized as: production / conversion machinery, transport system, warehouse / depot and the product itself.
  • software agents would represent and act on the various elements in the system.
  • an agent exists for each specific production machine, transport module, and set of products.
  • An agent responsible for a production machine has the necessary characteristics to offer production services (for example filling a can) so that he will offer this type of service.
  • production services for example filling a can
  • An agent handling multiple products will be proactive in the sense of requesting transportation services (from the transport system) to be able to transfer products between different locations and also request production services provided by production machinery agents. This can be achieved by following a workflow of services that has been established for a production type.
  • a generic architecture for service-oriented automation components AK defines that an automation component is structured in a puzzle of pluggable and reusable modules ERS-MOD, COM-MOD, GI-MOD, LS-MOD, EAH-MOD, as shown in FIG each with its own function.
  • the main modules considered here are: logic controller LS-MOD, communication KOM-MOD, decision and exception handler EAH-MOD, device interface GI-MOD and event router scheduler ERS-MOD.
  • the logic control module LS-MOD which may also be referred to as an orchestration module, controls the behavior of the automation component through coordination in the sense of composition and orchestration of a set of services S according to their behavior described by a logical model.
  • the logic embedded in the automation component depends on the system topology, but it should be independent of the process plan of each product.
  • One possible approach to developing a logic controller eg, design, validation, simulation and execution may be for high-level Petri customized for service-oriented systems Using the advantages of its powerful mathematical foundation to represent discrete, dynamic and distributed systems. These logic controllers (orchestration machines) must interpret and execute the process model expressed in Petri nets.
  • logic control modules LS-MOD in more than one automation component allows the construction of a non-hierarchical architecture, meaning that the supervisory controller is actually distributed and not centrally coordinated.
  • the processes encapsulated by the coordination of services S must work together to achieve the same synchronization level as a centralized entity would provide.
  • the communication between the automation components AK is carried out via the integration of services S of the automation components which are contained in and provided by the communication modules KOM-MOD.
  • a conveyor may provide the transfer service to handle the movement of pallets that may be used by other automation components, but this may also call external services S when needed (eg, connected to another conveyor) to be, the request of the transfer service of another sponsor is necessary).
  • a suitable technological solution for implementing the service-oriented communication module KOMMOD is the use of web technology, and in particular web services.
  • the decision and exception handler module EAH-MOD provides real-time decision making and conflict resolution services to assist in coordinating the execution of the services S since the logic model of the system does not describe a fixed sequence of actions, but instead its all possible combinations of these. For example, if a system is flexible due to the redundancy of service providers, the concrete mapping of services to devices must be decided in real time.
  • the degree of complexity associated with the Decision-making mechanism can range from simple algorithms to complex computed systems, such as multi-agent systems, expert systems, neural networks and genetic algorithms.
  • the device interface module GI-MOD provides the mechanisms for the integration of physical devices such as robots or sensors, within the control part of the automation component. Since local device controllers typically have closed architectures, it is necessary to develop envelopes to hide the details of each device controller and provide primitives that represent the functionality of the physical device. The purpose of the GI-MOD device interface module is to accomplish these tasks by providing mechanisms to support the simple and transparent integration of physical devices within the control applications.
  • event router scheduler module ERS-MOD acts as a coordinator for the various asynchronous and competing component modules.
  • each automation component of the architecture can be independently and differently implemented.
  • the only requirement is that the automation component should share its functions as services and follow the communication protocols and processes. This flexibility can contribute to the development of custom components for diversified applications.
  • the generic modular structure for the service-oriented automation components can be used to implement different types of automation components that participate in the control, namely the mechatronic components MeC, process control components PCC and intelligent support components ISC, as shown in FIG.
  • the development of automation components AK is achieved by defining the set of kernel modules KER-MOD such.
  • the MeC component includes the mechanical, electronic and software combination that allows local control of the physical device.
  • the logic control module LS-MOD may also be embedded to control its local behavior in cases when the atomic operation decomposition is possible and the device interface module GI-MOD then synchronizes the services provided by the physical device, such as read inputs, write outputs, or program invocation.
  • the MeC component can also have its own embedded intelligence.
  • the component is called the smart mechatronics component SMeC.
  • the component SMeC can also represent composite automation components, in the sense that an automation component is an aggregation of several other automation components such.
  • B a transport system, which is constructed of individual conveyor units.
  • the structure of this type of automation component also includes the decision and exception handler module EAH-MOD, which provides local decision support to the logic control mechanism in the case of decision needs or conflict resolution.
  • EAH-MOD exception handler module
  • Other application examples of the generic structure for service-oriented automation components AK are the development of process control components PCC. In more complex systems built from small mechatronic automation components, it is necessary to have automation components that are global
  • the components PCC which have their own logic control, provide these types of mechanisms and act as clients capable of utilizing services provided by other automation components.
  • the component PCC supports the complex process flow and interaction of services in the system, according to a process model. For this application, they implement the logic for work-flow-oriented execution and sequencing of atomic services, and provide a high-level interface for the aggregated process, which is composed of individual subprocesses.
  • a robot may provide a transport service that includes various operations, such as grabbing, moving, and placing. It can synchronize its activities with its connected neighbors and, if necessary, take commands from global components.
  • the structure of this type of automation components includes the communication module KOM-MOD, event router scheduler module ERS-MOD, logic control module LS-MOD, and the decision s and exception handler modules EAH-MOD. Because these types of components do not require access to physical hardware, the GI-MOD device interface module is not included in this structure.
  • the idea will provide a common and generic structure for service-oriented automation components that will support simple and rapid development of flexible and reconfigurable production systems.
  • modules that can be reused for different applications.
  • the modules can be developed independently because they have implemented the necessary interfaces for inter-module communication;

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Manufacturing & Machinery (AREA)
  • Quality & Reliability (AREA)
  • Automation & Control Theory (AREA)
  • Stored Programmes (AREA)

Abstract

Die Erfindung bezieht sich auf Verfahren zur Entwicklung eines Multi-Agenten-Systems sowie auf ein Multi-Agenten-System, wie Automations- und/oder Produktionssystem, umfassend Software- und/oder Hardwarekomponenten, deren Ressourcen und Funktionen durch Software-Agenten repräsentiert und/oder gesteuert werden, wobei jeder Software-Agent die Fähigkeit hat, definierte Ziele durch Interaktion mit der Umgebung und anderen Agenten zu erreichen. Um die Rekonfigurierbarkeit und Flexibilität zu erhöhen ist vorgesehen, dass die Ressourcen und Funktionen der Software-Agenten als Services dargestellt werden, wobei jeder Software-Agent zur Erreichung seiner eigenen Ziele Services anderer Software-Agenten aufruft und seine eigenen Ressourcen und Funktionen anderen Software-Agenten als Service anbietet.

Description

Verfahren zur Entwicklung eines Multi-Agenten-Systems sowie Multi-Agenten-System
Die Erfindung bezieht sich auf ein Verfahren zur Entwicklung eines Multi-Agenten- Systems nach dem Oberbegriff des Anspruchs 1 sowie auf ein Multi-Agenten-System nach dem Oberbegriff des Anspruchs 2.
In einer Veröffentlichung von Prof. Dr. Peter Göhner: „Agentensysteme in der Automatisierung"; Universität Stuttgart; 2005, IAS, ist der Aufbau von verschiedenen Automatisierungssystemen beschrieben. Unter anderem werden agentenorientierte Automatisierungssysteme beschrieben, wobei Agenten Automatisierungsfunktionen erfüllen. Agentenorientierte Automatisierungs Systeme zeichnen sich durch eine flexible Aufteilung von Funktionen sowie eine freie Aktionsbeziehungen zwischen Agenten aus. Ferner erfolgt ein Austausch von funktionalen und Verhaltens-Informationen über abstrakte Interaktionen. Die Art der Interaktion ist in dem Aufsatz nicht näher erläutert.
Als Agent wird eine Softwareeinheit mit definiertem Ziel, mit autonomen Verhalten zur Erreichung des Ziels, mit der Fähigkeit zur Interaktion mit einer Umgebung und anderen Agenten definiert. Insbesondere beinhaltet ein Agent ein Abbild der relevanten Umgebung, definierte Ziele sowie Fähigkeiten.
Betreffend die Implementierung von Agenten wird ausgeführt, dass verschiedene Möglichkeiten zur Verfügung stehen, wie beispielsweise agentenorientierte Programmiersprachen, wie Agent-O, konventionelle Programmiersprachen sowie Agenten-Frameworks/Plattformen, wie beispielsweise JADE oder LS/TS.
Zu Agenten-Frameworks und -Plattformen wird ausgeführt, dass diese meist in herkömmlichen Programmiersprachen, wie JAVA, implementiert werden. Die Agenten- Frameworks und -Plattformen bieten Hilfsmittel zur Agentenerzeugung, Life-Cycle- Managements und Persistenz, Bibliotheken für verschiedene Verhaltens Strategien, Plattformen zur Agentenkommunikation wie beispielsweise Sprachen, wie ACL, Protokolle sowie Hilfsmittel zur Agenteninteraktion, wie beispielsweise Verzeichnisdienste (Gelbe Seiten).
Verfahren zur Programmierung eines Multi-Agenten-Systems sind beispielsweise auch in EP 1 577 724 A2 sowie EP 1 659 468 A2 beschrieben.
Oben genannte Entwicklung s verfahren sind allerdings an eine bestimmte Technologie gebunden, so dass ein einmal entwickelter Software- Agent nur in bestimmten Frameworks/Plattformen einsetzbar ist.
Ferner bezieht sich die Erfindung auf das Feld der verteilten intelligenten Systeme, welche einen signifikanten Bereich von Anwendungsgebieten abdeckend, zum Beispiel Telekommunikation, industrielle Automation, Fertigungssysteme, und ebenfalls die vertikale IT-Unternehmensintegration, von den strategischen Geschäftsleveln bis zu dem Gerätelevel. Die Erfindung spricht das Bedürfnis an, flexible und intelligente Systeme zu entwickeln, welche die Anforderungen an Modularität, Rekonfigurierbarkeit, Widerverwendbarkeit, Verteilung und Heterogenität unterstützen.
In einem Artikel von F. Jammes; A. Mensch; H. Smit: „Service-oriented device Communications using the device profile for web Services", MPAC'05, November 28, - Dezember, 2, 2005, Genoble, Frankreich, werden die Vorteile der Einführung von Serviceorientierten Architekturen auf dem Level der Kommunikation zwischen resource-abhängigen eingebetteten Geräten beschrieben. Insbesondere wird die Verwendung von sogenannten „Device Profile for Web Services" (DPWS) als Basis für solche Architekturen für „Intelligente"-Geräte diskutiert.
Unter „serviceorientierter Architektur" (SOA) wird in dem Artikel - sowie auch nachfolgend - eine Architektur als Satz architektonischer Grundsätze zum Aufbau autonomer und dialogfähiger bzw. vollständig kompatibler Systeme verstanden. Dabei wird unter „autonome Systeme" verstanden, dass diese unabhängig voneinander gebildet werden, dass diese unabhängig von Ihrer Umgebung betrieben werden und dass diese eine inhärente Funktionalität aufweisen, beispielsweise kann diese Funktionalität hilfreich sein, selbst wenn diese nicht mit einer Funktionalität höheren Levels gekoppelt ist.
Die Dialogfähigkeit bzw. vollständige Kompatibilität wird begünstigt durch eine klare Abstrahierung des Interfaces bzw. der Kommunikationsschnittstelle, die ein Service seiner Umgebung durch die Implementierung des Services präsentiert.
Grundsätzliche Interaktionsmuster eines Geräte-Level SOA kann anhand von fünf Funktionslevel beschrieben werden: Adressierung, Auffinden, Beschreiben, Steuerung, Ereignis. Dabei werden Geräte entweder als steuernde oder gesteuerte Geräte charakterisiert, wobei jedoch ein gegebenes Gerät beide Rollen verkörpern kann und „peer-to-peer"-Interaktionen ermöglicht. Ferner werden Geräte-Level Serviceorientierter Protokolle beschrieben, wie beispielsweise UPnP (Universal Plug and Play) einschließlich IP, TCP, UDP, HTTP, SOAP und XML.
Ausführlich wird auch der Ansatz über „ Device Profile for Web Services (DPWS)" beschrieben, welcher dieselben Vorteile wie UPnP hat, jedoch zusätzlich vollständig an Web Service Technologien ausgerichtet ist.
Die DPWS -Spezifikationen definieren eine Architektur, in welcher Geräte zwei Typen von Services aufweisen: „hosting Services" und „hosted Services". „Hosting Services" spielen eine wesentliche Rolle beim Auffindungsprozess des Geräts. „Hosted Services" sind meist funktional von ihrem „hosting" Gerät zur Auffindung abhängig. Zusätzlich zu den „hosted Services" spezifiziert DPWS ein Set von eingebauten Services:
„Discovery Services": Werden verwendet von einem Gerät welches mit einem Netzwerk verbunden wird, um sich bekannt zu machen und um andere Geräte aufzufinden.
„Meta Data Exchange Services": Stellt dynamischen Zugang zu einem „hosted- service" des Gerätes und zu dessen Metadaten bereit, wie beispielsweise WSDL- oder XML-Schema-Definitionen. „Published Subscribe Eventing Services": Erlaubt Geräten die Subskribierung asynchroner Ereignisnachrichten, die von einem gegebenen Service produziert oder erzeugt werden.
Im DPWS-Sprachgebrauch wird ein „gesteuertes" Gerät einfach als „Gerät" bezeichnet, während ein „steuerndes" Gerät als „client" bezeichnet wird.
Ein DPWS Protokoll-Stack hat folgende Struktur:
„WSDL" (Web Services Discription Language) für die abstrakte Beschreibung von Service-Kommunikationsschnittstellen (Interfaces) und deren Bindung an Übertragungs-/Transportprotokolle
„XML-Schema" zur Definition der Datenformate, die zur Konstruierung der Nachrichten verwendet werden, die an Services adressiert und von Services empfangen werden
„SOAP", das Protokoll zum Transport von servicebezogenen Mitteilungen, die in Übereinstimmung mit deren korrespondieren WSDL Definitionen formatiert sind
„WS-Adressing" ist eng mit dem SOAP verbunden und konzentriert alle adressierenden Informationen in den Header der SOAP-Nachrichtenhülle, wodurch ermöglicht wird, dass der Nachrichteninhalt über jedes Transportprotokoll (HTTP, SMTP, TCP, UDP, ...) übertragen werden kann
„WS-Policy" wird verwendet, um Regeln in Verbindung mit dem Web Service auszudrücken in Form von „Policy Assertions", welche die WSDL-Beschreibung des Services komplettieren „WS-Metadata Exchange" erlaubt die dynamische Abfrage von Metadaten, die mit dem Web Service assoziiert sind (Beschreibung, Schema und Policy), stellt somit ein Web Service Selbstprüfungs-Mechanismus zur Verfügung
„WS-Security" ist ein optionaler Set von Mechanismen zur Sicherung einer „end- to-end"-Nachrichten-Integrität, Vertraulichkeit und Authentizität.
Der DPWS-Protokoll-Stack integriert sämtliche oben dargestellte Standards. Ergänzend zu den oben beschriebenen Web Service Kern-Protokollen ergänzt DPWS Web Service Protokolle zur „Discovery" und „Preventing". Beispielsweise
„WS-Discovery" ist ein Protokoll für „plug-and-play" Auffindung von Netzwerkverbundenen Resourcen. Es definiert ein Multicastprotokoll zur Suche nach und zum Auffinden von Geräten. Einmal aufgefunden zeigt das Gerät die Services, die es zur Verfügung stellt.
„WS-Eventing" definiert ein „publish-subscribe"-Ereignis-behandelndes Protokoll, welches es einem Web Service erlaubt mit anderen Web Services ereignisbezogene Nachrichten auszutauschen. WS-Eventing ist vorgesehen zur Implementierung einer Reihe von Anwendungen, von Geräte-orientierten bis „Enterprise-scaled-published-subscribed"-Systemen, im oberen Teil desselben Substrats.
Typischerweise hat jeder DPWS-basierte Service eine bestimmte WSDL-Beschreibung. Diese Beschreibung ist gerätespezifisch; somit haben verschiedene Gerätetypen verschiedene WSDL-Beschreibungen mit wenigen Gemeinsamkeiten.
Der Code des DPWS-Service ist in verschiedenen Funktionen darauf angewiesen, Meldungen zu bearbeiten. Diese Funktionen sind abhängig von der DPWS- Beschreibung eines bestimmten Services. Damit in diesem Zusammenhang ein Service mit einem anderen kommunizieren kann, müssen beide Services die jeweiligen spezifischen Funktionen des anderen implementieren. Daher muss jede WDSL- Beschreibung jedes Mal, wenn ein neuer Service gestaltet worden ist, kompiliert werden, um einen Server-Code und einen Client-Code zu generieren.
Sollen die Services, welche die Geräte abstrahieren, in einer dynamischen Umgebung mit einer großen Anzahl von Geräten miteinander kommunizieren, so wird es für einen bestimmten Service aufgrund der Meldungen, die er mit anderen austauscht, unpraktisch, alle Anwender zu implementieren. Dies ist besonders kritisch, wenn die Geräte einer großen Anzahl von Verfahren/ Abläufen ausgesetzt sind.
Darüber hinaus ist in Netzwerkumgebungen, in welchen eine Ansammlung von Geräten gewünscht ist, das Umprogrammieren ein schwerwiegendes Hemmnis dynamischer Ansammlung und sofort betriebsbereiter Konnektivität des Systems.
In diesem Zusammenhang wird auch auf die Veröffentlichungen WO 2008/09021 A2 sowie WO 2008/101912 Al hingewiesen, deren Offenbarung hier vollinhaltlich aufgenommen wird.
Davon ausgehend liegt der vorliegenden Erfindung die Aufgabe zugrunde, ein Verfahren zur Entwicklung eines Multi-Agenten-Systems sowie ein Multi-Agenten- System derart weiterzubilden, dass Software- Agenten technologieunabhängig einsetzbar sind, wodurch die Modularität, Rekonfigurierbarkeit und InterOperabilität in heterogenen Umgebungen verbessert wird.
Die Aufgabe wird erfindungs gemäß durch ein Verfahren mit den Merkmalen des Anspruchs 1 sowie durch ein service-orientiertes Multi-Agenten-System mit den Merkmalen des Anspruchs 2 gelöst.
Multi-Agenten-Systeme (MAS) und service-orientierte Architekturen (SoA) spezifizieren zwei Paradigmen, welche in das Feld der industriellen Automation und Produktion übertragen und entwickelt werden. Beide bieten ihre eigenen Vorteile und basieren auf separaten Modellen, haben jedoch auch gemeinsame Hintergrundanforderungen, Merkmale und Anwendungen. Die vorliegende Idee spezifiziert ein technologieunabhängiges Verfahren zur Entwicklung von Multi-Agenten-Systemen, welches durch Service-Orientierung geleitet, und angewendet wird um heterogene und gleichzeitig ablaufende Automationsund Produktionspläne und -probleme zu managen und zu lösen.
Die Idee stellt einen neuen Ansatz vor um modulare, steckbare, flexible und rekofigurierbare Systeme, insbesondere für industrielle Automation und Fertigungssysteme, basierend auf dem Konzept von Multi-Agenten-Systemen (MAS) und service-orientierte Architekturen (SoA) zu entwickeln.
Der Ansatz ist gekennzeichnet durch die Verwendung eines Sets von verteilten autonomen und kooperativen Einheiten, den Agenten, unter Verwendung von SoA- Prinzipien, die eine erhöhte Modularität, Rekonfigurierbarkeit und InterOperabilität in heterogenen Umgebungen erlauben.
Die Entwicklung solcher Service- orientierten Multi-Agenten-Systeme (SoMAS), welche Unterschiede im Bezug zu herkömmlichen Multi-Agenten-Systemen aufweisen, benötigt eine Entwicklungsumgebung welche die neuen Funktionalitäten unterstützt.
Insbesondere beschreibt die Idee ein Verfahren für die Entwicklung eines MultiAgenten-Systems orientiert an dem Angebot und der Anfrage von Services, um Industrie- und Produktionsziele zu erfüllen. Der Ansatz unterscheidet sich von herkömmlichen Multi-Agenten-Systemen in Gestalt von:
- Agenten sind service-orientiert: individuelle Ziele von Agenten können durch von anderen bereitgestellte Services vervollständigt werden. Interne Eigenschaften von Agenten können als Services für andere zum Aufruf angeboten werden.
- Merkmale sind von Service-Orientierung übernommen: Ein Hauptmerkmal ist die Wiederverwendbarkeit von Services eines Agenten der, nicht nur für einen einzigen Problemtyp, für den diese Entwickelt wurde, benutzt und angewendet werden kann sondern ebenfalls für verschiedene Anwendungen wiederverwendbar ist.
Die Idee repräsentiert ein Referenzmodell in dem die Kommunikation und die Entwicklungstechnologie offen ist. Dies bedeutet, dass jede geeignete Technologie zur Entwicklung der durch das Referenzmodell präsentierten Konzepte verwendet werden kann. Zum Beispiel können Web-Service-Technologien an den Resourcen-Zugriff über Services angepasst werden und C++- oder Java-Sprachen können zur Entwicklung der Agenten verwendet werden.
Der in dieser Erfindung beschriebene Ansatz verwendet Merkmale von MAS (MultiAgenten-Systemen)- und SoA-Paradigmen, kombiniert diese um verteilte, intelligente Systeme aufzubauen, die besser auf die gegenwärtige Anforderungen reagieren, nämlich bezüglich Modularität, Flexibilität, Rekonfigurierbarkeit und Adaptierbarkeit. Das Konzept eines solchen Systems wird beispielhaft für das Gebiet der Fertigungssysteme sein.
Die Idee ist in einem Referenzmodell formuliert, welches die allgemeinen Grundlagen bereitstellt, um ein service-orientiertes Multi-Agenten-System zur Lösung von Problemen und zum Erreichen von Zielen in industrieller Automationen und Produktionen zu spezifizieren.
Das Ziel des Patentvorschlags ist die Bereitstellung eines neuen Ansatzes für die Entwicklung von verteilten, intelligenten Systemen, welche Modularität, Flexibilität, Re-Konfigurierbarkeit und Interoperabilitätsfunktionen präsentieren, kombiniert mit den besten Merkmalen von MAS- und SoA-Paradigmen.
Die folgenden Themen fassen die grundsätzlichen Vorteile der Idee zusammen:
- Kombination der besten Merkmale aus MAS- und SoA-Paradigmen erweitern die Leistung von Autonomie, Modularität, Flexibilität und InterOperabilität, und konsequente Rekonfiguration die in verteilten Steuerungssystemen benötigt wird. Paradigma, welches 100 % Verteilung und „heterarchical" (Bedeutung: hierarchisch und verteilt) Steuerungsansatz garantiert.
Die Verwendung von service-orientierten Prinzipien vereinfacht die betriebliche Vertikal-Integration.
Transparenz, da die Agenten unter Verwendung verschiedener Methoden und Technologien entwickelt werden können, da Interaktionsmuster definiert werden und gemeinsamer Standard sind.
Integration in Informations-Technologie und Geschäfts-Level (üblicherweise Betrieb in service-orientierter Weise).
- Erweiterte Fähigkeiten zur Dezentralisation.
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 der Zeichnung zu entnehmenden bevorzugten Ausführungsformen.
Es zeigen:
Fig. 1 ein Modell basierend auf unterschiedlichen Schlüssel-Konzepten,
Fig. 2 eine schematische Übersicht eines service-orientierten Multi-Agenten-
Systems mit service-orientierten Agenten.
Fig. 3 Modulare Struktur einer Automatisierungskomponente, und
Fig. 4 Zusammensetzung von Modulen zur Bildung von Typen von
Automatisierungskomponenten Ein der Erfindung zugrunde liegendes Modell ist in Fig. 1 dargestellt, welches nachfolgend erläutert wird:
- Aufgabengebiet (Domain): Industrielle Automation und Produktion: Das Aufgabengebiet des Referenzmodells wird angewendet auf das Gebiet der industriellen Automation und Produktion bestehend aus Software und Hardwarekomponenten
- Ziel: Löse heterogene Automations- und Produktionsprozesse: Da moderne und flexible Systeme heterorgene und gleichzeitig ablaufende Aktivitäten umfassen und diese Einbeziehen, zielt das Modell auf das Management und die Auflösung von Prozessen für die Automation von Geräten und ebenfalls die Produktion von Gütern ab. Prozesse können einfache statische Beschreibungen von Arbeits-Plänen zur Ausführung eines gegebenen Ziels oder dynamisch konstruierte Kollaborationen für einen flexibleren Ansatz umfasen.
- Umgebung :Modular /V erteilt, Service -basiert: In dem System sind Software- und Hardwarekomponenten enthalten. Softwarekomponenten sind im Allgemeinen Agenten mit spezifizierten Funktionen (Tasks) und können ebenfalls Hardwarekomponenten repräsentieren/steuern. Ressourcen und Funktionen von Agenten und anderen Softwarekomponenten werden als Services dargestellt.
- Einheiten: Service-orientierte Software-Agenten: Ein Software-Agent ist eine Einheit, die für einen Benutzer oder ein Gerät agiert und die Fähigkeit hat, ihre eigenen Ziele zu lösen. Mehrere zusätzliche Konzepte schließen den Grad der Autonomität von Agenten ein und ebenfalls deren Lern- und Intelligenz- Befähigungn. Ein Multi-Agenten-System wird verwendet, wenn komplexe Zielsetzungen aus separierten individuellen Problemen erstellt werden, die von einzelnen Agenten gelöst werden können und deren Kollaboration, Reduzierung der Komplexität des gesamten Problems. Die eingeführte Erweiterung bedingt einen Service- orientierten Ansatz auf die Agenten. In diesem Fall werden die Agenten durch ihre eigenen Bedürfnisse und Motivation zur Lösung ihrer Probleme geleitet, können jedoch ebenfalls ihre Bedürfnisse durch Aufrufen von Services ergänzen , welche durch andere Agenten bereitgestellt werden, und haben ebenfalls die Fähigkeit Services der Gemeinschaft bereitzustellen.
Fig. 2 zeigt eine schematische Übersicht auf service-orientierte Agenten und serviceorientierte Multi- Agenten-Systeme.
Ein besonderes Merkmal welches durch den Ansatz geboten wird ist, dass jeder Agent intern unabhängig und unterschiedlich (zum Beispiel durch Verwendung unterschiedlicher Technologie, zum Beispiel unterschiedliche
Entscheidungstechniken, unterschiedliche Logik-Kontroller, usw.) implementiert werden kann. Die einzige Forderung ist, dass er seine Funktionen als Services verteilt und den Kommunikationsprotokollen und ausgeführten Prozessen folgt. Diese Flexibilität kann bei der Entwicklung von kundenspezifischen Komponenten für diversitäre Tasks einen Beitrag leisten. Eine Anregung für die interne Spezifikation dieser service-orientierten Agenten ist die Adaption eines modularen Ansatzes wie dieser in der Patentanmeldung "Modular and functional structure for service-oriented automation components" (DE 10 2008 002 827.4) beschrieben ist.
Beziehungen: Anfrage/Bereitstellung Services: Probleme und Unter-Probleme werden durch Agenten gelöst, die kollaborieren sollten. Die Kollaboration wird durch Bereitstellung von Services durch Agenten (wenn diese die Eigenschaften haben) und deren Anfrage (wenn Agenten Bedürfnisse haben) erreicht.
Mehrere andere Themen beziehen sich auf die Entwicklung von Systemen, die gemäß dem Referenzmodell spezifiziert und entwickelt werden. Andererseits und da das Referenzmodell technologie-unabhängig ist, kann die Entwicklung von konsequent service-orientierten Multi-Agenten-Systemen unter Verwendung von derzeit verfügbaren Agenten Entwicklungs-Frameworks und service-orientierten Systemen ausgeführt werden. Nicht als Teil des Modells, jedoch konsequente Aspekte der Entwicklung müssen berücksichtigt werden:
- Beschreibung von Wissen und Semantik: Agenten können verstehen, welches die mit Services und anderen Elementen assoziierte Information ist.
- Zentralisation/Dezentralisation von Einheiten (Agenten) und Tasks: Aufgrund der Flexibilität des Referenzmodells können implementierte Systeme einen zentralisierteren Ansatz (zum Beispiel Master/Slave-Agenten) oder eine vollständig dezentralisierte Verteilung (mehr kollaborative Aktivitäten zwischen Agenten, Austausch ihrer Services) adaptieren;
- Beschreibung von Prozessen, welche Verhalten von Agenten und Verwendung von Services beschreiben, kann verwendet werden als Ergänzung für Koordination von Aktivitäten.
- Services können aggregiert/assoziert verbunden werden, Vereinfachung des externen Zugriffs auf Ressourcen
- Ein Weg zur Adressierung und Erkennung von Services und Agenten.
- Autonomie und Pro-Aktivität von Agenten sollte beachtet werden im Sinne von nicht nur Bereitstellung von Services sondern ebenfalls der Fähigkeit diese anzufragen und Entscheidungs- und Steuerungs-„Autonomie" über einen Teil des Problems zu haben.
Es können mehrere Beispiele und Anwendungen angegeben werden, die auf dem Referenzmodell basieren. Ein herkömmliches Fertigungs Szenario umfasst mehrere Systemkomponenten, die charakterisiert werden können als: Produktions-/Umsetzungs- Maschinen, Transportsystem, Lager/Depot und das Produkt selbst. Betrachtet man ein Multi-Agenten-System, welches auf ein solches Szenario angewendet wird, würden Software-Agenten die verschiedenen Elemente in dem System repräsentieren und über dieses agieren. Zum Beispiel existiert ein Agent für jede spezifische Produktionsmaschine, jedes Transportmodul und jeden Satz von Produkten. Ein für eine Produktionsmaschine verantwortlicher Agent hat die notwendigen Eigenschaften Produktionsservices anzubieten (zum Beispiel Füllen einer Dose), so dass er diesen Typ von Service anbieten wird. Vorher müssen jedoch dessen Bedürfnisse erfüllt sein: Erhalten einer spezifischen Flüssigkeit aus einer Quelle, was vorher von einem anderen Agenten, der einen solchen Service bereitstellt verhandelt (und angefragt) wurde. Ein Agent welcher sich um mehrere Produkte kümmert wird proaktiv in dem Sinne des Anfragens von Transportservices (von dem Transportsystem) um im Stande zu sein Produkte zwischen verschiedenen Örtlichkeiten zu transferieren und ebenfalls Produktionsservices anzufragen, welche durch Produktionsmaschinen Agenten bereit gestellt werden. Dies kann erreicht werden durch Verfolgen eines Arbeitsablaufs von Services, die für eine Produktionsart etabliert wurde.
Eine generische Architektur für service-orientierte Automatisierungskomponenten AK definiert, dass eine Automatisierungskomponente in einem Puzzle von steckbaren und wiederverwendbaren Modulen ERS-MOD, KOM-MOD, GI-MOD, LS-MOD, EAH- MOD strukturiert ist, wie in Fig. 3 dargestellt, wobei jede ihre eigene Funktion hat. Die Hauptmodule, welche hier betrachtet werden, sind: Logik-Steuerung LS-MOD, Kommunikation KOM-MOD, Entscheidungs- und Ausnahme-Handler EAH-MOD, Geräte-Interface GI-MOD und Ereignis-Router-Scheduler ERS-MOD.
Das Logik-Steuerungs-Modul LS-MOD, welches auch als Orchestrierungs-Modul bezeichnet werden kann, regelt das Verhalten der Automatisierungskomponente durch Koordination im Sinne von Komposition und Orchestrierung eines Sets von Services S gemäß ihres Verhaltens, beschrieben durch ein logisches Modell. Die in der Automatisierungskomponente eingebettete Logik ist abhängig von der Systemtopologie, jedoch sollte diese von dem Prozessplan jedes Produkts unabhängig sein. Ein möglicher Ansatz zur Entwicklung eines Logikcontrollers (z. B. Design, Validation, Simulation und Ausführung) kann für service-orientierte Systeme angepasste High-Level Petri Netze verwenden, wobei die Vorteile ihrer leistungsfähigen mathematischen Grundlage, diskrete, dynamische und verteilte Systeme zu repräsentieren, genutzt werden. Diese Logikcontroller (Orchestrierungs-Maschinen) müssen das in Petri-Netzen ausgedrückte Prozessmodell interpretieren und ausführen.
Die Anwesenheit von Logik-Steuerungs-Modulen LS-MOD in mehr als einer Automatisierungskomponente erlaubt den Aufbau einer nicht-hierarchischen Architektur, was bedeutet, dass die überwachende Steuerung tatsächlich verteilt ist und nicht zentral koordiniert. In diesem Fall müssen die durch Koordination von Services S eingekapselten Prozesse miteinander zusammenwirken, um dasselbe Synchronisationslevel zu erreichen, wie sie eine zentralisierte Einheit zur Verfügung stellen würde.
Die Kommunikation zwischen den Automatisierungskomponenten AK wird ausgeführt über die Einbindung von Services S der Automatisierungskomponenten, welche in den Kommunikations-Modulen KOM-MOD enthalten sind und von diesen bereitgestellt werden. Beispielsweise kann ein Förderband den Transfer-Service bereitstellen, um die Bewegung von Paletten zu handhaben, der von anderen Automatisierungskomponenten genutzt werden kann, jedoch kann dieser ebenfalls externe Services S aufrufen, wenn diese benötigt werden (z. B. um mit einem anderen Förderer verbunden zu werden, ist die Anfrage des Transfer-Services eines anderen Förderers notwendig). Eine geeignete technologische Lösung, um die service-orientierten Kommunikations-Module KOMMOD zu implementieren, ist die Verwendung von Web-Technologie, und insbesondere Web-Services.
Das Entscheidungs- und Ausnahme-Handler-Modul EAH-MOD stellt in Realzeit Entscheidungsfindungs- und Konfliktlösungs-Services zur Verfügung, um die Koordination der Ausführung der Services S zu unterstützen, da das Logikmodell des Systems eine festgelegte Sequenz von Aktionen nicht beschreibt, jedoch statt dessen alle möglichen Kombinationen von diesen. Zum Beispiel, wenn ein System durch Redundanz von Service-Providern flexibel ist, muss das konkrete Mapping von Services zu Geräten in Realzeit entschieden werden. Der Komplexitätsgrad, welcher mit dem Entscheidungsfindungsmechanismus verknüpft ist, kann im Bereich von einfachen Algorithmen bis komplexen berechneten Systemen liegen, wie beispielsweise Multiagentensysteme, Expertensysteme, neuronale Netzwerke und genetische Algorithmen.
Das Geräte-Interface-Modul GI-MOD stellt die Mechanismen zur Integration der physikalischen Geräte wie beispielsweise Roboter oder Sensoren zur Verfügung, innerhalb des Steuerungsteils der Automatisierungskomponente. Da lokale Gerätecontroller üblicherweise geschlossene Architekturen aufweisen, ist es notwendig, Hüllen zu entwickeln, um die Details jedes Gerätecontrollers zu verbergen und Stammfunktionen bereitzustellen, die die Funktionalität des physikalischen Geräts repräsentieren. Das Geräte-Interface-Modul GI-MOD setzt sich zum Ziel, diese Aufgaben zu erfüllen, durch Bereitstellung von Mechanismen zur Unterstützung der einfachen und transparenten Integration von physikalischen Geräten innerhalb der Steuerungsanwendungen.
Das Herz der Struktur ist das Event-Router-Scheduler-Modul ERS-MOD, das als ein Koordinator für die verschiedenen asynchronen und konkurrierenden Komponenten- Module wirkt.
Ein wichtiges Merkmal, welches von der vorgeschlagenen generischen Komponentenstruktur dargestellt wird, ist, dass jede Automatisierungskomponente der Architektur unabhängig und unterschiedlich implementiert werden kann. Die einzige Notwendigkeit ist, dass die Automatisierungskomponente ihre Funktionen als Services mit anderen teilen und den Kommunikationsprotokollen und Prozessen folgen sollte. Diese Flexibilität kann zur Entwicklung für kundenspezifischer Komponenten für diversifizierte Anwendungen beitragen.
Die generische modulare Struktur für die service-orientierten Automatisierungskomponenten kann verwendet werden, um unterschiedliche Typen von Automatisierungskomponenten zu implementieren, die an der Steuerung teilhaben, nämlich die Mechatronik-Komponenten MeC, Prozesssteuerungskomponenten PCC und intelligente Support-Komponenten ISC, wie in Fig. 4 dargestellt. Die Entwicklung von Automatisierungskomponenten AK wird erreicht durch Festlegung des Sets von Kernel-Modulen KER-MOD wie z. B. Kommunikations-Modul KOM-MOD und Event-Router-Scheduler-Modul ERS-MOD, welche durch die generische Struktur bereitgestellt werden, und Auswahl der optionalen Module wie z. B. Logik-Steuerungs- Modul LS-MOD, Geräte-Interface-Modul GI-MOD und Entscheidungs- und Ausnahme-Handler-Modul EAH-MOD entsprechend des Typs und der Funktion der Automatisierungskomponente MeC, SMec, PCC oder ISC, wie in Fig. 2 dargestellt.
Die Komponente MeC umfasst die mechanische, elektronische und Software- Kombination, welche die lokale Steuerung des physikalischen Geräts erlaubt. Neben den Kommunikations- KOM-MOD und Event-Router-Scheduler-Modulen ERS-MOD, welche die Kernel-Module sind, kann ebenfalls das Logik-Steuerungs-Modul LS-MOD eingebettet sein, um dessen lokales Verhalten in Fällen zu regeln, wenn die Dekomposition von atomaren Operationen möglich ist und das Geräte-Interface-Modul GI-MOD sodann die Services synchronisiert, welche von dem physikalischen Gerät bereitgestellt werden, wie beispielsweise Leseeingänge, Schreibausgänge oder Aufruf von Programmen.
Die Komponente MeC kann ebenfalls ihre eigene Intelligenz eingebettet aufweisen. In diesem Fall wird die Komponente als Intelligente-Mechatronik-Komponente SMeC bezeichnet. Die Komponente SMeC kann ebenfalls zusammengesetzte Automatisierungskomponenten repräsentieren, in dem Sinne, dass eine Automatisierungskomponente eine Aggregation von mehreren anderen Automatisierungskomponenten ist wie z. B. ein Transportsystem, welches aus individuellen Fördereinheiten aufgebaut ist. Neben den von den Komponenten MeC geerbten Modulen, enthält die Struktur dieses Typs von Automatisierungskomponenten ebenfalls das Entscheidungs- und Ausnahme-Handler-Modul EAH-MOD, welches lokalen Entscheidungssupport für den Logik-Steuerungs-Mechanismus im Fall von Entscheidungsbedarf oder Konfliktlösung bereitstellt. Andere Anwendungsbeispiele der generischen Struktur für service-orientierte Automatisierungskomponenten AK sind die Entwicklung von Prozesssteuerungskomponenten PCC. In komplexeren Systemen, die aus kleinen mechatronischen Automatisierungskomponenten aufgebaut sind, ist es notwendig, Automatisierungskomponenten zu haben, die globale
Prozesskoordinationsmechanismen bereitstellen.
Die Komponenten PCC, welche ihre eigene Logik-Steuerung aufweisen, stellen diese Art von Mechanismen bereit und wirken als Clienten, die imstande sind, von anderen Automatisierungskomponenten bereitgestellte Services zu nutzen. Die Komponente PCC unterstützt den komplexen Prozessfluss und die Interaktion von Services in dem System, entsprechend eines Prozessmodells. Für diese Anwendung implementieren diese die Logik für das Work-Flow-orientierte Ausführen und Sequenzieren von atomaren Services, und stellen ein High-Level-Interface für den aggregierten Prozess zur Verfügung, welcher aus einzelnen Teilprozessen zusammengesetzt ist. Als Beispiel kann ein Roboter einen Transportservice bereitstellen, der verschiedene Operationen beinhaltet, wie beispielsweise Greifen, Bewegen und Platzieren. Dieser kann seine Aktivitäten mit seinen verbundenen Nachbarn synchronisieren, und falls notwendig, Befehle von globalen Komponenten aufnehmen. Die Struktur dieser Art der Automatisierungskomponenten umfasst das Kommunikations-Modul KOM-MOD, Event-Router-Scheduler-Modul ERS-MOD, Logik-Steuerungs-Modul LS-MOD und die Entscheidung s- und Ausnahme-Handler-Module EAH-MOD. Da diese Typen von Komponenten den Zugriff auf physikalische Hardware nicht benötigen, ist das Geräte- Interface-Module GI-MOD in dieser Struktur nicht enthalten.
Durch die Idee wird eine gemeinsame und generische Struktur für service-orientierte Automatisierungskomponenten zur Verfügung gestellt werden, die einfache und schnelle Entwicklung von flexiblen und rekonfigurierbaren Produktionssystemen unterstützt.
Die folgenden Themen fassen die eigentlichen Vorteile der Anwendung der Idee zusammen: Definition einer gemeinsamen Struktur für Service- orientierte
Automatisierungskomponenten, die die Entwicklung von rekonfigurierbaren
Systemen und die vertikale Unternehmensintegration vereinfachen;
Funktionale Trennung von Modulen, die für verschiedene Anwendungen wiederverwendet werden können. Die Module können unabhängig entwickelt werden, da sie die notwendigen Interfaces für Inter-Modul-Kommunikation implementiert haben;
Integrationstransparenz, da die Modulstrukturen entwickelt werden können unter
Verwendung verschiedener Methodologien und Technologien;
Systemintegrationstransparenz, da das System das modulare Framework nutzt mit dem service-orientierten Kommunikations-Modul, welches in verteilten und heterogenen Umgebungen ausschlaggebend ist;
Erweiterte Flexibilität und konsequente Rekonfigurabilität, die von verteilten
Steuerungssystemen verlangt wird.

Claims

PatentansprücheVerfahren zur Entwicklung eines Multi-Agenten-Systems sowie Multi-Agenten-System
1. Verfahren zur Entwicklung eines Multi-Agenten-Systems, wie Automations- und/oder Produktionssystem, umfassend Software- und/oder Hardwarekomponenten, deren Ressourcen und Funktionen durch Software- Agenten repräsentiert und/oder gesteuert werden, wobei jeder Software- Agent die Fähigkeit hat, definierte Ziele durch Interaktion mit der Umgebung und anderen Agenten zu erreichen, dadurch gekennzeichnet, dass die Ressourcen und Funktionen der Software- Agenten und anderer Software-Komponenten als Services dargestellt werden, wobei jeder Software- Agent zur Erreichung seiner eigenen Ziele Services anderer Software- Agenten aufruft und seine eigenen Ressourcen und Funktionen anderen Software- Agenten als Service anbietet.
2. Multi-Agenten-Systems, wie Automations- und/oder Produktionssystem, umfassend Software- und/oder Hardwarekomponenten, dessen Ressourcen und Funktionen durch Software- Agenten repräsentiert und/oder gesteuert werden, wobei jeder Software- Agent die Fähigkeit hat, definierte Ziele durch Interaktion mit der Umgebung und anderen Software- Agenten zu erreichen, dadurch gekennzeichnet, dass die Software- Agenten Service- orientiert ausgebildet sind und ihre Ressourcen und Funktionen als Services anbieten und darstellen.
PCT/EP2009/063366 2008-10-13 2009-10-13 Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system WO2010043629A1 (de)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US13/123,762 US20120029656A1 (en) 2008-10-13 2009-10-13 Method for developing a multi-agent system and multi-agent system
EP09752312A EP2342607A1 (de) 2008-10-13 2009-10-13 Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102008037446A DE102008037446A1 (de) 2008-10-13 2008-10-13 Referenz Model für service-orientierte Multi-Agenten-Systeme in der industriellen Automation und Produktion
DE102008037446.6 2008-10-13

Publications (1)

Publication Number Publication Date
WO2010043629A1 true WO2010043629A1 (de) 2010-04-22

Family

ID=41566141

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2009/063366 WO2010043629A1 (de) 2008-10-13 2009-10-13 Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system

Country Status (4)

Country Link
US (1) US20120029656A1 (de)
EP (1) EP2342607A1 (de)
DE (1) DE102008037446A1 (de)
WO (1) WO2010043629A1 (de)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101977160A (zh) * 2010-11-30 2011-02-16 中国人民解放军信息工程大学 可重构路由交换平台中的路由协议软件构件重构方法
DE102015221652A1 (de) 2015-11-04 2017-05-04 Hochschule Düsseldorf Steuerungseinrichtung mit einem Steuerungsprogramm und einer Runtime-Maschine zum Betreiben eines Automatisierungsgerätes
DE102015221650A1 (de) 2015-11-04 2017-05-04 Hochschule Düsseldorf Steuerungseinrichtung mit einem Steuerungsprogramm und einer Gerätekonfiguration zum Betreiben eines Automatisierungsgerätes
WO2017077013A1 (de) 2015-11-04 2017-05-11 Hochschule Düsseldorf Steuerungseinrichtung mit einem steuerungsprogramm und einer gerätekonfiguration zum betreiben eines automatisiserungsgerätes
CN109031959A (zh) * 2018-10-26 2018-12-18 黑龙江大学 一种带有控制参数自适应补偿的非一致非线性系统协同控制方法及控制系统
DE102017217839A1 (de) * 2017-10-06 2019-04-11 Robert Bosch Gmbh Steuersoftware, Montagearbeitsplatz, Anordnung mit einer Mehrzahl von Montagearbeitsplätzen, computerlesbares Medium
WO2021041774A1 (en) * 2019-08-29 2021-03-04 Siemens Aktiengesellschaft Abstraction of plc communication
CN113093673A (zh) * 2021-03-31 2021-07-09 南京大学 一种使用平均场动作价值学习优化车间作业排程的方法

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102011053757A1 (de) * 2011-09-19 2013-03-21 Schneider Electric Automation Gmbh Verfahren zur Generierung und Handhabung von Applikationen für Komponenten eines Steuerungssytems
WO2016180478A1 (de) 2015-05-12 2016-11-17 Siemens Aktiengesellschaft Steuereinrichtung für ein produktionsmodul, produktionsmodul mit steuereinrichtung sowie verfahren zum betreiben der steuereinrichtung
DE102015212264A1 (de) 2015-07-01 2017-01-05 Siemens Aktiengesellschaft Steuereinrichtung für ein Produktionsmodul, Produktionsmodul mit Steuereinrichtung sowie Verfahren zum Betreiben der Steuereinrichtung
US11774920B2 (en) 2016-05-04 2023-10-03 Johnson Controls Technology Company Building system with user presentation composition based on building context
US11231691B2 (en) 2016-05-04 2022-01-25 Johnson Controls Technology Company Systems and methods for agent interaction with building management system
US11226598B2 (en) 2016-05-04 2022-01-18 Johnson Controls Technology Company Building system with user presentation composition based on building context
US11226597B2 (en) 2016-07-11 2022-01-18 Johnson Controls Technology Company Systems and methods for interaction with a building management system
US9817383B1 (en) 2016-07-11 2017-11-14 Johnson Controls Technology Company Systems and methods for agent interaction with building management system
US10310837B2 (en) 2016-08-25 2019-06-04 General Electric Company Method and apparatus for updating industrial assets
CN106980548A (zh) * 2017-02-22 2017-07-25 中国科学院合肥物质科学研究院 基于Jade的智能仓库调度多Agent系统及方法
CN106873564B (zh) * 2017-04-26 2019-09-20 南京航空航天大学 基于智能车间的流动式多智能体实时调度方法
EP3629264A1 (de) * 2018-09-28 2020-04-01 Siemens Aktiengesellschaft Produktionsmodul
DE102021213898A1 (de) 2021-12-07 2023-06-07 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Optimieren von Ressourcen in einem Kommunikationsnetzwerk mittels wenigstens zwei Agenten

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6851115B1 (en) * 1999-01-05 2005-02-01 Sri International Software-based architecture for communication and cooperation among distributed electronic agents
GB0220899D0 (en) * 2002-09-09 2002-10-16 Univ Liverpool Automation system for information management, condition monitoring and real-time control of distributed industrial systems
DE102008002827A1 (de) 2008-04-21 2010-02-04 Schneider Electric Automation Gmbh Modulare und funktionale Struktur für serviceorientierte Automatisierungskomponenten
US8145333B2 (en) * 2008-12-01 2012-03-27 Rockwell Automation Technologies, Inc. Ontology-based system and method for industrial control

Non-Patent Citations (6)

* Cited by examiner, † Cited by third party
Title
A. J. DIETRICH U. A.: "IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT", vol. 54, 1 February 2007, IEEE INC. NEW YORK, article "A Service-Oriented Architecture for Mass Customization - A Shoe Industry Case Study", pages: 190 - 204
ANDREAS J DIETRICH ET AL: "A Service-Oriented Architecture for Mass Customization-A Shoe Industry Case Study", IEEE TRANSACTIONS ON ENGINEERING MANAGEMENT, IEEE INC. NEW YORK, US, vol. 54, no. 1, 1 February 2007 (2007-02-01), pages 190 - 204, XP011161717, ISSN: 0018-9391 *
CHRISTIAN BRECHER, FRANK POSSEL-DÖLKEN: "Agentenbasierte Ablaufsteuerung - Projektierbares Multiagentensystem für die Ablaufsteuerung in der automatisierten Fertigung", ATP AUTOMATISIERUNGSTECHNISCHE PRAXIS, vol. 47, no. 11, November 2005 (2005-11-01), pages 46 - 54, XP002566278 *
PROF. DR. PETER GÖHNER, AGENTENSYSTEME IN DER AUTOMATISIERUNG, 2005
See also references of EP2342607A1 *
VON CHRISTIAN BRECHER U.A.: "Agentenbasierte Ablaufsteuerung - Projektierbares Multiagentensystem für die Ablaufsteuerung in der automatisierten Fertigung", ATP AUTOMATISIERUNGSTECHNISCHE PRAXIS, vol. 47, no. 11, November 2005 (2005-11-01), pages 46 - 54

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101977160A (zh) * 2010-11-30 2011-02-16 中国人民解放军信息工程大学 可重构路由交换平台中的路由协议软件构件重构方法
CN101977160B (zh) * 2010-11-30 2012-08-22 中国人民解放军信息工程大学 可重构路由交换平台中的路由协议软件构件重构方法
DE102015221652A1 (de) 2015-11-04 2017-05-04 Hochschule Düsseldorf Steuerungseinrichtung mit einem Steuerungsprogramm und einer Runtime-Maschine zum Betreiben eines Automatisierungsgerätes
DE102015221650A1 (de) 2015-11-04 2017-05-04 Hochschule Düsseldorf Steuerungseinrichtung mit einem Steuerungsprogramm und einer Gerätekonfiguration zum Betreiben eines Automatisierungsgerätes
WO2017077013A1 (de) 2015-11-04 2017-05-11 Hochschule Düsseldorf Steuerungseinrichtung mit einem steuerungsprogramm und einer gerätekonfiguration zum betreiben eines automatisiserungsgerätes
DE102017217839A1 (de) * 2017-10-06 2019-04-11 Robert Bosch Gmbh Steuersoftware, Montagearbeitsplatz, Anordnung mit einer Mehrzahl von Montagearbeitsplätzen, computerlesbares Medium
CN109031959A (zh) * 2018-10-26 2018-12-18 黑龙江大学 一种带有控制参数自适应补偿的非一致非线性系统协同控制方法及控制系统
CN109031959B (zh) * 2018-10-26 2021-09-07 黑龙江大学 一种非一致非线性系统协同控制方法及控制系统
WO2021041774A1 (en) * 2019-08-29 2021-03-04 Siemens Aktiengesellschaft Abstraction of plc communication
CN114375428A (zh) * 2019-08-29 2022-04-19 西门子股份公司 Plc通信的抽象
CN113093673A (zh) * 2021-03-31 2021-07-09 南京大学 一种使用平均场动作价值学习优化车间作业排程的方法

Also Published As

Publication number Publication date
EP2342607A1 (de) 2011-07-13
DE102008037446A1 (de) 2010-05-06
US20120029656A1 (en) 2012-02-02

Similar Documents

Publication Publication Date Title
WO2010043629A1 (de) Verfahren zur entwicklung eines multi-agenten-systems sowie multi-agenten-system
EP2153291B1 (de) Kollaboratives automationssystem sowie verfahren zur steuerung eines solchen
DE69609516T2 (de) Verfahren zur verwaltung dynamischer relationen zwischen objekten in dynamisch objektorientierten programmiersprachen
DE602004004300T2 (de) Verfahren, System und Computerprogramm für das Senden und Empfangen von Meldungen durch einen individuellen Kommunikationskanal
DE60109709T2 (de) Datenverwaltungsrahmenwerk für Verfahrensverwaltung
EP2476032A2 (de) Verfahren zur konfiguration von soa-basierten automatisierungsgeräten und zur entwicklung einer orchestrierungs-maschine, fertigungsverfahren und fertigungssystem in service-orientierter architektur mit eingebetteter service-orchestrierungs-engine
EP1560094A1 (de) Bereitstellung von Diensten innerhalb eines Netzwerks mit gekoppelten Rechnern
WO2003050680A2 (de) System und verfahren zur kommunikation zwischen softwareapplikationen, insbesondere mes-applikationen
EP2201454A1 (de) Automatisierungsgerät mit steuerprogramm sowie verfahren zu dessen programmierung
WO2011088878A1 (de) Verbindungsmodul zum anbinden mindestens eines sensors, aktors oder effektors an ein service oriented architecture- (soa-) netzwerk
Mendes et al. Service-oriented control architecture for reconfigurable production systems
EP2248012A1 (de) Verfahren und system zur einbindung von service-orientierten automatisierungskomponenten einer fertigungsstätte in eine flexible it-unternehmensarchitektur
Margaria Web services-based tool-integration in the ETI platform
EP2245514B1 (de) Serviceorientiertes automatisierungsgerät sowie verfahren zur spezifizierung eines serviceorientierten automatisierungsgeräts
DE10161115A1 (de) Transformation von Objektbäumen, insbesondere in MES-Systemen
Barata The cobasa architecture as an answer to shop floor agility
WO2009130221A1 (de) Struktur einer service-orientierten automatisierungskomponente
Pflüger Konversation, manipulation, delegation: Zur ideengeschichte der interaktivität
Halpern Standards collisions around SDN.
Charatsis et al. Home/building automation environment architecture enabling interoperability, flexibility and reusability
Fougères Agent-based micro-tools development for a co-operative design platform
Zajac et al. Towards agent-based manufacturing systems
Fougères Agent-Based µ-Tools Integrated into a Co-Design Platform
EP2250557A1 (de) Verfahren zur steuerung einer interaktion zwischen modulen einer service-orientierten komponente sowie service-orientierte komponente
Michaud Intelligent agents for network management

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: 09752312

Country of ref document: EP

Kind code of ref document: A1

DPE1 Request for preliminary examination filed after expiration of 19th month from priority date (pct application filed from 20040101)
NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009752312

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 13123762

Country of ref document: US