-
Die Erfindung betrifft ein System zur Steuerung einer fördertechnischen Anlage und ein in einem solchen System ablauffähiges Verfahren.
-
Herkömmliche Systeme zur Steuerung fördertechnischer Anlagen bestehen, wie es in 1 dargestellt ist, aus einer dreistufigen Hierarchie von Rechnern, nämlich einem übergeordneten Leitrechner 1, auch Host genannt, einem Lagerverwaltungs- und Materialflussrechner 2 (LVR/MFR), sowie einer Speicherprogrammierbaren Steuerung 3 (SPS). In diesem Zusammenhang wird die mittlere Schicht der dreistufigen Hierarchie auch als Middleware bezeichnet. Die SPS 3 ist über einen Feldbus 4, wie beispielsweise PROFIBUS®, mit den Komponenten der fördertechnischen Anlage 5, d. h. mit Sensoren, die Zustandssignale aus der Anlage liefern, und mit Aktoren, die Transportvorgänge in der Anlage 5 bewirken bzw. beeinflussen, verbunden. Ein typisches Beispiel für eine fördertechnische Anlage 5 ist ein automatisches Hochregallager, das mit einer Vielzahl von Regalbediengeräten und Verfahrwagen zur Ein- und Auslagerung von Warenträgern ausgerüstet ist. Untereinander sind der Host 1, der LVR/MFR 2 und die SPS 3 über ein lokales Datennetzwerk 6 (LAN) miteinander verbunden.
-
Auf dem Host 1 laufen Programme eines unternehmensweiten Informationssystems zur übergeordneten Planung des Einsatzes von Unternehmensressourcen (ERP für Enterprise Resource Planning). Ein besonders weit verbreitetes ERP-Programm ist beispielsweise SAPIR3®. Daher wird nachfolgend beispielhaft vom Einsatz eines ERP-Programms des Herstellers SAP® ausgegangen, jedoch kann die vorliegende Erfindung grundsätzlich ebenso auf Systeme angewendet werden, die ein ERP-Programm eines anderen Herstellers verwenden.
-
Der Datenaustausch zwischen zwei Rechnern innerhalb eines Systems der hier interessierenden Art erfolgt durch Übertragung der Daten in Form von Telegrammen auf der Basis definierter Regeln, genannt Protokolle. Diese Protokolle beschreiben die Übertragungstechnik, Reihenfolge, Aufbau und Inhalt von Telegrammen. Beispiele für solche Protokolle sind TCP/IP, RFCIO06, R3964 und TIM. Nach dem Stand der Technik ist es großenteils nicht möglich, zwischen einem auf einem Host 1 laufenden ERP-Programm und einer im Echtzeitbetrieb arbeitenden SPS 3 Telegramme zum Zweck der Ansteuerung einer fördertechnischen Anlage 5 auf der Basis von standardisierten Protokollen direkt auszutauschen. Hierzu müssten beide Systeme zur Kommunikation über ein- und dasselbe Protokoll in der Lage sein, was nach dem Stand der Technik oftmals nicht der Fall ist.
-
So ist beispielsweise seitens des im ERP-Bereich führenden Softwareherstellers SAP@ für die Kommunikation mit untergeordneten Rechnern das sog. RFC-Protokoll (Remote Function Call) vorgesehen. Um die Integration von Partnersoftware zu erleichtern, wird eine Funktionsbibliothek zur Verfügung gestellt, die in die Partnersoftware eingebunden werden kann und die zur Kommunikation mit dem auf dem übergeordneten Host 1 laufenden ERP Programm notwendigen Programmbausteine enthält. Diese Bibliothek steht für verschiedene Betriebssysteme zur Verfügung, nicht jedoch für Echtzeitbetriebssysteme der Art (z. B. RMOS3), wie sie bei einer SPS 3 notwendigerweise eingesetzt werden müssen.
-
Ein wesentlicher Grund hierfür ist die derzeit in der Fachwelt herrschende Meinung, dass von einem Host 1, auf dem ERP-Anwendungen laufen, keine zeitkritischen Aufgaben wahrgenommen werden können, da ERP-Anwendungen einschließlich ihres externen Datenaustauschs mit untergeordneten Rechnern üblicherweise keinen sog. harten Echtzeitbedingungen unterliegen und daher für die Einbindung von echtzeitfähigen Modulen zu langsam sind. Hierbei bewegen sich typische Transaktionszeiten bei einer im Echtzeitbetrieb arbeitenden SPS 3 im Millisekundenbereich, während solche Transaktionszeiten bei einem ERP-Host 1 in der Größenordnung von bis zu einer Sekunde liegen.
-
Der direkte Anschluss einer echtzeitfähigen SPS 3 an einen ERP-Host 1 ist derzeit großenteils technisch nicht möglich, insbesondere beim Einsatz eines ERP-Programms des führenden Herstellers SAP@. Hierzu wird vielmehr eine Zwischenschicht, nämlich die Middleware 2 benötigt, welche die Umsetzung der Protokolle sowie eine gewisse Aufbereitung der übertragenen Daten übernimmt. Die Middleware 2 umfasst eigene Rechner (LVR/MFR) mit Betriebssystem und eigener Datenhaltung. Zu den Funktionen der Middleware 2 zählt zunächst die Umsetzung der zu übermittelnden Daten zwischen den verschiedenen Protokollen, d. h. die Verbindung der ERP-Welt (typisches Protokoll: RFC) mit der SPS-Welt 2 (typische Protokolle: TCP/IP, RFCIO06) hinsichtlich der reinen Datenübermittlung. Diese Funktion wird üblicherweise als ”Gateway” bezeichnet.
-
Über die reine Protokollwandlung hinaus übernehmen die Softwaremodule der Middleware 2 im Bereich der Steuerung fördertechnischer Anlagen 5 noch weitere Funktionen von wesentlicher Bedeutung wie beispielsweise
- – Speichern von Nachrichten zum Zweck der Statistik und Fehleranalyse,
- – Speichern von Nachrichten zum Zweck des Wiederanlaufs nach einer Störung,
- – Darstellung von Anlagenzuständen für Bedienpersonal (Visualisierung),
- – erweiterte Funktionen zur Steuerung des Materialflusses.
-
Ein typisches Beispiel für die letztgenannte Art von Funktionen ist die Verwaltung von Auftragswarteschlangen im Fall der Erzeugung einer Vielzahl von Transportaufträgen im Host 1, die von der zu steuernden fördertechnischen Anlage 5 wegen Ressourcenkonflikten nicht simultan, sondern nur sequentiell abgearbeitet werden können. Es versteht sich, dass gerade die vorausgehend beispielhaft aufgeführten Zusatzfunktionen eine eigene permanente Datenhaltung von nicht unerheblichem Umfang in der Middleware 2 erfordern.
-
Ein Beispiel für eine Datenübertragung zwischen einem Host 1 und einer SPS 3 unter Vermittlung durch Middleware 2 ist in 2 dargestellt. Aus einer ERP-Anwendung heraus wird auf dem Host 1 ein Datensatz erzeugt, der eine Bewegung auf einer fördertechnischen Anlage 5 verursacht. Hierzu wird der Datensatz mittels ERP-Standardprotokollen an die Middleware 2 übertragen. Ein Verarbeitungsprogramm der Middleware 2 empfängt die Daten gemäß dem ERP-Protokoll (z. B. WM-LSR-Schnittstelle von SAP@) und speichert den Datensatz lokal in einer eigenen Datenbank ab. Die Daten werden nun in der Middleware 2 an eine Verarbeitungsroutine übergeben, die ein Telegramm gemäß dem verwendeten SPS Kommunikationsprotokoll aufbaut und ab speichert. Ein Sendeprogramm der Middleware 2 übernimmt die als ”Neu” markierten Datensätze und sendet das Telegramm an die SPS 3.
-
Entsprechende Programmbausteine der SPS 3 übernehmen nun den Empfang sowie die weitere Verarbeitung der Telegrammdaten und steuern die fördertechnische Anlage 5 an. Um die Middleware 2 davon zu unterrichten, dass das Telegramm ordnungsgemäß empfangen wurde, sendet die SPS 3 ein Antworttelegramm, die sog. ”Logische Quittung” an die Middleware 2 zurück. Die Middleware 2 empfängt das Quittungstelegramm und protokolliert den Empfang in ihrer eigenen Datenbank. Damit wird sichergestellt, dass bereits an die SPS 3 gesendete Telegramme nicht noch einmal übertragen werden, andererseits können die von der SPS 3 nicht oder fehlerhaft verarbeiteten Telegramme von der Middleware 2 wiederholt übertragen werden.
-
Zur Abwicklung eines kompletten von dem ERP-Programm im Host 1 initiierten Auftrags wird über das Datennetzwerk 6 eine Vielzahl von Telegrammen auf die zuvor beschriebene Weise ausgetauscht, wobei die SPS 3 nicht nur den Empfang von Telegrammen mit eigenen Telegrammen quittiert, sondern auch von sich aus Telegramme, beispielsweise mit Status und/oder Fertigmeldungen zu bearbeiteten Aufträgen, absendet. Beispielhaft ist in 3 der Ablauf der Bearbeitung eines Kundenauftrags, zu dessen Erfüllung der Host 1 einen Transportauftrag zur Auslagerung einer Palette aus einem Hochregallager erteilen muss, in tabellarischer Form wiedergegeben. Dabei widerspiegelt die fortlaufende Nummerierung in der äußersten linken Spalte die zeitliche Abfolge der einzelnen Prozessschritte. Die Bezeichnungen der Prozessschritte und der zugehörigen Aktionen in den bei den nächsten Spalten sind selbsterklärend. In den drei rechten Spalten ist jeweils markiert, welche Aktion von welchem der drei beteiligten Rechner ausgeführt wird, und wie dabei Datentelegramme zwischen den verschiedenen Rechnern übermittelt werden.
-
Aus der
DE 103 16 288 A1 ist eine Vorrichtung zur Datenübertragung bekannt. Die Vorrichtung zur Datenübertragung ermöglicht den Zugriff von einer Remote-Einrichtung über einen Standard-Browser auf eine oder mehrere Automatisierungs-Einrichtungen. Zwischen die Remote-Einrichtung und die oder jede Automatisierungs-Einrichtung ist eine Datenumwandlungs-Einrichtung geschaltet, wobei die oder jede Automatisierungs-Einrichtung mit der Datenumwandlungs-Einrichtung sowie gegebenenfalls die Automatisierungs-Einrichtung untereinander Daten nach einem ersten Kommunikationsprotokoll austauschen, wobei die Datenumwandlungs-Einrichtung und die Remote-Einrichtung Daten nach einem zweiten Kommunikationsprotokoll austauschen, und wobei die Datenumwandlungs-Einrichtung die Daten des ersten Kommunikationsprotokolls in Daten des zweiten Kommunikationsprotokolls umwandelt
-
Aus der
DE 102 51 502 A1 ist ein Feldgerät für die Prozessautomatisierung zum Erfassen und/oder Beeinflussen einer Prozessvariablen mit zwei Kommunikationsschnittstellen bekannt, wobei die erste Kommunikationsschnittstelle zur Verbindung mit einem ersten Feldbus und die zweite Kommunikationsschnittstelle zur Verbindung mit einem zweiten Datenbus dient und im Feldgerät eine Protokollumsetzung für Daten, die zwischen beiden Feldbussen übertragen werden, erfolgt.
-
Aus der
EP 1 612 630 A1 ist ein System zur Erleichterung der Kommunikation zwischen unterschiedlichen Automatisierungsgeräten bekannt, bei dem eine Eingangskomponente Kommunikationsdaten von einem ersten Automatisierungsgerät erhält, eine Ausgangskomponente mit einem zweiten Automatisierungsgerät kommuniziert und eine Übersetzungskomponente ein erstes mit dem ersten Gerät assoziiertem Protokoll in ein zweites Protokoll umwandelt, das mit dem zweiten Gerät assoziiert ist.
-
Aus der
DE 102 27 422 A1 ist ein Umwandler mit einem an einem externen Datenbus anschließbaren Kopfteil und einem oder mehreren daran im Wege einer reihenförmigen Steckmontage anschließbaren Anschlussmodul bekannt. Das Kopfteil weist einen Steckanschluss mit einem internen Datenbus zugeordneten Steckkontakten auf; jedes Anschlussmodul weist einen zum Steckanschluss des Kopfteiles passenden Gegensteckanschluss auf; Gegensteckkontakte des Gegensteckanschlusses sind mit Schaltungsanschlusskontakten zum Anschluss eines eine elektronische Schaltung aufweisenden Schaltungsträger und mit Steckkontakten zum Anschluss der Gegensteckkontakte eines weiteren Anschlussmoduls verbunden; jedes Anschlussmodul weist mindestens einen Geräteanschluss auf zum Anschluss eines Aktors oder eines Sensors, der über den internen und externen Bus mit einer mit dem externen Bus verbindbaren Steuereinrichtung kommuniziert. Dieser Umwandler soll dadurch einfacher herstellbar sein, aber gleichzeitig eine erforderliche Robustizität aufweisen, dass die Steckverbindung der Anschlussmodule untereinander bzw. das Steckmodul an dem Kopf sowie die Steckzuordnung der Schaltungsträger wasserdicht sind.
-
Aus der Firmenschrift INAT ECHOLINK Seriell-Ethernet-Konverter, Nürnberg, 2004, Seiten 1 bis 35 des Unternehmens INAT GmbH ist die Kommunikation zwischen einer Ethernet Workstation und einer seriell an einer echolink Station angeschlossenen Steuerung in den verschiedenen Varianten gezeigt, wobei die Daten aus dem Ethernet kommend über die echolink Station an den jeweiligen folgenden Datenbus der Steuerung übergeben bzw. empfangen werden.
-
Aus der
US 2006/0133412 A1 ist eine Architektur zur Integration der Steuerung und Unternehmenssysteme und/oder Anwendungen ohne die Verwendung einer Zwischenanwendung (sogenannte middleware) bekannt.
-
Aus der
US 2005/0267882 A1 ist ein System zur Ermöglichung einer direkten Kommunikation zwischen einer Leitebene zur Ressourcenplanung und Steuerungsebene bekannt.
-
Der vorliegenden Erfindung liegt die Aufgabe zugrunde, ein hierarchisches System zur Steuerung einer fördertechnischen Anlage gemäß dem vorausgehend beschriebenen Stand der Technik zu vereinfachen, ohne dabei substantielle Abstriche am Funktionsumfang zu machen.
-
Diese Aufgabe wird erfindungsgemäß durch ein System mit den Merkmalen des Anspruchs 1 sowie durch ein Verfahren mit den Merkmalen des Anspruchs 5 gelöst. Vorteilhafte Ausgestaltungen sind in den jeweiligen Unteransprüchen angegeben.
-
Die Erfindung sieht vor, die mittlere Ebene der herkömmlichen dreistufigen Hierarchie vollständig zu eliminieren und ihre Funktionen auf die beiden verbleibenden Ebenen, nämlich auf den Host 1 und die SPS 3 zu verteilen, und zwar vorteilhaft dergestalt, dass sämtliche Funktionen, die eine permanente Datenhaltung erfordern, in den Host 1 verlagert werden, während diejenigen Funktionen, die ohne eine solche Datenhaltung auskommen, zu der SPS 3 hin verlagert werden.
-
Dabei wird die SPS 3 vorzugsweise um eine zusätzliche Kommunikationsbaugruppe ergänzt, die im gleichen Schaltschrank untergebracht und an die bestehende SPS-Hardware mittels einer LAN- oder Bus-Verbindung angeschlossen wird. Sämtliche Zusatzfunktionen, welche die SPS 3 von der Middleware 2 übernimmt, sind dann in dieser Kommunikationsbaugruppe implementiert, so dass die Umrüstung keinen Eingriff in die Programmierung der SPS 3 erfordert und sich die Notwendigkeit der Neuinstallation von Softwarekomponenten erübrigt. Im Fall einer sog. Soft-SPS kommt anstelle der Installation einer Kommunikationsbaugruppe auch die Installation von Softwarekomponenten, welche die Funktion der Kommunikationsbaugruppe implementieren, auf der vorhandenen Hardwareplattform der Soft-SPS in Betracht.
-
Der Aufwand für die Beschaffung, Installation, Programmierung, Vernetzung, Inbetriebnahme, Betrieb und Wartung der mittleren Hierarchieebene (Middleware 2) entfällt, woraus für den Anwender ein beträchtlicher Zeit- und Kostenvorteil resultiert. Die Kommunikationsbaugruppe arbeitet nach ihrer Installation wartungsfrei, da in ihr keine Datenhaltung erfolgt und somit auch keine Maßnahmen zur Datensicherung nötig sind.
-
Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand der Zeichnungen beschrieben. In diesen zeigt
-
1 eine herkömmliche Struktur eines Systems zur Steuerung einer fördertechnischen Anlage,
-
2 eine herkömmliche Übertragung eines Datentelegramms zwischen einem Host-Rechner und einer SPS,
-
3 einen herkömmlichen Gesamtablauf der Bearbeitung eines Kundenauftrags,
-
4 eine Übersicht über die erfindungsgemäße Aufteilung von Middleware-Funktionen zwischen Host und SPS,
-
5 eine Übersicht über die erfindungsgemäße Unterteilung aufgeteilter Middleware-Funktionen in mehrere Module,
-
6 eine erfindungsgemäße Hardwarestruktur eines Systems zur Steuerung einer fördertechnischen Anlage,
-
7 eine erfindungsgemäße Übertragung eines Datentelegramms zwischen einem Host-Rechner und einer SPS,
-
8 einen erfindungsgemäßen Gesamtablauf der Bearbeitung eines Kundenauftrags.
-
Wie aus 4 zu ersehen ist, gehören zu den im Zusammenhang mit der Steuerung einer fördertechnischen Anlage herkömmlicherweise durch Middleware 2 realisierten Funktionen die Bereitstellung einer Schnittstelle zu einem auf dem ERP-Host 1 laufenden Anwendungsprogramm, wie beispielsweise die Entgegennahme eines Transportauftrags und das Absetzen von Rückmeldungen über dessen Abwicklung, ferner die Anwendung von (~ Ausführungsregeln, wie beispielsweise die Zuweisung von Prioritäten zu verschiedenen Transportaufträgen und weiterhin das Verwalten des Status von Komponenten der zu steuernden fördertechnischen Anlage, wie beispielsweise der Verfügbarkeit und Kapazität von Ressourcen. Diese Funktionen bilden eine erste Funktionengruppe, die erfindungsgemäß dem ERP-Host 1 zugeordnet und gemäß 5 zu einem ersten Modul zusammengefasst wird, welches nachfolgend mit SUBCONTROL bezeichnet wird.
-
Eine weitere Gruppe von herkömmlicherweise durch Middleware 2 realisierten Funktionen bilden nach 4 die Sicherung des Kommunikations- oder Nachrichtenprotokolls, die Verwaltung von Wiederholungen bei Übertragungsfehlern sowie des Wiederanlaufs nach einer Störung, die Umwandlung der Datenstruktur zwischen Anwendungsdaten und Telegramminhalten, und das Anstoßen der Weitererarbeitung. Auch diese Funktionen werden erfindungsgemäß dem ERP-Host 1 zugeordnet und gemäß 5 zu einem zweiten Modul zusammengefasst, welches nachfolgend mit SUBLINK bezeichnet wird.
-
Die beiden vorausgehend genannten Gruppen von Middleware-Funktionen beinhalten eine permanente Datenhaltung, wozu erfindungsgemäß auf den Massenspeicher des Hosts 1 und auf die vorhandenen Datenbank-Funktionen der auf diesem laufenden ERP-Anwendungen zurückgegriffen wird. Dies bedeutet, dass auf dem Host 1 ohnehin vorhandene Ressourcen mitgenutzt werden, um die separate Vorhaltung solcher Ressourcen in Form der Middleware 2 einzusparen.
-
Der SPS 3, d. h. einem neuen Kommunikationsmodul bzw. einer Kommunikationsbaugruppe 7, mit welcher diese auszurüsten ist, wird die herkömmlicherweise durch Middleware 2 realisierte Funktion der reinen Umsetzung von Nachrichten oder Telegrammen zwischen zwei unterschiedlichen Kommunikationsprotokollen zugeordnet. Die Telegramme werden dabei inhaltlich nicht mehr verändert, sondern das Kommunikationsmodul bzw. die Kommunikationsbaugruppe reicht die Telegramminhalte zwischen dem ERP-Host 1 und der SPS 3 lediglich weiter und verkehrt dabei mit jedem dieser beiden Kommunikationspartner unter Anwendung eines anderen Kommunikationsprotokolls.
-
Die sich aus diesem Konzept ergebende bevorzugte Hardwarestruktur ist aus 6 zu ersehen, in der gegenüber 1 gleichartige Komponenten mit gleichen Bezugszahlen bezeichnet sind. Der Host 1 ist in diesem Fall über ein LAN 6 mit einer zusätzlichen Kommunikationsbaugruppe 7 verbunden, welche die Funktion eines reinen Protokollwandlers ausübt und mit dem Host 1 einerseits und der SPS 3 andererseits unter Anwendung verschiedener Kommunikationsprotokolle Datentelegramme austauscht, die lediglich nach Bedarf umformatiert, aber inhaltlich nicht verändert werden.
-
Die Verbindung zwischen der Kommunikationsbaugruppe 7 und der SPS 3 kann durch das dasselbe LAN 6 realisiert sein, über welches die Kommunikationsbaugruppe 7 mit dem Host 1 verbunden ist, doch es kann alternativ hierzu auch eine separate Verbindung zur SPS 3 über eine andere Datenleitung, beispielsweise über einen eigenen Datenbus 9, für den an der SPS 3 eine Anschlussmöglichkeit besteht und bei dem es sich um einen Standard-Feldbus handeln kann, vorgesehen sein. Ob zur Verbindung der Kommunikationsbaugruppe 7 mit der SPS 3 das LAN 6 oder ein separater Datenbus 9 zweckmäßiger ist, hängt davon ab, welche Anschlüsse diesbezüglich an der SPS 3 vorhanden sind. An die SPS 3 sind ferner in bekannter Weise über einen Feldbus 4 Komponenten einer fördertechnischen Anlage 5 angeschlossen.
-
Die Kommunikationsbaugruppe 7 ist dazu ausgelegt, in demselben Schaltschrank wie die SPS 3 in unmittelbarer Nachbarschaft zu dieser untergebracht, d. h. vorzugsweise zusammen mit dieser auf einer gemeinsamen Montageschiene 8 angebracht zu werden. Außer den Anschlüssen für das LAN 6 und ggf. den zusätzlichen Datenbus 9 besitzt die Kommunikationsbaugruppe 7 noch einen Anschluss für eine Stromversorgung, z. B. für 24 V Gleichspannung. Alternativ könnte die Kommunikationsbaugruppe 7 auch wie eine 7 Erweiterungsbaugruppe für den Baugruppenträger der SPS 3 ausgelegt sein, um die Stromversorgung der SPS 3 mitzubenutzen.
-
In Analogie zu 2 zeigt 7 die erfindungsgemäße Übertragung eines Datentelegramms zwischen einem Host-Rechner 1 und einer Speicherprogrammierbaren Steuerung 3 ohne Verwendung von Middleware 2. Aus einer ERP-Anwendung heraus wird ein Datensatz erzeugt, der eine Bewegung in der fördertechnischen Anlage 5 verursacht. Die Daten werden im Host 1 an eine Verarbeitungsroutine übergeben, die ein Telegramm gemäß dem verwendeten SPS-Protokoll aufbaut und abspeichert. Ein Sendeprogramm im Host 1 übernimmt die als ”Neu” markierten Datensätze und sendet das Telegramm an das vorzugsweise in der Kommunkationsbaugruppe 7 laufende Modul SUBDRIVE, das die Telegramminhalte nach dem vereinbarten Protokoll an die SPS 3 weiterleitet.
-
Die Programmbausteine der SPS 3 übernehmen nun den Empfang sowie die weitere Verarbeitung der Telegrammdaten und steuern die Einrichtungen der fördertechnischen Anlage 5 an. Um die ERP-Anwendung auf dem Host 1 davon zu unterrichten, dass das Telegramm ordnungsgemäß empfangen wurde, sendet die SPS 3 ein Antworttelegramm, die sog. ”Logische Quittung”, an das Modul SUBDRIVE zurück. Das Telegramm wird von SUBDRIVE nun an den Host 1 weitergegeben. Das dort laufende ERP-Programm empfängt das Quittungstelegramm und protokolliert den Empfang in der dortigen Datenbank. Damit wird sichergestellt, dass bereits an die SPS 3 gesendete Telegramme nicht noch einmal übertragen werden, andererseits können die von der SPS 3 nicht oder fehlerhaft verarbeiteten Telegramme vom Host 1 wiederholt übertragen werden. Der Einsatz des Kommunikationsmoduls SUBDRIVE setzt voraus, dass in die ERP-Anwendung die Funktionen für die logische Behandlung von SPS-Telegrammen integriert werden, wie z. B. durch SUBLINK.
-
Es ist eine wesentliche Eigenschaft des Kommunikationsmoduls SUBDRIVE, dass es keine eigene Datenhaltung betreibt, da alle Funktionen der herkömmlichen Middleware 2, die eine Datenhaltung beinhalten, erfindungsgemäß dem Host 1 zugewiesen sind. Dementsprechend braucht die Kommunikationsbaugruppe 7 keinen Massenspeicher wie eine Festplatte oder dergleichen zu enthalten, was einen kompakten Aufbau und Unempfindlichkeit gegenüber rauhen industriellen Umgebungsbedingungen begünstigt.
- • Im Einzelnen erfüllt das auf dem Host 1 installierte, z. B. als ABAP-Programm in ein SAP@System eingebundene Modul SUBCONTROL unter anderem folgende Funktionen:
- • Erstellen der Nachrichten für das weitere Modul SUBLINK aus den Host-Anwendungsdaten, z. B. aus Transportaufträgen oder Tasks.
- • Aufbereiten der Nachrichten aus SUBLINK für die Anwendung (z. B. Transportauftrag quittieren, Regalbediengerät sperren, Zielanfragen).
- • Übergeben von Fahrbefehlen an SUBLINK gemäß den Ausführungsregeln, z. B. Einlagerung nach Auslagerung (Doppelspiel) oder Reihenfolge auf Basis der Priorität. Der Status der Fördertechnik wird hierbei abgefragt und berücksichtigt: Fahrbefehle werden nur dann übergeben, wenn das Ziel erreichbar ist, also nicht gestört ist und freie Kapazität hat.
- • Verwalten der als Stammdaten hinterlegten fördertechnischen Einrichtungen (Status, aktuelle Belegung).
- • Verwalten von Wegen. Z. B. führt der Weg von einem Lagerfach zum Auslagerpunkt zunächst über das Regalbediengerät und anschließend über weitere fördertechnische Komponenten.
-
Das ebenfalls auf dem Host 1 installierte, z. B. als ABAP-Programm in ein SAP@-System eingebundene Modul SUBLINK erfüllt unter anderem folgende Funktionen:
- • Empfangen und Übergeben von Nachrichten von/zu dem Modul SUBCONTROL über Funktionsaufrufe und Datenbanktabellen.
- • Aufbereiten der Daten für/von das/dem auf der Kommunikationsbaugruppe 7 laufende Modul SUBDRIVE. Wichtig ist hier die Umsetzung vom Datenformat der Anwendung (Felder der Datenbank-Tabellen) in das Format der Telegramm-Nachrichten für die SPS 3 (Zusammenhängende Zeichenkette).
- • Weitergeben von der SPS 3 eingehender Telegramme zur Weiterverarbeitung an SUBCONTROL (z. B. per RFC).
- • Protokollieren der gesendeten und empfangenen Nachrichten in Datenbank-Tabellen.
- • Verwalten des Telegrammverkehrs von/zu der SPS 3 (Gesendet, Quittiert, Offen, Reihenfolge, usw.).
- • Anstoßen des wiederholten Sendens eines Telegramms, wenn die logische Empfangsquittung der SPS 3 ausbleibt.
-
Das vorzugsweise auf der Kommunikationsbaugruppe 7 installierte Modul SUBDRIVE erfüllt unter anderem folgende Funktionen:
- • Bereitstellen eines Funktionsbausteins, der von einem Host 1 (z. B. SAP® mit SUBLINK mittels RFC) aufgerufen werden kann.
- • Bereitstellen einer Routine, die Funktionsbausteine im Host 1 (z. B. SAP® mit SUBLINK über RFC) aufrufen kann.
- • Übernehmen der Nachrichten vom Host 1 (z. B. SAP® mit SUBLINK) und Senden der unveränderten Daten über TCP/IP an die SPS 3.
- • Empfangen der Nachrichten von der SPS 3 und Senden der unveränderten Daten an den Host 1 (z. B. SAP® mit SUBLINK) weiter.
-
In Analogie zu 3 ist in 8 der erfindungsgemäße Gesamtablauf der Bearbeitung eines Kundenauftrags, zu dessen Erfüllung der Host 1 einen Transportauftrag zur Auslagerung einer Palette aus einem Hochregallager erteilen muss, in tabellarischer Form wiedergegeben. Dabei widerspiegelt die fortlaufende Nummerierung in der äußersten linken Spalte die zeitliche Abfolge der einzelnen Prozessschritte. Die Bezeichnungen der Prozessschritte und der zugehörigen Aktionen in den beiden nächsten Spalten sind selbsterklärend. In den drei rechten Spalten ist jeweils markiert, welche Aktion jeweils von dem Host 1, von dem vorzugsweise auf der Kommunikationsbaugruppe 7 installierten Modul SUBDRIVE (in 8 als DRV abgekürzt) und von der SPS 3 ausgeführt wird, und wie dabei Datentelegramme durch das Modul SUBDRIVE zwischen dem Host 1 und der SPS 3 übermittelt werden.
-
Wesentlich ist, dass das Modul SUBDRIVE nur die Aufgabe der Protokollumwandlung (”xs”/”xe”) erfüllt, während alle herkömmlicherweise von der Middleware 2 ausgeführten logischen Verarbeitungsschritte sowie die Datenhaltung bei dem Host 1 liegen. Die Installation des Programms SUB DRIVE in der Kommunikationsbaugruppe 7 erfolgt auf der Ebene des Betriebssystems. Das Programm SUB DRIVE wird als Service oder Hintergrundprozess gestartet.
-
Eine Kommunikationsbaugruppe 7 kann gleichermaßen bei einer konventionellen SPS 3 wie auch bei einer Soft-SPS, bei der an die Stelle einer speziellen SPS-Hardware ein Standardindustrie-PC mit Feldbusanschluss tritt, eingesetzt werden. Im Fall einer Soft-SPS ist es aber auch möglich, das Programm SUBDRIVE auf dem Rechner, der die Hardwareplattform der Soft-SPS bildet, auf der Ebene des Betriebssystems zu installieren, so dass sich eine eigene 10 Kommunikationsbaugruppe 7 hier erübrigt. Das Programm SUBDRIVE wird auch hier als Service oder Hintergrundprozess gestartet. Allerdings ist bei dieser Lösung durch die Mitnutzung der Hardware und des Betriebssystems der Soft-SPS die Protokollwandlungsfunktion von der SPS-Seite her gesehen nicht mehr vollständig transparent, sondern die Installation des Programms SUBDRIVE bedingt eine Einbindung in die vorhandene Umgebung und muss bei Änderungen an der Hard- und/oder Softwarekonfiguration der Soft-SPS neu vorgenommen werden.
-
Zu den Echtzeiteigenschaften der erfindungsgemäßen Lösung ist anzumerken, dass die teilweise Verlagerung von Middleware-Funktionen in einen Host 1 unter Einbindung von Modulen mit zeitrelevanten Funktionen in eine ERP-Anwendung das Echtzeitverhalten gegenüber der herkömmlichen Lösung mit zusätzlicher Hierarchieebene potentiell beeinträchtigen kann, da ERP-Anwendungen üblicherweise nicht für harten Echtzeitbetrieb ausgelegt sind. Hinsichtlich der sog. weichen Echtzeitanforderungen ist dies in Anbetracht der erheblichen Aufwandsersparnis durch den Wegfall einer ganzen Hierarchieebene zweifellos akzeptabel.
-
Als kritisch wird jedoch im Kontext fördertechnischer Anlagen in der Fachwelt eine geforderte Reaktionszeit im Bereich von deutlich unter einer Sekunde angesehen. Wenn solche sehr kurzen Reaktionszeiten gefordert sind, kann es nötig sein, diese durch Gegenmaßnahmen zu entschärfen. Geeignet sind hierzu strukturelle Veränderungen an der Sensorik, wie beispielsweise die Vorverlegung der Anbringungssorte von Sensoren gegenüber in Abhängigkeit von den Sensorsignalen zu betätigenden Aktoren entlang der Bewegungsbahn eines zu steuernden Objekts und/oder gewisse Eingriffe in die Programmierung der SPS 3, um dort beispielsweise ausreichenden Pufferspeicher für die temporäre Verwaltung mehrerer anstehender Aufträge bereitzustellen. Im Regelfall können durch derartige Maßnahmen ohne großen Aufwand auch harte Echtzeitbedingungen fördertechnischer Anlagen trotz der im Vergleich zu herkömmlichen Middleware-Programmen generell geringeren Geschwindigkeit von ERP-Anwendungen und deren externer Datenkommunikation erfüllt werden.
