DE10155586A1 - Automatisierungssystem, Technologiefunktionsplattform, Verfahren zum Betrieb eines Automatisierungssystems und Verwendung einer Technologiefunktionsplattform - Google Patents

Abstract

Bisher bekannte Automatisierungssysteme sind auf eine zentrale speicherprogrammierbare Steuerung hin ausgelegt und erweisen sich als für komplexe Regelungsalgorithmen unflexibel und uneffektiv betreibbar. Wird eine Technologiefunktionsplattform zur Einbindung in ein Automatisierungssystem mit einer weiteren Steuerung vorgeschlagen, welche Plattform einen Hardware-Aufbau und einen Software-Aufbau aufweist und wobei der Hardware-Aufbau und der Software-Aufbau weitgehend autark zur weiteren Steuerung zusammenwirken. Der Hardware-Aufbau weist eine CPU-Einheit, eine Speichereinheit und eine Schnittstelleneinheit auf und der Software-Aufbau ein Technologiefunktionsmodul aus einer Anzahl modular verbindbarer und anwendungsabhängig ausführbarer Technologiefunktionen und ein Betriebssystem, wobei das Technologiefunktionsmodul zur Verarbeitung in einem vom Betriebssystem organisierten anwendungsabhängigen Ablauf auf dem Hardware-Aufbau vorgesehen ist. Weiter ist ein entsprechendes Automatisierungssystem vorgesehen. Bei einem Verfahren zum Betrieb eines Automatisierungssystems wird in einem Konfigurationsschritt eine Technologiefunktionsplattform lediglich mit einer Anwendungs-Baugruppe verbunden, und der Technologiefunktion wird für die Anwendungs-Baugruppe spezifische Parameter zugewiesen. In einem Betriebsschritt arbeitet die Technologiefunktion auf der Technologiefunktionsplattform in einem von einem Betriebssystem organisierten anwendungsabhängigen Laufzeitplan weitgehend ...

Description

• Die Erfindung bezieht sich auf eine Technologiefunktionsplattform zur Einbindung als Steuerung in ein Automatisierungssystem mit einer weiteren Steuerung, welche Plattform einen Hardware-Aufbau und einen Software-Aufbau aufweist. Weiter bezieht sich die Erfindung auf ein Automatisierungssystem mit einer weiteren Steuerung, einer Anzahl von Anwendungsbaugruppen, einem Netzteil, einem Engineering-System und einer Datenkommunikationsperipherie. Die Erfindung führt auch auf ein Verfahren zum Betrieb eines Automatisierungsystems mit einer Steuerung, aufweisend ein Konfigurations- und einen Betriebsschritt sowie eine Verwendung einer Technologiefunktionsplattform.
• Bei der Automatisierung von Maschinen und Anlagen mit SPS war es bisher üblich, für komplexere Regelungsvorgänge wie z. B. Temperaturregelung, Positionierung oder Nockenschaltwerk, spezielle Hardware-Komponenten bzw. Sonderbaugruppen einzusetzen. Diese Baugruppen weisen jeweils für die entsprechende Aufgabe spezialisierte Hardware und Software auf. Solche Hardware-Komponenten werden auch als intelligente Baugruppen bezeichnet, da sie vom Prozeß kommende Signale unabhängig von der Zentral-CPU bzw. SPS aufbereiten, verarbeiten und dann entweder wieder an den Prozeß zurückgeben oder der CPU zur Verfügung stellen. Sie übernehmen dabei Aufgaben, die die CPU meist nicht schnell genug ausführen kann und entlasten dadurch die CPU.
• Solche Automatisierungssysteme sind bekannt aus der Patentschrift EP 0 852 031 B1 oder dem Aufsatz "Automatisieren mit Simatic", Hans Berger, ISBN 3-89578-132-0, Seiten 34 ff.
• Mit der Einführung der internationalen Programmiersprachnorm für SPS EN61131 und der steigenden Leistungsfähigkeit der SPS-CPU wird in neuerer Zeit die Umsetzung solcher Technologiefunktionen oder anderer algorithmischer Anwendungen zur Lösung von anwendungsspezifischen Aufgabenstellungen durch Software-Bibliotheken umgesetzt, die auf der SPS-CPU als Teil des Anwenderprogramms abgearbeitet werden.
• Solche Lösungen sind vorgeschlagen worden in "Automatisieren mit Simatic", Hans Berger, ISBN 3-89578-132-0 (Seite 34 ff), APP-RTT-E-D Regelungstechnik-Toolbox, Moeller, AWB 2700-1319, 7/99 und APP-HLKT-S-D Applikationssoftware HLK-Toolbox, Moeller, AWB 7920-1351, 3/99. Ein Beispiel findet sich auch in APP-POS-S-D Sucosoft-S40- Applikationssoftware, Positionier-Toolbox, Moeller, 09/00, AWB 2700-1400D.
• Die anwendungsspezifischen Steuer- und Regelfunktionen sind dabei modular als Funktionen und Funktionsmodule realisiert, so daß auf dieser Basis je nach Anwendungsfall ein komplettes Steuerungs- und Regelungssystem zusammengestellt werden kann. Oft sind solche Bibliotheken auch hierarchisch aufgebaut. Für den beispielhaften Fall der Regelungstechnik bietet z. B. die untere Ebene Grundfunktionen (Interpolation, Mittelwertbildung, . . .), die nächste Ebene Grundfunktionen der Regelungstechnik (Integratoren, Differenzierglieder, . . .), die nächste Ebene höhere Funktionen der Regelungstechnik (z. B. PID-Regler) und die oberste Ebene komplette Technologiefunktionsmodule wie z. B. Dosierregler für die Verpackungsindustrie oder Temperaturregler von Extrudern.
• Solch eine Bibliothek ist beispielsweise beschrieben in APP-RTT-E-D Regelungstechnik- Toolbox, Moeller, AWB 2700-1319, 7/99.
• Für den Fall, daß zur Lösung Funktionsbaugruppen oder andere spezielle Hardware- Komponenten verwendet werden, ergeben sich Nachteile dadurch, daß der Aufwand der Steuerungs- und Regelungsseite erheblich ist, falls die Produkte an geänderte Verhältnisse von Maschinen angepaßt werden müssen. Oft sind bei solchen Änderungen auch neue Hardware-Komponenten erforderlich. Insgesamt müssen sowohl die Anwendungsprogramme auf der SPS als auch die Technologiebaugruppen geändert werden, was insgesamt hohe F & E- Kosten aber auch Logistikaufwand sowohl auf der Seite der Hersteller (neue Produkte, Pflege, Lager) als auch beim Anwender (neue Stücklisten, Pflege alter Maschinen, Lager) nach sich zieht.
• Werden die Anforderungen durch modulare Software-Technik gelöst, ergeben sich Nachteile für die SPS. Zum einen arbeiten SPS zyklisch ein Anwendungsprogramm ab. Hierbei werden i. d. R. alle Software-Module des Programms durchlaufen und dabei Aktionen angestoßen bzw. Ergebnisse abgefragt. Diese Art der Programmierung hat sich für die ursprüngliche Anwendungen einer SPS, nämlich Ersatz von festverdrahteten E/A-Komponenten bewährt, jedoch ist diese nur bedingt für algorithmische Lösungen geeignet. Weiterhin sind die üblicherweise in SPS verwendeten Sprachen AWL, KOP, FUP auf einfache Datentypen hin, wie z. B. Bits und logische Operationen darauf, wie z. B. AND bzw. Schiebeoperationen optimiert. Anforderungen, z. B. aus der Regelungstechnik mit Fest- oder Gleitkomma Datentypen inklusive Übertragungsrechnung zu hantieren, werden nur schlecht gelöst. Dies resultiert in einer oft umständlichen und aufwendigen Programmierung, die damit zu längeren Abarbeitungszeiten und in der Folge zu längeren Zykluszeiten der SPS führt.
• Darüber hinaus muß nun die SPS-CPU neben der eigentlichen Anwendung auch noch eine oder sogar mehrere Technologiefunktionen abarbeiten. Dadurch wird die für Maschinen oft kritische Zykluszeit und der Anwendungsspeicher stark belastet. Beides sind Ressourcen, die heute nach dem Stand der Technik in klassischen SPS oft nur begrenzt vorhanden und daher teuer sind. Es entfallen zwar dadurch Funktionsbaugruppen oder andere spezielle Hardware- Komponenten, andererseits werden höherwertige SPS-CPU (Speicher, Geschwindigkeit) als bisher notwendig, um z. B. die für die Maschine notwendige Zykluszeit einzuhalten. Bei den sogenannten Soft-SPS, die auf PC ablauffähig sind, spielen Speicher und Geschwindigkeit keine Rolle, da beides gegenüber klassischen SPS'en ausreichend vorhanden ist. Jedoch kann in der industriellen Praxis davon ausgegangen werden, daß nur sogenannte Industrie-PC's zum Einsatz kommen. Dies sind speziell für den rauhen Einsatz (Temperatur, Feuchte, Rütteln, Bauformen, Echtzeit, . . .) ausgebildete Rechner, die preislich deutlich oberhalb von heute üblichen Standard-SPS liegen.
• Je nach Anwendungsfall und Maschinenaufbau werden Funktionen der SPS auch dezentralisiert. Dies entspricht dem Stand der Technik, Funktionen dort haben zu wollen, wo diese benötigt werden. Sowohl bei der Lösung mit Funktionsbaugruppen als auch durch modulare Software-Techniken werden die Daten dabei zwar dezentral erfaßt, müssen jedoch über Feldbusse oder andere Kommunikationswege in die SPS transportiert werden, dort vom Kommunikationsprozessor an den Anwendungsprozessor übergeben werden, um endlich in der Anwendung verarbeitet werden zu können. Diese abhängig von einer zentralen Steuerung bewirkten Art der Verarbeitung hat mehrere Nachteile:
  
• - Durch die verschiedenen asynchronen Vorgänge (SPS-Zyklus, Zyklus Kommunikationsprozessor, Zyklus Feldbus, Zyklus dezentrale E/A-Baugruppe) sowie die Buslaufzeit ergeben sich hohe Reaktionszeiten. Eine beispielhafte Berechnung findet sich z. B. in Siemens S7-300 EWA 4NEB 710 6084-01, Kapitel Zyklus- und Reaktionszeiten der S7-300. Als allgemeine Regel läßt sich sagen:
  
  Reaktionszeit = Summe aller asynchronen Zeiten × 2;
• - Je mehr Daten über den Feldbus transportiert werden müssen und je mehr Teilnehmer am Bus angeschlossen sind, desto stärker wird de Feldbuszyklus zeitlich belastet. Dies bedeutet ggf. höhere Übertragungsgeschwindigkeiten, was i. d. R. kleinere Busausdehnungen zur Folge hat oder weitere Feldbusstränge in der SPS, was zusätzliche Kosten und Engineering-Aufwand bedeutet.
• Bei allen vorbekannten Automatisierungssystem nimmt die SPS also eine zentrale Rolle ein. Die SPS ist zentral im Automatisierungssystem angeordnet und ist Auftraggeber für Anweisungen, Taktung und Parametervergabe an Baugruppen, ob nun als Hardware oder Software. Zudem arbeitet eine SPS gemäß dem Stand der Technik in der Regel zyklisch und ist für allgemeine algorithmisch geprüfte Anforderungen bei zeitgemäßen Anwendungsprofilen nicht oder nur mit erhöhtem Aufwand, wie oben erläutert, betreibbar.
• Hier setzt die Erfindung an, deren Aufgabe es ist, eine Technologiefunktionsplattform und ein Automatisierungssystem sowie ein Verfahren zum Betrieb eines Automatisierungssystems und eine Verwendung einer Technologiefunktionsplattform anzugeben, was es ermöglicht, das Steuern und Regeln von Maschinen und Anlagen flexibler und effektiver zu gestalten.
• Zur Lösung der Aufgabe ist bei einer Technologiefunktionsplattform der eingangs genannten Art gemäß einer ersten Variante der Erfindung vorgesehen, daß der Hardware-Aufbau und der Software-Aufbau weitgehend autark zur weiteren Steuerung zusammenwirken. Insbesondere ist die weitere Steuerung eine speicherprogrammierbare Steuerung.
• Gemäß einer weiteren Variante der Erfindung ist vorgesehen, daß bei einer Technologiefunktionsplattform der eingangs genannten Art der Hardware-Aufbau eine CPU-Einheit, eine Speichereinheit und eine Schnittstelleneinheit aufweist und der Software-Aufbau ein Technologiefunktionsmodul aus einer Anzahl modular verbindbarer und anwendungsabhängig ausführbare Technologiefunktionen und ein Betriebssystem aufweist, wobei das Technologiefunktionsmodul zur Installation mittels des Betriebssystems im Rahmen einer vorgegebenen Anwenderumgebung und zur Verarbeitung in einem vom Betriebssystem organisierten anwendungsabhängigen Ablauf auf dem hardware-Aufbau vorgesehen ist. Insbesondere ist die weitere Steuerung eine speicherprogrammierbare Steuerung.
• Die vorgeschlagene Technologiefunktionsplattform ist also weitgehend autark zu einer weiteren Steuerung, insbesondere weitgehend autark zu einer zentralen speicherprogrammierbaren Steuerung, einsetzbar. D. h., eine Technologiefunktionsplattform nach der Erfindung ist auch universell einsetzbar. Eine weitgehend autarke Wirkungsweise umfaßt also insbesondere die folgenden Einsatzmöglichkeiten einer Technologiefunktionsplattform. Sie könnte beispielsweise einer zentralen Steuerung, insbesondere einer zentralen speicherprogrammierbaren Steuerung, nebengeordnet sein. Sie könnte dabei der Steuerung zuarbeiten und auch gleiche Aufgaben wie diese übernehmen, also parallel zu dieser prozessieren. Eine Technologiefunktionsplattform könnte auch eine zentral angeordnete Steuerung, insbesondere eine zentral angeordnete speicherprogrammierbare Steuerung ersetzen. Außerdem könnte sie auch aufgrund ihrer weitgehend autarken Wirkungsweise dezentral zu solch einer Steuerung eingesetzt werden. In allen Fällen ist eine Anzahl oder auch eine Vielzahl von solchen Technologiefunktionsplattformen, welche im Verbund parallel prozessieren, möglich. Insbesondere ist bei einem weiter unten erläuterten Automatisierungssystem nach der Erfindung ein Netz von parallel und für sich autark arbeitenden Technologiefunktionsplattformen vorteilhaft vorgesehen.
• Die Einheiten des Hardware-Aufbaues und des Software-Aufbaues einer Technologiefunktonsplattform, wie in der zweiten Variante der Erfindung definiert, sind, insbesondere im Unterschied zu einer zentralen speicherprogrammierbaren Steuerung, entsprechend einer weitgehend autarken und insbesondere universell vorgesehenen Wirkungsweise der vorgeschlagenen Technologiefunktionsplattform ausgelegt. Eine CPU-Einheit ist vorgesehen, insbesondere eine für Echtzeitprozessierung geeignete CPU. Eine CPU und Speichereinheit sind außerdem entsprechend den Anforderungen größen- und leistungsmäßig ausgelegt. Eine Schnittstelle eines Schnittstellensystems weist sowohl Eingangs- (E) als auch Ausgangs- (A) Merkmale auf, so daß überhaupt ein Ansprechen von Anwendungseinheiten möglich ist. Ein Schnittstellensystem ist also im wesentlichen als ein E/A-System ausgelegt. Insbesondere ist ein Feldbus-Anschluß bei solch einem Schnittstellensystem vorteilhaft zur direkten Anbindung einer Anwendungseinheit vorgesehen. Es könnte auch PC bzw. im allgemeinen ein Engineering-System direkt an eine Technologiefunktionsplattform angeschlossen werden und zur Parametrisierung und anderweitigen Steuerung während des Betriebs derselben dienen. Ein Speicher der vorgeschlagenen Technologiefunktionsplattform ist jedenfalls teilweise als ein Permanent- und/oder Hintergrundspeicher ausgelegt, so daß auch bei einem Aus/Einschalten nur die Funktionsplattform bzw. einer dieselbe umfassenden Einheit, die auf ihr gespeicherten Parameter und sonstigen Daten erhalten bleiben. Die vorgeschlagene Technologiefunktionsplattform ist also selbständig bootbar. Sie braucht bei einem Hochfahren eines Automatisierungssystems, in das sie eingebunden ist, nicht notwendigerweise von einer zentralen Steuerung, insbesondere speicherprogrammbieren Steuerung, initialisiert werden. Außerdem weist die vorgeschlagene Technologiefunktionsplattform ein entsprechend ausgelegtes Betriebssystem auf. Ein solches Betriebssystem weist insbesondere auch ein Datei- und Verwaltungssystem auf, um Auswahl und Ladevorgang eines Technologiefunktionsmoduls mit verschiedensten Funktionsmodulen zu bewerkstelligen. Ein solches Betriebssystem ist also nicht, wie üblicherweise, ausschließlich zum Prüfen und Speichern einer Firmware vorgesehen, sondern weist darüber hinaus Verwaltungs- und Taktungseigenschaften im Rahmen eines anwenderbezogen auszuführenden Algorithmuses auf.
• Eine Technologiefunktionsplattform arbeitet vorzugsweise algorithmusbezogen und nicht notwendigerweise zyklisch wie eine speicherprogrammierbare Steuerung gemäß dem Stand der Technik. Während nämlich eine SPS üblicherweise zyklisch programmiert ist, ist eine vorgeschlagene Technologiefunktionsplattform gemäß eines beliebigen Algorithmus entsprechend einer Anwendung, vorteilhaft in einer dafür jeweils geeigneten Hochsprache programmiert. Dies führt zu einer Wirkungsweise der Technologiefunktionsplattform, die besonders angepaßt ist für zeitgemäße Algorithmen der Regelungstechnik sowie der dafür notwendigen Datentypen, Zyklen bzw. Zeittaktungen, ereignisorientierten Uhrzeit oder freiprogrammierbaren Start/Stop-Anweisungen und Verknüpfungen. Insbesondere erlaubt eine Technologiefunktionsplattform jeder Technologiefunktion eines Technologiefunktionsmoduls, eine separate Abarbeitungsvorschrift und/oder Prioritäten zuzuweisen. Insbesondere ist eine Technologiefunktionsplattform aufgrund ihrer Auslegung multitaskingfähig.
• Eine Installation eines Technologiefunktionsmoduls ist mittels des Betriebssystems im Rahmen einer vorgegebenen Anwenderumgebung vorgesehen. Dies führt zu einer besonders leichten Handhabung und gleichzeitig flexiblen Einsetzbarkeit der Technologiefunktionsplattform im Rahmen vorgegebener Grenzen. Während nämlich eine SPS in der Regel frei programmierbar ist, im Rahmen eines Programmiersystems, was beispielsweise das Debuggen und andere für eine Programmierung typische Funktionen vorsieht, so steht die freie Programmierbarkeit einer Technologiefunktionsplattform zu Gunsten einer Anwenderfreundlichkeit nicht an erster Stelle. Die autarke und universelle Einsetzbarkeit der Technologiefunktionsplattform ist im Rahmen vorgegebener und im wesentlichen durch das Betriebssystems und die vorgegebene Anwenderumgebung festgelegten Bereichen besonders einfach möglich. Dem Anwender wird also eine Oberfläche der Anwenderumgebung zur Verfügung gestellt, die es ihm ermöglicht, ein Technologiefunktionsmodul zu installieren. Das heißt, ein vorteilhaft in einer Hochsprache bereits programmiertes Technologiefunktionsmodul kann in einer ausführungsfähigen Form auf die Technologiefunktionsplattform geladen werden. Dazu kann eine Bibliothek zur Auswahl eines Technologiefunktionsmoduls zur Verfügung gestellt werden. Es ist vorgesehen, daß das Betriebssystem und die Anwenderumgebung das Diagnostizieren einer Anwenderfunktion und eine dementsprechende Parametrisierung des Technologiefunktionsmoduls bzw. der Technologiefunktion erlaubt. Die Technologiefunktionsplattform ist also ausgelegt, um in einem Konfigurationsschritt die Installation und Parametrisierung einer Technologiefunktion durch den Anwender auf besonders einfache und fehlerfreie Art und Weise zu ermöglichen. Eine Programmierung muß vom Anwender in der Regel nicht mehr vorgenommen werden, sondern wird ihm durch eine entsprechende Dienstleistung, beispielsweise bewirkt durch Softwarelieferung im Rahmen einer Bestellung oder eines Internetangebots, zur Verfügung gestellt. Das Betriebssystem und die Anwenderumgebung der Technologiefunktionsplattform erlauben dementsprechend eine breite Palette von Einbindungsmöglichkeiten für eine Technologiefunktion für eine ebenso breite und flexible Palette von Anwendungen. Somit ist eine vorgeschlagene Technologiefunktionsplattform also auf einfache Weise und gleichzeitig universell einsetzbar.
• Die Erfindung führt weiter auf ein eingangs genanntes Automatisierungssystem, bei dem erfindungsgemäß eine Technologiefunktionsplattform, insbesondere nach einer der hier erläuterten Ausführungen, vorgesehen ist, auf der eine Anzahl von von einem Permanentspeicher abrufbarer Technologiefunktionen zum weitgehend zur Steuerung autarken Ausführen vorgesehen sind.
• Die Erfindung führt auch auf ein Verfahren zum Betrieb eines Automatisierungssystems mit einer Steuerung, aufweisend einen Konfigurations- und einen Betriebsschritt, bei dem erfindungsgemäß im Konfigurationsschritt einer Technologiefunktionsplattform eine Technologiefunktion mittels eines Betriebssystems im Rahmen einer vorgegebenen Anwenderumgebung installiert wird, der Technologiefunktion für eine Anwendungs-Baugruppe spezifische Parameter zugewiesen werden und im Betriebsschritt die Technologiefunktion auf der Technologiefunktionsplattform in einem von einem Betriebssystem organisierten anwendungsabhängigen Laufzeitplan weitgehend autark zur Steuerung abgearbeitet wird.
• Insbesondere ist im Konfigurationsschritt eine Technologiefunktionsplattform mit einer Anwendungsbaugruppe verbunden.
• Gemäß der Erfindung ist auch eine Verwendung einer Technologiefunktionsplattform bei einem Automatisierungssystem mit einer Steuerung, autark zur Steuerung vorgesehen. Dabei kann die Technologiefunktionsplattform, wie hier erläutert, und das Automatisierungssystem, wie hier erläutert, ausgeführt sein. Insbesondere eignet sich auch die Verwendung einer Technologiefunktionsplattform gemäß der Erfindung dezentral zur Steuerung des Automatisierungssystems.
• Die vorliegende Erfindung hat erkannt, daß im Unterschied zum Stand der Technik mit der Erfindung ein Automatisierungssystem, eine Technologiefunktionsplattform und ein Verfahren zum Betrieb eines Automatisierungssystems und eine Verwendung einer Technologiefunktionsplattform für das Steuern und Regeln von Maschinen und Anlagen, insbesondere aufweisend eine speicherprogrammierbare Steuerung (SPS), angegeben ist, mit dem ohne Veränderung der Hardware und der Basis-Software die Steuerungskonfiguration und der Leistungsumfang des Automatisierungssystems einfach an die Anforderungen einer konkreten Anwendung anpaßbar ist. Diese Anpassungen können vom Benutzer ohne Systemkenntnisse und unter Verwendung von Basismodulen vorgenommen werden. Dabei wird ein SPS- Anwendungsprogramm nicht zusätzlich belastet. Das System kann darüber hinaus nicht nur eine, sondern auch mehrere Technologiefunktionen aufnehmen. Weiterhin sind sowohl fertige Technologiefunktionen, wie z. B. Positionieren, die nur noch parameterisiert werden müssen, als auch modulare Software-Bibliotheken, mit denen ohne Programmierung Anwendungsmodule erstellt werden können, ablauffähig.
• Eine Technologiebaugruppe, umfassend die Plattform und/oder das Modul, kann dabei als zentrale Baugruppe ausgeführt sein und dabei eine oder mehrere Funktionsbaugruppen ersetzen. Weiterhin kann die Erfindung auch als dezentraler Feldbusteilnehmer ausgeführt sein, wobei die Aufgabe, z. B. Positionierung, dann vor Ort durchgeführt werden kann.
• Zusätzlich kann die Baugruppe eine Plattform oder ein Modul auch autark zu einer SPS-CPU arbeiten, so daß damit sowohl die Entwicklung als auch die Inbetriebnahme einer Maschine modularisiert und parallelisiert werden kann.
• Die Erfindung weist eine ganze Reihe an Vorteilen gegenüber bisher üblichen Hardware oder Software implementierten Technologiefunktionen bei einem Automatisierungssystem auf.
• So bestehen erhebliche Kundenvorteile. Es kann auf bisher verwendete steckbare Funktionsbaugruppen/Hardware-Komponenten verzichtet werden. Der Hardware-Aufwand wird entsprechend kostengünstiger.
• SPS-Anwenderprogramme werden kleiner, übersichtlicher und dadurch schneller in der Abarbeitung. Dadurch können Kosten gespart werden, da i. d. R. kleinere SPS-CPU's verwendet werden können, bzw. es ergeben sich höhere Maschinentakte und damit eine effizientere Produktion.
• Bessere Ausführungsergebnisse, da z. B. die Algorithmen in einer adäquaten Hochsprache (z. B. C, C++ oder Ähnliches) geschrieben werden können und nicht in AWL.
• Durch die Verbindung von Mechanik, Elektronik, und der Erfindung können leicht mechantronische Komponenten gebildet werden, die wiederverwendbare und herstellerunabhängige Komponenten darstellen, da die Erfindung auch autark zur SPS-CPU arbeiten kann. Das hilft Entwicklungs- und Engineering-Kosten sparen. Diese bilden heute mit ca. 60% den größten Kostenanteil einer Maschine/Anlage.
• Wird die Erfindung dezentral ausgeführt, ergeben sich schnellere Feldbuszyklen, da weniger Daten über den Feldbus transportiert werden müssen. Dadurch sind einerseits bessere Reaktionsgeschwindigkeiten und höhere Taktraten der Maschine möglich. Andererseits kann auch eine niedrigere Übertragungsrate verwendet werden, mit dem Vorteil einer größeren physikalischen Ausdehnung des Busses.
• Weitere sind Herstellervorteile zu nennen. Es muß nur eine einmalige Entwicklung einer Basis-Hardware und zugehöriger Firmware durchgeführt werden.
• Es erfolgt eine schnellere Umsetzung von Anforderungen, da z. B. die Algorithmen in einer adäquaten Hochsprache (z. B. C, C++ oder Ähnliches)geschrieben werden können (und nicht in AWL) und dafür keine spezielle Hardware-Entwicklung mehr notwendig ist.
• Es kann unter Beibehaltung der Hardware und der SPS-Anwendung flexibel auf geänderte Anforderungen an der Maschine oder auf spezielle Kundenwünsche reagiert werden.
• Im einzelnen sind Weiterbildungen der Erfindung den Unteransprüchen zu entnehmen.
• Bei einer Technologiefunktionsplattform ist vorteilhaft die Anzahl der Technologiefunktionen als eine hierarchisch aufgebaute Bibliothek von Software-Modulen vorgesehen. Dabei kann eine Technologiefunktion als ein Basis-, Funktions- oder Organisations-Sofiware-Modul vorliegen. Funktionsmodule können z. B. für Interpretationen ausgebildet sein. Basismodule könnten Grundschritte der Automatisierung ausführen, z. B. PID-Regelfunktionen, Analogwerterfassungen etc. Als Organisations-Software-Modul könnte eine Technologiefunktion auch komplexere Steuerungen einer Maschine vornehmen. Insbesondere gerade für hochkomplexe dynamische Regelvorgänge bei Maschinen ist eine Technologiefunktionsplattform und entsprechende Technologiefunktionen, wie vorgeschlagen, geeignet.
• Das Betriebssystem ist vorteilhaft als ein Echtzeitbetriebssystem entsprechend einer Anwendung ausgelegt.
• Eine Schnittstelleneinheit umfaßt eine oder mehrere Schnittstellen, die insbesondere direkt zu einer Anwendungseinheit angekoppelt werden können. Dabei kann auch die Ankopplung eines Engineering-Systems oder einer weiteren Steuerung, insbesondere einer speicherprogrammierbaren Steuerung vorgesehen sein. Eine Technologiefunktionsplattform, wie vorgeschlagen, ist also vorteilhaft voll an eine Umgebungsperipherie angebunden, so daß sie autark zu einer zentralen Steuerung arbeiten kann. D. h., sie kann dieser zentralen Steuerung nebengeordnet, dezentral zu ihr angeordnet sein oder sie auch ersetzen.
• Vorteilhaft weist eine Schnittstelleneinheit auch einen integrierten Feldbus-Anschluß auf, was sich insbesondere für schnelle Anwendungen eignet. Vorteilhaft ist ein Schnittstellensystem, jedenfalls aber ein Großteil der Schnittstellen als E/A-Schnittstelle ausgelegt. Die Technologiefunktion ist für komplizierte Algorithmen der Regeltechnik geeigneterweise in einer Hochsprache programmiert.
• Der Hardware-Aufbau einer Technologiefunktionsplattform weist vorteilhaft wenigstens einen Permanentspeicher und/oder einen Arbeitsspeicher auf.
• Gemäß einer besonders bevorzugten Ausführung kann eine Technologiefunktionsplattform auch eine integrierte Anwendungsbaugruppe umfassen, insbesondere eine integrierte E/A- Baugruppe.
• Im folgenden werden bevorzugte Ausführungsformen der Erfindung im Vergleich zum Stand der Technik beschrieben. Dabei ist zu berücksichtigen, daß vielfältig Modifikationen und Änderungen betreffend Form und Detail einer Ausführungsform vorgenommen werden können, ohne von der allgemeinen Idee der Erfindung abzuweichen. Die in der vorstehenden Beschreibung, in der Zeichnung sowie in den Ansprüchen offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung wesentlich sein. Die allgemeine Idee der Erfindung ist nicht beschränkt auf die exakte Form oder das Detail der im folgenden gezeigten und beschriebenen bevorzugten Ausführungsformen oder beschränkt auf einen Gegenstand, der eingeschränkt wäre im Vergleich zu dem in den Ansprüchen beanspruchten Gegenstand. Ausführungsbeispiele und Ausführungsformen der Erfindung werden anhand der Zeichnung beschrieben. Diese soll die Ausführungsformen nicht notwendig maßstäblich darstellen; vielmehr ist die Zeichnung wohl zur Erläuterung dienlich in schematischer und/oder leicht verzerrter Form ausgeführt. Im Hinblick auf Ergänzungen, der aus der Zeichnung unmittelbar erkennbaren Lehren, wird auf den einschlägigen Stand der Technik verwiesen. Im einzelnen zeigen die Figuren der Zeichnung in:
• Fig. 1 ein Automatisierungssystem gemäß dem Stand der Technik mit Hardware- Technologiebaugruppen;
• Fig. 2 eine Prinziparchitektur einer Technologiefunktionsplattform bei einem schematisch dargestellten Automatisierungssystem gemäß einer bevorzugten Ausführungsform;
• Fig. 3 eine Prinziparchitektur eines Hardware-Aufbaus, insbesondere eines Technologiefunktions-Bausteins bei einer Technologiefunktionsplattform und seine Anbindung an ein Engineering-System, eine SPS-Anwendung und E/A-Baugruppen gemäß einer bevorzugten Ausführungsform;
• Fig. 4 eine Prinziparchitektur eines Software-Aufbaus, insbesondere ein Technologiefunktionsmodul für eine Technologiefunktionsplattform gemäß der Erfindung und seine Anbindung an eine SPS-Baugruppe, E/A-Baugruppen und einem Engineering-System gemäß einer bevorzugten Ausführungsform;
• Fig. 5 ein erstes Ausführungsbeispiel eines Automatisierungssystems mit zentral angeordneter universeller Technologiebaugruppe;
• Fig. 6 ein weiteres Ausführungsbeispiel eines Automatisierungssystems mit zentral angeordneter universeller Technologiebaugruppe mit lokalem Feldbusanschluß;
• Fig. 7 noch ein weiteres Ausführungsbeispiel eines Automatisierungssystems mit dezentral angeordneten universellem Technologieteilnehmer mit lokal angeschlossenen E/A- Baugruppen.
• In Fig. 1 ist ein Aufbau eines Automatisierungssystem gemäß dem Stand der Technik gezeigt. Bei diesem vorbekannten Automatisierungssystem 10 werden in einem Einschubsystem 101 mehrere Funktionsbaugruppen 13, 14 oder andere spezielle Hardware-Komponenten verwendet. U. a. ist auch ein Netzteil 11 sowie eine speicherprogrammierbare Steuerung (SPS) mit CPU 12 vorgesehen. Die Technologiebaugruppen 13, 14 und die SPS/CPU 12 sind u. a. mittels einer Kommunikations/Feldbusbaugruppe 15, zum Beispiel einem Profibus-DP mit E/A-Baugruppen 16 verbunden. Die SPS/CPU 12 ist beim Stand der Technik zentral angeordnet. Signifikante Nachteile entstehen dadurch, daß der Aufwand der Steuerungs- und Regelungsseite erheblich ist, falls das Automatisierungssystem 10 an geänderte Verhältnisse von Maschinen angepaßt werden muß. In der Regel sind bei solchen Änderungen neue Hardware-Komponenten oder Technologiebaugruppen 13, 14 oder noch weitergehende Änderungen am Automatisierungssystem 10 erforderlich.
• Außerdem ist eine Programmier/Inbetriebnahmeeinheit, beispielsweise ein PC eines Engineering-Systems 17 mit einer Daten/Kommunikationsverbindung PC/SPS 18 vorgesehen. Neben Änderungen oder gar einem Austausch von Hardware-Komponenten sind zudem gegebenenfalls auch Anwendungsprogramme auf der SPS 12 als auch auf den Technologiebaugruppen 13, 14 zu ändern. Eine solche Änderung könnte über die Einheit 17 erfolgen. Dies ist aufgrund einer oft umständlichen und aufwendigen Programmierung der Software in der Regel mit erheblichem Aufwand verbunden. Insgesamt können bei einem solchen Automatisierungssystem 10 gemäß dem Stand der Technik hohe F & E-Kosten, aber auch Logistikaufwand sowohl auf der Seite der Hersteller als auch beim Anwender, veranschlagt werden.
• Die Nachteile werden nicht allein dadurch behoben, daß die als Hardware ausgebildeten Technologiebaugruppen 13, 14 durch modulare Software-Technik ersetzt werden. Nach wie vor bleiben die Nachteile hinsichtlich der umständlichen Programmierung, einer unnötig hohen starken Auslastung der Kommunikationsverbindungen 18 und die unflexible Handhabung lediglich im Rahmen einer zentralen Anordnung der SPS 12 und der Technologiebaugruppen 13, 14, ob nun Software oder Hardware ausgebildet, bestehen.
• Ein Ausführungsbeispiel der Erfindung sieht gemäß Fig. 2 eine universelle Plattform vor, welche fertig gelöste Technologiefunktionen wie z. B. Positionierung, Temperaturregelung, Wegerfassung, Nockenschaltwerk, Dosierregelung etc. dynamisch aufnehmen oder abarbeiten kann. Technologiefunktionen TF24a, TF24b, TF24c liegen in einem auf der Plattform ausführbaren Format vor und sind im Hintergrundspeicher 25 abgelegt. Aus dem Engineering- System kann der Anwender eine oder mehrere Technologiefunktionen auswählen und über eine Kommunikationsverbindung 27 der Plattform 21 laden. Dort wird die Funktion inklusive der Parameter in einem permanent ausgebildeten Speicher 33 in Fig. 3 gesichert.
• Jede Technologiefunktion beinhaltet dabei alle Mechanismen und Funktionen, die für die Anwendung der Technologie erforderlich sind. Die Plattform 21 kann mehrere solcher voneinander unabhängiger Technologiefunktionen aufnehmen 24a, 24b, 24c. Dabei ist es auch möglich, ein und dieselbe Technologiefunktion 24a mehrfach und unabhängig 24a, 24b und 24c voneinander über 23 zu starten, wenn dies in der Anwendung erforderlich ist, z. B. für die Positionierung mehrerer unabhängiger Achsen.
• Jeder Technologiefunktion werden in einem Konfigurationsschritt auf dem Engineering- System 26 die notwendigen Parameter und das notwendige E/A zugewiesen. Die Plattform 21 muß zu diesem Zweck Zugriff über 22 auf E/A-Baugruppen haben. Je nach Ausprägung kann das ein lokaler Peripheriebus/Rückwandbus 22 sein wie in den Fig. 5 und 7 oder auch dezentrale Teilnehmer an einem Feldbus, der unmittelbar an der Plattform 21 angeschlossen ist wie in der Fig. 6.
• Es ergibt sich eine Architektur eines Technologiefunktionsbausteins gemäß des Ausführungsbeispiels, die in Fig. 3 schematisch dargestellt ist. Die CPU arbeitet das zugrundeliegende Echtzeitbetriebssystem und die geladenen Technologiefunktionen 24a, 24b, 24c ab. Handelt es sich bei einer Technologiefunktion um einen Regler der auf Standard-Regelungsfunktionen wie z. B. P-Algorithmus (Regler mit Proportionalcharakter), PI-Algorithmus (Regler mit Proportional-Integralcharakter) oder PID-Algorithmus (Regler mit Proportional-Integral- Differentialcharakter) basiert, arbeitet diese üblicherweise als zeitdiskreter Abtastregler. Die Technologiefunktion wird dazu in einem festgelegten Abtastintervall betrieben, wobei die Technologiefunktion jeweils zu den Abtastzeitpunkten aktiviert wird. Alternativ kann auch die jeweilige Abtastzeit ermittelt und der Technologiefunktion 24a, 24b, 24c als Parameter mitgegeben werden. Diese wird dann in den o. g. Regelalgorithmen verarbeitet. Die Verwaltung und die geschilderte Abarbeitung (zeitdiskrete oder alternativ) von Technologiefunktionen 24a, 24b, 24c ist Aufgabe des Echtzeitbetriebssystems 23. Zur Abarbeitung einer Technologiefunktion wird diese aus dem Hintergrundspeicher 33 in den Arbeitsspeicher 32 kopiert. Zum Zugriff auf das E/A-System 312 stellt das Betriebssystem 23 Zugriffsfunktionen zur Verfügung, die von der Technologiefunktion gerufen werden können, um Daten vom E/A-System 312 zu lesen oder auf die Peripherie zu schreiben. Für extrem schnelle Zugriffe kann die Plattform auch ein integriertes E/A 36 zur Verfügung stellen. Die 36 kann z. B. ein SSI-Geber sein, der zur Umsetzung von Nockenschaltwerken oder zur Positionierung benötigt wird. Damit eine Technologiefunktion 24a, 24b, 24c zur Laufzeit gestartet, gestoppt oder parameterisiert werden kann, ist vorgesehen, in der SPS 30 dazu passende Schnittstellen 35, 38 in Form von Funktionsbausteinen 35 bereitzustellen. Diese besitzen keine Intelligenz, sondern führen nur die Kommunikation zwischen der SPS-Anwendung und einer Technologiefunktion durch. Dazu kommuniziert eine SPS-Anwendung 313 über eine SPS-Schnittstelle 35 und tauscht passend für eine spezielle Technologiefunktion Daten aus. Zusätzlich dient die Schnittstelle 38 auch dazu, Daten zwischen der Technologiefunktion und dem übergeordneten an der SPS angeschlossenen Engineering-System 39 wie in Fig. 5 z. B. zur Parameterisierung oder Inbetriebnahme auszutauschen.
• Liegt das von einer Technologiefunktion benötigte E/A räumlich von der Erfindung entfernt wie in Fig. 7 gezeigt, z. B. wegen der Geometrie einer Maschine/Anlage, kann es sinnvoll sein, dieses E/A über einen Feldbus 310 an einen Feldbusanschluß 37 einzubinden. Dieser ist der E/A-Schnittstelle 34 untergeordnet, so daß die Zugriffsfunktionen für die Anwendung verdecken, wo und mit welchen Mechanismen auf das geforderte E/A zugegriffen wird. Daneben kann die Erfindung aber auch selber als dezentrale Einheit 611 arbeiten wie in Fig. 6, um z. B. das Datenvolumen zu reduzieren. Auch in diesem Fall ist ein Feldbusanschluß notwendig, der hier jedoch der SPS-Schnittstelle 25 untergeordnet ist und damit der Kommunikation zwischen SPS-Anwendung 313 und Technologiefunktion dient.
• Nützlich kann auch eine von der SPS separate Kommunikationsschnittstelle 38 sein, mittels der Technologiefunktionen unmittelbar und unter Umgehung der SPS mit einem Engineeringsystem 39 kommunizieren können. Ebenso kann es vorteilhaft sein, über diese Schnittstelle 38 Visualisierungsgeräte anzuschließen, mit denen der Zustand der Technologiefunktion gezielt überwacht oder auch verändert werden kann.
• In Fig. 4, die schematisch den Aufbau und Einzelheiten eines erfindungsgemäßen Technologiefunktionsmoduls zeigt, bezeichnet 41 das eigentliche Technologiefunktionsmodul zur Bearbeitung einer Technologiefunktion mit Basis- und Funktionsmodulen 45a, 45b, 45c und 45d. Selbstverständlich ist dies ein Beispiel, und es können weniger oder mehr gleichartige und verschiedenartige Basis-, Funktions- und Organisations-Module verwendet werden. Die Basis-, Funktions- und Organisations-Module 45a-d werden über einen internen Parameterspeicher 43 in dem Technologiefunktionsmodul und einem Kommunikationsdatenspeicher 44 mit den für den Ablauf notwendigen Daten versorgt. Hierbei handelt es sich um Adressen, Parameter, Ist-Werte, Kurven etc. Der Parameterspeicher 43 wird dabei aus dem Engineering- System gefüllt. Der Kommunikationsdatenspeicher 44 wird beidseitig sowohl von Funktionsbausteinen der SPS 413 als auch von den Basis-, Funktions- und Organisations-Modulen 45a-d beschrieben und gelesen. Beispielsweise liefert ein Verwaltungssystem als Teil eines Betriebssystems 23 Taktraten und/oder Start/Stop-Anweisungen oder andere Anweisungen zur anwendergerechten Ausführung des Technologiefunktionsmoduls 41 an die Basis-, Funktions- und/oder Organisationsmodule 45a-d.
• Die Basis-, Funktions- und Organisations-Module sind modular als Funktionen und Funktionsmodule realisiert und untereinander datenflußmäßig verbunden werden. Dabei können die Module den internen Datenspeicher zur Speicherung von Daten, gegebenenfalls auch remanent oder zur Kommunikation untereinander nutzen. Neben der Datenverschaltung ist auch die Realisierung eines Ablaufs notwendig. Hierfür stehen sprachliche Mittel z. B. in Form der Ablaufsprache, bekannt aus der Norm EN 61131-3, zur Verfügung.
• Die Eingänge 48 und Ausgänge 47, 48 des Technologiefunktionsmoduls bilden sich auf Ein- bzw. Ausgänge eines verwendeten Bausteins ab. Das Laufzeitsystem verbindet diese über das E/A-System mit physikalischen Baugruppen 412, 413, 46, so daß damit der Zugriff auf die Prozeßperipherie gegeben ist.
• Insgesamt ergibt sich aufbauend auf der universellen Plattform eine flexible und durchgängige Technologielösung, in der beliebig aufgebaute Technologiebausteine ablauffähig sind. Damit können komplette Steuerungs- und Regelsysteme für beliebige Technologien realisiert werden, die sowohl die Funktionalität als auch die Schnelligkeit der bekannten Lösungen mit speziellen Baugruppen bzw. SPS-Funktionsbibliotheken übertreffen.
• Die Fig. 5 zeigt ein bevorzugtes Ausführungsbeispiel eines Automatisierungssystem 50. Bei diesem ist in einem Einschubsystem 53 ein Netzteil 51 sowie als weitere Einheiten eine SPS- CPU-umfassende speicherprogrammierbare Steuerung 52 vorgesehen sowie eine oder mehrere E/A-Baugruppen 55. Das Einschubsystem weist auch weitere Plätze für noch weitere Einheiten und Baugruppen auf. In der Peripherie ist ein Programmier/Inbetriebnahme-PC 56 vorgesehen. Dieser ist Teil eines Engineering-Systems 56 zur Programmierung und Inbetriebnahme des Automatisierungssystems 50. Das Engineering-System 56 ist mit der SPS-CPU 52 über eine Daten/Kommunikationsverbindung 57 verbunden. Über diese Verbindung läuft die Kommunikation zwischen PC 56 und SPS 52. Die SPS-CPU-Einheit 52 kann beispielsweise eine Siemens-Simatic 57-300- oder eine Moeller-PS-416-Einheit sein.
• Als wesentlicher Teil dieses Automatisierungssystem 50 gemäß des bevorzugten Ausführungsbeispiels ist eine universelle Technologiebaugruppe 58 vorgesehen, welche eine Technologiefunktionsplattform, wie beschrieben, umfaßt. Die universelle Technologiebaugruppe 58 ist bei diesem Ausführungsbeispiel zentral angeordnet. Der Zugriff der in der Technologiebaugruppe 58 untergebrachten Technologiefunktionsplattform auf die E/A-Baugruppen 55 und weitere Verbindungen zwischen den Einheiten 51 bis 58 des Automatisierungssystems 50 erfolgt bei diesem Ausführungsbeispiel über einen lokalen Peripheriebus/Rückwandbus im Einschubsystem 53.
• Ein ähnlich wie in Fig. 5 ausgestaltetes Automatisierungsystem 60 ist in Fig. 6 gezeigt. Dieses weist, wie bereits in Fig. 5, ein Netzteil 61, eine SPS-CPU-Einheit 62, eine oder mehrere E/A-Baugruppen 65 in einem Einschubsystem 63 auf. In der Peripherie ist ein Programmier-Inbetriebnahme-PC 66 als Teil eines Engineering-Systems 66 über eine Daten/Kommunikationsverbindung 67 an die SPS-CPU-Einheit 62 angeschlossen. Im Unterschied zu dem in Fig. 5 dargestellten Automatisierungssystem 50 weist dieses Automatisierungssystem 60 jedoch eine universelle Technologiebaugruppe 68 auf, die einen lokalen Feldbusanschluß 610 umfaßt. An diesem Feldbus 610 könnte irgendein dezentraler Teilnehmer unmittelbar an die eine Technologiefünktionsplattform aufweisende universelle Technologiebaugruppe 68 angeschlossen werden. Dies könnte beispielsweise eine weitere E/A- Baugruppe sein. Dies könnte allerdings auch ein weiterer universeller Technologieteilnehmer 711 sein, was im weiteren in Fig. 7 dargestellt ist. Die universelle Technologiebaugruppe 68des Automatisierungssystem 60 ist beim Ausführungsbeispiel der Fig. 6 nämlich, wie auch beim Ausführungsbeispiel des Automatisierungssystems 50 in Fig. 5. zentral geschaltet.
• Gemäß Fig. 7 könnte ein Automatisierungssystem auch dezentral ausgelegt sein. Ein dezentral ausgelegtes Automatisierungssystem 70 weist wiederum in einem Einschubsystem 73 ein Netzteil 71, eine SPS-CPU-Einheit 72 sowie eine oder mehrere E/A-Baugruppen 75 auf. In der Peripherie sind wiederum ein Programmier/Inbetriebnahme-PC 76 als Teil eines Engineering-Systems 76 vorgesehen, welcher über eine Daten/Kommunikationsverbindung 77 an die SPS-CPU-Einheit 72 angeschlossen ist. Die Kommunikation/Feldbusbaugruppe 79 könnte in diesem Fall eine Kommunikations/Feldbusbaugruppe gemäß der Erfindung sein. Es könnte also eine universelle Technologiebaugruppe 58 oder 68, wie in den Fig. 5 und 6 und im weiteren oben beschrieben, sein. Es könnte allerdings auch eine konventionelle Baugruppe, welche ausschließlich als Kommunikations- und Feldbusbaugruppe wirkt, nämlich beispielsweise eine Profibus-DP sein. An diese Art von Baugruppen 79 ist gemäß dem Ausführungsbeispiel in Fig. 7 ein universeller Techologieteilnehmer 711 über eine Kommunikations/Feldbusleitung 710 angeschlossen. Dieser universelle Technologieteilnehmer 711 könnte also beispielsweise als universelle Technologiebaugruppe 68 oder 58 also als Technologiefunktionsplattform, gemäß den Ausführungsbeispielen in den Fig. 6 und 5 sowie weiter oben beschrieben, ausgebildet sein und/oder eine entsprechende universelle Technologiefunktionsplattform umfassen. An diesen universellen Technologieteilnehmer 711 sind gemäß dem dezentral ausgelegten Automatisierungssystem 70 nunmehr weitere lokale E/A- Baugruppen 712 angeschlossen.
• Die vorgenannten Ausführungsbeispiele eignen sich insbesondere zur Steuerung und zum automatisierten Betrieb von intelligenten Feldgeräten, also z. B. zum automatisierten Betrieb von MMI, Leistungsschaltern oder Antrieben oder Motorstartern, also einer Vielzahl von intelligenten Anwendungen, bei denen die Intelligenz in Form von Funktionsmodulen vor Ort herunter ladbar sein sollte.
• Die in der vorstehenden Beschreibung, in den Zeichnungen sowie in den Ansprüchen offenbarten Merkmale der Erfindung können sowohl einzeln als auch in beliebiger Kombination für die Verwirklichung der Erfindung wesentlich sein. Bezugszeichenliste 10 Automatisierungssystem; StdT
  11 Netzteil; StdT
  12 SPS-CPU; StdT
  13, 14 Technologiebaugruppen, z. B. Temperaturregler, Positionierung, Nockenschaltwerk, StdT
  15 Kommunikations/Feldbusbaugruppe, z. B. Profibus-DP; StdT
  16 E/A-Baugruppen, zentral; StdT
  17 Programmier/Inbetriebnahme-PC (Engineering System); StdT
  18 Daten/Kommunikationsverbindung PC - SPS; StdT
  19 Feldbus; StdT
  101 Einschubsystem
  21 Technologiefunktionsplattform (Erfindung)
  22 Hardware-Ebene mit Zugriff auf E/A-System, Kommunikationsschnittstellen
  23 Echtzeitbetriebssystem mit Ablaufsystem für Technologiefunktionen
  24 Technologiefunktionen, z. B. Positionierung, Temperaturregelung, Wegerfassung, Nockenschaltwerk, Dosierregelung
  25 Hintergrundspeicher
  26 Programmier/Inbetriebnahme-PC (Engineering-System)
  27 Daten/Kommunikationsverbindung PC - SPS
  30 Technologiefunktionsbaustein
  31 CPU
  32 Arbeitsspeicher (RAM)
  33 Permanenter Hintergrundspeicher (Flash, gepuffertes SRAM, NvRam, . . .)
  34 Schnittstelle E/A-System
  35 Schnittstelle SPS
  36 Integriertes E/A (optional)
  37 Integrierter Feldbusanschluß (optional)
  38 Kommunikationsschnittstelle (optional)
  312 E/A-Baugruppen
  39 Bedienungsgerät/Engineering SW
  310 Feldbus zur Anbindung einer E/A
  313 SPS-Anwendung
  41 Technologiefunktionsmodul
  42 Interner Datenspeicher
  43 Parameterdaten
  44 Kommunikationsdaten
  45a-d Basis- und Funktionsmodule
  48 Eingänge
  47 Ausgänge
  45 Programmier/Inbetriebnahme-PC (Engineering-System)
  412 E/A-Baugruppen, E/A-System
  413 SPS-Anwendung oder Betriebssystem
  50 Automatisierungssystem
  51 Netzteil
  52 SPS-CPU
  53 Einschubsystem
  55 E/A-Baugruppen
  56 Programmier/Inbetriebnahme-PC (Engineeering-System)
  57 Daten/Kommunikationsverbindung PC-SPS
  58 Universelle Technologiebaugruppe (Erfindung)
  60 Automatisierungssystem
  61 Netzteil
  62 SPS-CPU
  63 Einschubsystem
  65 E/A-Baugruppen
  66 Programmier/Inbetriebnahme-PC (Engineering-System)
  67 Daten/Kommunikationsverbindung PC-SPS
  68 Universelle Technologiebaugruppe (Erfindung) mit lokalem Feldbusanschluß
  610 Kommunikations/Feldbusleitung
  70 Automatisierungssystem
  71 Netzteil
  72 SPS-CPU
  73 Einschubsystem
  75 E/A-Baugruppen
  76 Programmier/Inbetriebnahme-PC (Engineering-System)
  77 Daten/Kommunikationsverbindung PC-SPS
  78 Kommunikations/Feldbusbaugruppe, z. B. Profibus-DP
  710 Kommunikations/Feldbusleitung
  711 Universeller Technologieteilnehmer (Erfindung) mit lokalem E/A
  712 Lokale E/A-Baugruppen
  

Claims (17)

1. Technologiefunktionsplattform zur Einbindung als Steuerung in ein Automatisierungssystem mit einer weiteren Steuerung, welche Plattform einen Hardware-Aufbau und einen Software-Aufbau aufweist, dadurch gekennzeichnet, daß der Hardware-Aufbau und der Software-Aufbau weitgehend autark zur weiteren Steuerung zusammenwirken.

2. Technologiefunktionsplattform zur Einbindung als Steuerung in ein Automatisierungssystem mit einer weiteren Steuerung, welche Plattform einen Hardware-Aufbau und einen Software-Aufbau aufweist dadurch gekennzeichnet, daß der Hardware-Aufbau eine CPU-Einheit, eine Speichereinheit und eine Schnittstelleneinheit aufweist und der Software-Aufbau ein Technologiefunktionsmodul aus einer Anzahl modular verbindbarer und anwendungsabhängig ausführbarer Technologiefunktionen und ein Betriebssystem aufweist, wobei das Technologiefunktionsmodul zur Installation mittels des Betriebssystems im Rahmen einer vorgegebenen Anwendungsumgebung und zur Verarbeitung in einem vom Betriebssystem organisierten anwendungsabhängigen Ablauf auf dem Hardware-Aufbau vorgesehen ist.

3. Technologiefunktionsplattform nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die weitere Steuerung eine speicherprogrammierbare Steuerung ist.

4. Technologiefunktionsplattform nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß die Anzahl der Technologiefunktionen als eine hierarchisch aufgebaute Bibliothek von Software-Modulen vorliegt.

5. Technologiefunktionsplattform nach Anspruch 4, dadurch gekennzeichnet, daß die Technologiefunktion als ein Basis-, Funktions- oder Organisations-Sofiware-Modul vorliegt.

6. Technologiefunktionsplattform nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß das Betriebssystem als ein Echtzeitbetriebssystem ausgelegt ist.

7. Technologiefunktionsplattform nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Schnittstelleneinheit eine oder mehrere Schnittstellen direkt zu einer Anwendungseinheit, einem Engineering-System oder der weiteren Steuerung aufweist.

8. Technologiefunktionsplattform nach Anspruch 7, dadurch gekennzeichnet, daß die Schnittstelleneinheit einen integrierten Feldbusanschluß aufweist.

9. Technologiefunktionsplattform nach Anspruch 7 oder 8, dadurch gekennzeichnet, daß eine Schnittstelle E/A-Funktionen hat.

10. Technologiefunktionsplattform nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Technologiefunktion einen in einer Hochsprache geschriebenen Algorithmus aufweist.

11. Technologiefunktionsplattform nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, daß die Speichereinheit einen Permanentspeicher und/oder einen Arbeitsspeicher aufweist.

12. Technologiefunktionsplattform nach einem der vorhergehenden Ansprüche, gekennzeichnet durch eine integrierte Anwendungs-Baugruppe, insbesondere eine integrierte E/A-Baugruppe.

13. Automatisierungssystem mit einer weiteren Steuerung, einer Anzahl von Anwendungs- Baugruppen, einem Netzteil, einem Engineering-System und einer Datenkommunikationsperipherie, gekennzeichnet durch eine Technologiefunktionsplattform, insbesondere nach einem der vorhergehenden Ansprüche, auf der eine Anzahl von von einem Permanentspeicher abrufbarer Technologiefunktionen zum weitgehend zur Steuerung autarken Ausführen vorgesehen sind.

14. Verfahren zum Betrieb eines Automatisierungssystems mit einer Steuerung, aufweisend einen Konfigurations- und einen Betriebsschritt, dadurch gekennzeichnet, daß im Konfigurationsschritt einer Technologiefunktionsplattform eine Technologiefunktion mittels eins Betriebssystems im Rahmen einer vorgegebenen Anwenderumgebung installiert wird, der Technologiefunktion für eine Anwendungs-Baugruppe spezifische Parameter zugewiesen werden und im Betriebsschritt die Technologiefunktion auf der Technologiefunktionsplattform in einem von dem Betriebssystem organisierten anwendungsabhängigen Laufzeitplan weitgehend autark zur speicherprogrammierbaren Steuerung abgearbeitet wird.

15. Verfahren nach Anspruch 14, dadurch gekennzeichnet, daß im Konfigurationsschritt eine Technologiefunktionsplattform mit einer Anwendungsbaugruppe verbunden wird.

16. Verwendung einer Technologiefunktionsplattform, insbesondere nach einem der Ansprüche 2 bis 12, bei einem Automatisierungssystem mit einer Steuerung, insbesondere bei einem Automatisierungssystem nach Anspruch 13, autark zur Steuerung.

17. Verwendung einer Technologiefunktionsplattform nach Anspruch 16 dezentral zur Steuerung des Automatisierungssystems.