DE19850469A1 - Automatisierungssystem und Verfahren zum Zugriff auf die Funktionalität von Hardwarekomponenten - Google Patents

Abstract

Die Erfindung betrifft ein Automatisierungssystem (1) mit über mindestens ein Bussystem (B1...B3) koppelbaren Hardwarekomponenten (H1...Hn), insbesondere Motoren, Sensoren, Aktuatoren etc. Eine möglichst flexible und offene Betriebsweise des Automatisierungssystems kann dadurch erzielt werden, daß jede Hardwarekomponente (H1...Hn) jeweils eine Systemverbindungseinheit (5) mit Funktionsobjekten als Abbild der realen Funktionalität der Hardwarekomponenten (H1...Hn) aufweist, wobei die Funktionsobjekte zum Zugriff auf die Funktionalität der Hardwarekomponenten über das Bussystem vorgesehen sind. Die Funktionsobjekte sind als DCOM-Objekte ausgebildet, so daß eine Nutzung der aus der Bürowelt bekannten Mechanismen zur Ausführung von verteilten Anwendungen möglich wird.

Description

Die Erfindung betrifft ein Automatisierungssystem mit über mindestens ein Bussystem koppelbaren Hardwarekomponenten, insbesondere Motoren, Sensoren, Aktuatoren, etc.

Die Erfindung betrifft weiter ein Verfahren zum Zugriff auf die Funktionalität von derartigen Hardwarekomponenten.

Ein derartiges Automatisierungssystem besteht beispielsweise aus Motoren, Sensoren, etc., die beispielsweise im Zusammen­ spiel mit einer oder mehreren übergeordneten Steuerungen ei­ nen automatischen Produktionsprozeß bilden. Für die Ansteue­ rung der Hardwarekomponenten ist dabei in der Regel eine spe­ zielle zwischen Steuerung und Hardwarekomponente zwischenge­ schaltete Abstraktionshülle erforderlich, die die Vermittlung der Steuerungsbefehle zwischen Steuerungsvorrichtung und Hardwarekomponente übernimmt. Bei einem Austausch von Hardwa­ rekomponenten bzw. bei einer Ergänzung ist somit neben Ände­ rungen der Hardwarekomponenten selbst in der Regel auch eine Änderung bzw. Anpassung der Steuerungsvorrichtung beispiels­ weise in Bezug auf Steuerungsprogramme etc. erforderlich.

Der Erfindung liegt die Aufgabe zugrunde, auf einfache Weise eine offene und flexible Betriebsweise des Systems zu erzie­ len. Insbesondere sollen dabei Hardwarekomponenten ohne Ände­ rungen der Steuerprogramme austauschbar sein.

Diese Aufgabe wird durch ein Automatisierungssystem mit über mindestens ein Bussystem koppelbaren Hardwarekomponenten, insbesondere Motoren, Sensoren, Aktuatoren, etc. gelöst, die jeweils eine Systemverbindungseinheit mit Funktionsobjekten als Abbild der realen Funktionalität der Hardwarekomponenten aufweisen, wobei die Funktionsobjekte zum Zugriff auf die Funktionalität der Hardwarekomponenten über das Bussystem vorgesehen sind.

Diese Aufgabe wird durch ein Verfahren zum Zugriff auf die Funktionalität von Hardwarekomponenten, insbesondere Motoren, Sensoren, Aktuatoren, etc. eines Automatisierungssystems ge­ löst, bei dem die Kopplung der Hardwarekomponenten innerhalb des Automatisierungssystems über mindestens ein Bussystem er­ folgt, wobei auf die Funktionalität der Hardwarekomponenten über das Bussystem mittels einer in der Hardwarekomponente integrierte Systemverbindungseinheit mit Funktionsobjekten als Abbild der realen Hardwarefunktionen zugegriffen wird.

Die Erfindung geht von der Erkenntnis aus, daß es für eine Realisierung der Hardwarekomponenten als "plug and play"-Mo­ dule erforderlich ist, direkt in der Hardwarekomponente einen speziellen Baustein vorzusehen, auf dem die Funktionsobjekte als Zugang zur Funktionalität der Hardwarekomponenten ablauf­ fähig sind. Dieser spezielle Baustein ist in Form der System­ verbindungseinheit realisiert. Die Systemverbindungseinheit ist mit einem Bussystem des Automatisierungssystems gekop­ pelt, so daß Kommunikationsdaten beispielsweise von einem Leitsystem zur Hardwarekomponente wie auch von und zu sämt­ lichen mit dem Bussystem gekoppelten weiteren Komponenten übertragen werden können. Hierdurch können spezielle zwischen einem Leitsystem und den Hardwarekomponenten bisher erforder­ liche Vermittlungsobjekte entfallen. Darüber hinaus ver­ ringert sich durch die Einsparung derartiger als Hardware oder Software vorliegender Vermittlungsobjekte auch die Feh­ lerhäufigkeit, da die Systemverbindungseinheit im wesentli­ chen auf Softwareobjekten beruht. Hierdurch wird auch bei ei­ nem Austausch einer Hardwarekomponente sowie auch im Be­ triebsfall eine aktuelle und dynamische Abfrage zur Konfigu­ ration des Automatisierungssystems möglich. Darüber hinaus besteht über die Systemverbindungseinheit jederzeit eine di­ rekte Verbindung zur Funktionalität der Hardwarekomponenten.

Eine Konfiguration oder ein Zugriff auf die bestehenden Hard­ warekomponenten des Automatisierungssystems kann in vorteil­ hafter Weise derart realisiert werden, daß das Automatisie­ rungssystem ein Leitsystem und/oder ein Bedien- und Beobach­ tungssystem zum Zugriff auf die Funktionsobjekte aufweist.

Die Nutzung der aus der Bürowelt bekannten Mechanismen zur Ausführung von verteilten Anwendungen kann dadurch erfolgen, daß die Funktionsobjekte als DCOM-Objekte ausgebildet sind. DCOM (Distributed Component Object Model) ist ein Mechanis­ mus, der es ermöglicht, über mehrere Computer in einem Netz­ werk verteilte Anwendungen auszuführen. Eine verteilte Anwen­ dung kann dabei aus mehreren Prozessen bestehen, die zusam­ menarbeiten, um eine Aufgabe auszuführen. Diese Prozesse kön­ nen dabei auf einem oder mehreren Rechnern oder Systemverbin­ dungseinheiten ausgeführt werden.

Die Einbettung der den Hardwarekomponenten zugeordneten Sy­ stemverbindungseinheiten in ihre Umgebung kann dadurch erfol­ gen, daß die Funktionsobjekte mindestens ein erstes Funk­ tionsobjekt zur Erzeugung einer minimalen Funktionalität ei­ ner Hardwarekomponente, mindestens ein zweites Funktions­ objekt zur Verschaltung von Funktionsobjekten und mindestens ein drittes Funktionsobjekt zur Auflistung von in der System­ verarbeitungseinheit und/oder auf entfernten Systemverarbei­ tungseinheiten und/oder entfernten Rechnern vorhandenen Funk­ tionsobjekten enthalten.

Ein sogenanntes Verknüpfungsobjekt kann dadurch geschaffen werden, daß das zweite Funktionsobjekt zur Beeinflussung von Verbindungen zwischen den auf entfernten Systemverbindungs­ einheiten und/oder auf entfernten Rechnern vorhandenen Funk­ tionsobjekten vorgesehen ist.

Ein störungsfreier Zugriff auf die Hardwarekomponenten ohne die Notwendigkeit von Synchronisierungsmaßnahmen kann dadurch sichergestellt werden, daß durch das dritte Funktionsobjekt beim Zugriff auf die Systemverbindungseinheit ein dynamisches Abfrageobjekt generiert wird. Die Besonderheit dieses Abfra­ geobjekts besteht darin, die Summe der Funktionalität des Systems zu enumerieren.

Eine einfache und wirkungsvolle Möglichkeit zur Bereitstel­ lung von Codierungsmitteln wird dadurch erreicht, daß das Au­ tomatisierungssystem eine ladbare Tabelle mit Codierungsvor­ schriften aufweist. Hierdurch wird auch eine sogenannte Marshaling-Funktion der Funktionsobjekte erzielt.

Im folgenden wird die Erfindung anhand der in den Figuren dargestellten Ausführungsbeispiele näher beschrieben und er­ läutert.

Es zeigen:

Fig. 1 ein Blockschaltbild eines ersten Ausführungsbei­ spiels eines Automatiserungssystems mit verteilten Objekten,

Fig. 2 ein weiteres Ausführungsbeispiel eines Automatisie­ rungssystems mit mehreren Bussystemen,

Fig. 3 eine schematische Darstellung für den Aufbau einer Systemverbindungseinheit einer Hardwarekomponente und

Fig. 4 ein abstraktes Geräteobjektmodell.

Fig. 1 zeigt ein Blockschaltbild eines Automatisierungssy­ stems 1. Das Automatisierungssystem 1 besteht aus einem Leit­ system 3, welches über ein Bussystem B1 mit einer Vielzahl von Hardwarekomponenten H1..Hn gekoppelt ist. Mit dem Bussy­ stem B1 ist weiterhin ein Bedien- und Beobachtungssystem 6 gekoppelt. Jede Hardwarekomponente H1..Hn weist eine System­ verbindungseinheit 5 auf, die jeweils mit dem Bussystem B1 gekoppelt ist.

Zentraler Bestandteil des in Fig. 1 dargestellten Automati­ sierungssystems 1 ist die Systemverbindungseinheit 5, die der Kommunikation der Hardwarekomponenten H1..Hn innerhalb des Automatisierungssystems 1 sowie zur Abbildung der jeweiligen Funktionalität der Hardwarekomponenten H1..Hn, d. h. zur Er­ zeugung von Repräsentanten hierfür dient. Hierzu weist die Systemverbindungseinheit 5 ein minimales gemeinsames Inter­ face auf, welches eine für alle Hardwarekomponenten H1..Hn vorgegebene Identifizierung enthält und hierdurch von einen externen Kommunikationspartner, beispielsweise vom Leitsystem 3 auch ohne Kenntnis über das eigentliche Gerät, d. h. über die eigentliche Hardwarekomponente H1..Hn angesprochen werden kann. Durch die Systemverbindungseinheit 5 kann vom jeweili­ gen Ansprechpartner der Hardwarekomponente H1..Hn nach Auf­ nahme einer Kommunikation weiteres Wissen über die jeweilige Hardwarekomponente H1..Hn erlangt werden. Mit Hilfe der Sy­ stemverbindungseinheit 5 wird es somit möglich, Hardwarekom­ ponenten H1..Hn ohne Änderung der bestehenden Strukturen des Automatisierungssystems 1 zu ersetzen, zu ergänzen etc. Da­ rüber hinaus entfallen aufgrund der direkten Kommunikation eines übergeordneten Leitsystems mit der in der Hardwarekom­ ponente H1..Hn angeordneten Systemverbindungseinheit 5 anson­ sten erforderliche dazwischengeschaltete Abstraktionshüllen. Insgesamt führt das in Fig. 1 dargestellte Grundprinzip von Hardwarekomponenten H1..Hn mit integrierter Systemverbin­ dungseinheit 5 dazu, daß das Automatisierungssystem 1 offen und flexibel betrieben werden kann. Dies wird im folgenden auch mit dem Schlagwort "offene/verteilte Automatisierung" bezeichnet werden.

Fig. 2 zeigt ein weiteres Ausführungsbeispiel eines Automa­ tisierungssystems mit mehreren Bussystemen B1, B2, B3. Mit den ersten Bussystem B1 ist eine Hardwarekomponente H1 gekoppelt, die einen Motor M1 wie eine zugehörige Signalverarbeitungs­ einheit 5 enthält. Die Hardwarekomponente H1 ist darüber hi­ naus mit dem zweiten Bussystem B2 gekoppelt, welches mit ei­ nem Leitsystem 3 verbunden ist. Das Leitsystem 3 ist darüber hinaus mit dem dritten Bussystem B3 koppelbar. An das dritte Bussystem B3 ist ein Bedien- und Beobachtungssystem 6 sowie eine speicherprogrammierbare Steuerung 8 verbunden.

Die Hardwarekomponente H1, genauer gesagt die Systemverbin­ dungseinheit 5 der Hardwarekomponente H1 mit zugehörigem Sig­ nalverarbeitungsmitteln ist in der Lage über das erste B1 und das zweite B2 Bussystem Kommunikationsdaten zu übertragen bzw. zu empfangen. Darüber hinaus bildet die Systemverbin­ dungseinheit 5 auch eine Schnittstelle für einen Netzübergang zwischen dem ersten Bussystem B1 und dem zweiten Bussystem B2, beispielsweise für Kommunikationsdaten, die von einer mit dem Bussystem B1 gekoppelten Hardwarekomponente H2 an das Leitsystem 3 übertragen werden sollen. Hierzu weist die Sy­ stemverbindungseinheit 5 einen Speicher 9 zur Speicherung von für einen Netzübergang zwischen dem Bussystem B1 und dem Bus­ system B2 erforderlichen Protokollen auf. So ist beispiels­ weise auf einfache Weise ein Netzübergang zwischen einem so­ genannten Ethernet und einem sogenannten Profibus möglich. Die Hardwarekomponente H1 weist bei dem in Fig. 2 darge­ stellten Ausführungsbeispiel neben dem Vorteil einer offenen und verteilten Kommunikation zwischen der Hardwarekomponente H1 und beispielsweise dem Leitsystem 3 auch den weiteren Vor­ teil einer Schnittstellenanpassung für weitere Hardwarekompo­ nenten auf.

Fig. 3 zeigt eine schematische Darstellung des Aufbaus einer Systemverbindungseinheit 5 einer Hardwarekomponente H1..Hn, wie sie beispielsweise im Zusammenhang mit dem in Fig. 1 und Fig. 2 dargestellten Ausführungsbeispielen zum Einsatz kommt. Die Signalverbindungseinheit 5 enthält Funktionsobjek­ te D1, D2, D3 sowie Betriebssystemkomponenten 4A, 4B, ein Lauf­ zeitsystem 7 (Runtime-System) sowie eine Protokollverarbei­ tungseinheit 10 (Profibus, UDP/IP, RPC). Die Hardwarekompo­ nenten H1..Hn weist darüber hinaus weitere Datenobjekte D4..Dn auf, die als Datenobjekte D eines Anwenders eine zu­ sätzliche Anwenderfunktionalität kennzeichnen.

Die Funktionsobjekte D1..D3 sind beispielsweise als soge­ nannte DCOM-Objekte (Distributed Component Object Model) bzw. als sogenannte OLE-Objekte (Object Linking and Embedding) ausgebildet. Das erste Funktionsobjekt D1 dient der Erzeugung einer minimalen Funktionalität einer Hardwarekomponente. Das zweite Funktionsobjekt D2 dient zur Verschaltung von Objek­ ten, während das dritte Funktionsobjekt D3 zur Sammlung von in der Systemverbindungseinheit und/oder auf entfernten Sy­ stemverarbeitungseinheiten und/oder entfernten Rechnern vor­ handenen Objekten vorgesehen ist. Das zweite Funktionsobjekt D2 benutzt das Laufzeitsystem 7, um Verbindungen herzustel­ len. Das Laufzeitsystem 7 baut auf dem Remote Procedure Call RPC-Protokoll auf und ist eine dem RPC-Protokoll überlagerte Verwaltungseinheit, die eine Sicht auf lokale oder entfernte Objekte bzw. Interfaces mit Hilfe der RPC-Protokolle her­ stellt. Das besondere der Laufzeitschnittstelle 7 ist es, daß die Schnittstelle asynchron ausgebildet ist, d. h. nach Rück­ kehr der entsprechenden Funktion liegen die Ergebnisse, die von einem entfernten System zu liefern sind, noch nicht vor. Der Aufrufer, d. h. der Auslöser des Remote Procedure Calls muß daher die Adresse einer Variablen an das Laufzeitsystem 7 übergeben. Das Laufzeitsystem 7 verändert beim Eintreffen der Ergebnisse oder einem vorgebbaren Time-out den Wert einer be­ stimmten Quittungskomponente. Hierdurch wird dem Aufrufer mitgeteilt, ob die Operation erfolgreich abgeschlossen wurde oder fehlschlug. Der Vorteil der Asynchronität der Funktions­ schnittstelle des Laufzeitsystems des zweiten Datenobjekts D2 ist es, daß beispielsweise bei einer zyklischen speicherpro­ grammierbaren Steuerung mit einem strengen Zyklus der vorge­ gebene Zyklus eingehalten werden kann. Hierzu ruft das Anwen­ derprogramm in einem beliebigen Zyklus die Methode eines lo­ kalen bzw. entfernten Objekts, während das Ergebnis des Auf­ rufs beispielsweise per Flag im nächsten Zyklus abgefragt wird.

Die Registrierung von Hardwarekomponenten H1..Hn erfolgt in der Weise, daß mit Hilfe einer bestimmten Funktion, d. h. ei­ nes Befehls ein Interface sichtbar im Laufzeitsystem 7 anmel­ det. Das registrierte Interface ist danach für sogenannte "Clients" zugänglich. Künftige Aufrufe von derartigen Clients werden vom Laufzeitsystem 7 an die vorher übergebene Funktion weitergeleitet.

Die Systemverbindungseinheit 5 enthält Umsetzungsmittel zur Umsetzung zwischen Rechnerinformationsdaten und Daten auf einen Kommunikationsmedium. Dabei liegt die Verantwortung für eine derartige Umsetzung, d. h. für das sogenannte Marshaling beim jeweiligen Datenobjekt D1..Dn selbst. Die Datenobjekte D1..Dn müßten vor dem Aufruf einer entfernten Methode ent­ sprechend der Parametersignatur der jeweiligen Methode einen Puffer mit Werten füllen, der den Codierungsvorschriften von beispielsweise RPC bzw. DCOM gerecht wird. Entsprechendes gilt für die Rückgabe der Out-Parameter, die Entgegennahme der In-Parameter und die Entgegennahme von Out-Parametern.

Das DCOM-Runtime-System 7 stellt Funktionen für das Marsha­ ling einzelner Werte zur Verfügung.

Das DCOM-Runtime-System 7 stellt die Verbindungen zwischen Objekten auf unterschiedlichen Rechnern her. Für diese Auf­ gabe wird zum einen eine Liste von Interfaces verwaltet, die von lokalen Clients auf entfernten Rechnern beansprucht wer­ den, sogenannte importierte Interfaces. Zum anderen werden Listen mit Interfaces verwaltet, die lokale Server für ent­ fernte Clients zur Verfügung stellen, sogenannte exportierte Interfaces.

Fig. 4 zeigt ein abstraktes Geräteobjektmodel M für alle an einem offenen verteilten Automatisierungssystem teilnehmenden Komponenten OVA-Komponenten 13 (OVA-Device = Offene Verteilte Automatisierung). Das Geräteobjektmodel M besteht im wesent­ lichen aus einem allgemeinen Gerät A, welches als Systemde­ finition die über alle Geräte gleiche Funktionalität eines sogenannten OVA-Geräts (Offene Verteilte Automatisierung) be­ schreibt. Das allgemeine Gerät A wird durch die drei Funk­ tionsobjekte D1, D2, D3 realisiert. Das allgemeine Gerät A enthält weiter ein erweitertes Gerät E beschreibt alle Dien­ ste des Geräts, die eine bestimmte Geräteklasse, beispiels­ weise einen bestimmten Gerätetyp von speicherprogrammierbaren Steuerungen zusätzlich zum allgemeinen Objektmodell A anbie­ ten. Es wird über ein Objekt E1 (Extented Device) beschrie­ ben. Das Geräteobjektmodel M enthält weiter einen Bereich 14 für die einer OVA-Komponente 13 zugeordnete Anwenderfunktio­ nalität. Die Anwenderfunktionalität der Automatisierungsob­ jekte 13 kann dabei über ein weiteres Objekt 12, beispiels­ weise über ein sogenanntes ACAO-Interfaces (Active Control Application Object) beschrieben werden. Über das ACAO-Inter­ face bestehen Interfaces zu den Datenobjekten D4..Dn.

Das Objekt D1 (Common Device) stellt die allgemeine minimale Funktionalität eines Geräts zur Verfügung. Es hat eine für alle Geräte gleiche wohlbekannte Identifizierung und kann so­ mit einen externen Kommunikationspartner auch ohne Kenntnis über das eigentliche Gerät angesprochen werden. Das Objekt D1 ist sozusagen Anker für alle weiteren Objekte des Geräts, d. h. die auf dem Gerät lebenden Objekte können über das Ob­ jekt D1 bestimmt werden. Das Objekt D2 (ACCO = Active Control Connection Object) realisiert die Verschaltung von Automati­ sierungsobjekten, während das Objekt D3 (RT Automation Object) Verweise auf die Automatisierungsobjekte des Geräts enthält. Die besondere Funktion des Funktionsobjekts D3 be­ steht darin, die Summe der Funktionalität des Systems zu enu­ merieren, d. h. zu erfragen. Das erweiterte Gerät E beschreibt alle Dienste des Geräts, die eine bestimmte Geräteklasse, beispielsweise einen bestimmten Gerätetyp von speicherpro­ grammierbaren Steuerungen zusätzlich zum allgemeinen Objekt­ modell A anbieten. Es wird über das Objekt Extented Device E1 beschrieben.

Das Geräteobjektmodell ist gemäß Fig. 4 somit in einen Teil fester Funktionalität A sowie in einen Teil E mit variabler Funktionalität unterteilt. Die Funktionalität der Funktions­ objekte D2, D3 wird über das erste Funktionsobjekt D1 zu­ gänglich gemacht, während vom Funktionsobjekt D3 die weiteren Funktionsobjekte D4, .., Dn erfragbar und zugänglich sind. Die Funktionalität der Automatisierungsobjekte kann dabei über das ACAO-Interface 12 (Active Control Application Object) be­ schrieben werden.

Zusammenfassend betrifft die Erfindung somit ein Automatisie­ rungssystem 1 mit über mindestens ein Bussystem B1..B3 kop­ pelbaren Hardwarekomponenten H1..Hn, insbesondere Motoren, Sensoren, Aktuatoren, etc. Eine möglichst flexible und of­ fene Betriebsweise des Automatisierungssystems kann dadurch erzielt werden, die jeweils eine Systemverbindungseinheit mit Funktionsobjekten als Abbild der realen Funktionalität der Hardwarekomponenten aufweisen, wobei die Funktionsobjekte zum Zugriff auf die Funktionalität der Hardwarekomponenten über das Bussystem vorgesehen sind. Die Funktionsobjekte sind als DCOM-Objekte ausgebildet, so daß eine Nutzung der aus der Bürowelt bekannten Mechanismen zur Ausführung von verteilten Anwendungen möglich wird.

Claims (10)

1. Automatisierungssystem (1) mit über mindestens ein Bussy­ stem (B1..B3) koppelbaren Hardwarekomponenten (H1..Hn), ins­ besondere Motoren, Sensoren, Aktuatoren, etc., die jeweils eine Systemverbindungseinheit (5) mit Funktionsobjekten (D1..Dn) als Abbild der realen Funktionalität der Hardware­ komponenten (H1..Hn) aufweisen, wobei die Funktionsobjekte (D1..Dn) zum Zugriff auf die Funktionalität der Hardwarekom­ ponenten (H1..Hn) über das Bussystem (B1..B3) vorgesehen sind.

2. Automatisierungssystem nach Anspruch 1, dadurch gekennzeichnet, daß das Automatisierungssystem ein Leitsystem (3) und/oder eine Bedien- und Beobachtungssystem zum Zugriff auf die Funk­ tionsobjekte (D1..Dn) aufweist.

3. Automatisierungssystem nach einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, daß die Funktionsobjekte (D1..Dn) als DCOM-Objekte ausgebil­ det sind.

4. Automatisierungssystem nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Funktionsobjekte (D1..D3) mindestens ein erstes Funk­ tionsobjekt (D2) zur Erzeugung einer minimalen Funktionalität einer Hardwarekomponente (H1..Hn), mindestens ein zweites Funktionsobjekt (D2) zur Verschaltung von Funktionsobjekten und mindestens ein drittes Funktionsobjekt (D3) zur Sammlung von in der Systemverarbeitungseinheit (5) und/oder auf ent­ fernten Systemverarbeitungseinheiten und/oder entfernten Rechnern vorhandenen Funktionsobjekten (D1..Dn) aufweisen.

5. Automatisierungssystem nach einem der Ansprüche 1 bis 4, dadurch gekennzeichnet, daß das zweite Funktionsobjekt (D2) zur Beeinflussung von Verbindungen zwischen den auf entfernten Systemverbindungs­ einheiten und/oder auf entfernten Rechnern vorhandenen Funk­ tionsobjekten vorgesehen ist.

6. Automatisierungssystem nach einem der Ansprüche 1 bis 5, dadurch gekennzeichnet, daß durch das dritte Funktionsobjekt (D3) beim Zugriff auf die Systemverbindungseinheit ein dynamisches Abfrageobjekt generiert wird.

7. Automatisierungssystem nach einem der Ansprüche 1 bis 6, dadurch gekennzeichnet, daß das Automatisierungssystem eine ladbare Tabelle mit Co­ dierungsvorschriften aufweist.

8. Automatisierungssystem nach einem der Ansprüche 1 bis 7, dadurch gekennzeichnet, daß das Automatisierungssystem zum Zugriff auf die Funktiona­ lität der Hardwarekomponenten ein Leitsystem und/oder eine Bedien- und Beobachtungssystem aufweist.

9. Verfahren zum Zugriff auf die Funktionalität von Hardware­ komponenten (H1..Hn), insbesondere Motoren, Sensoren, Aktua­ toren, etc. eines Automatisierungssystems (1), bei dem die Kopplung der Hardwarekomponenten (H1..Hn) innerhalb des Auto­ matisierungssystems über mindestens ein Bussystem (B1..B3) erfolgt, wobei auf die Funktionalität der Hardwarekomponenten über das Bussystem mittels einer in der Hardwarekomponente integrierte Systemverbindungseinheit (5) mit Funktionsobjek­ ten (D1..Dn) als Abbild der realen Hardwarefunktionen zuge­ griffen wird.

10. Verfahren nach Anspruch 9, dadurch gekennzeichnet, daß in der Systemverbindungseinheit (5) über ein erstes Funk­ tionsobjekt (D1) eine minimalen Funktionalität einer Hard­ warekomponente (H1..Hn) erzeugt wird, daß über ein zweites Funktionsobjekt (D2) Funktionsobjekte (D1..Dn) miteinander verschaltet werden und daß über ein drittes Funktionsobjekt (D3) die in der Systemverarbeitungseinheit (5) und/oder auf entfernten Systemverarbeitungseinheiten und/oder auf entfern­ ten Rechnern vorhandene Funktionsobjekte (D1..Dn) aufgelistet werden.