SAIL

SAIL
System-Architektur
für die
IntraLogistik
Arbeitskreis
„Innovation und Standardisierung“
des Forum Intralogistik
VDMA, Frankfurt am Main / Stand: 18. Mai 2006

SAIL – Systemarchitektur für die Intralogistik
Teil 1:
Wiederverwendung durch Standardisierung

Zielsetzung und Konzept
Dipl.-Ing. R. Sang, Eckelmann AG, Wiesbaden;
Kurzfassung
„Rationalisierung durch Standardisierung" ist der Tenor der beiden folgenden Beiträge. Es
wird ein Architekturmodell für die Steuerungsimplementierung von Materialflusssystemen
vorgestellt, das durch konsequentes Design der Wiederverwendbarkeit die Risiken
komplexer Intralogistikprojekte reduzieren hilft. Der Modellansatz ist für alle Phasen und alle
Sichtweisen eines solchen Projektes bedeutsam und verspricht einen Anwendernutzen von
der Planungsphase bis in die Betriebsphase einer Intralogistik-Anlage.
1. Hintergrund der System-Architektur-Entwicklung

„Innovation und Standardisierung“ ist der Titel eines Arbeitskreises im Forum Intralogistik des
VDMA. In diesem Arbeitskreis haben sich namhafte Lösungsanbieter von Intralogistik-
Systemen zu einem Erfahrungsaustausch zusammen gefunden. Der Arbeitskreis hat sich
zum Ziel gesetzt, durch Empfehlungen, wie auch durch die Erstellung von Standards, einen
Mehrwert für Anwender und für Lieferanten von intralogistischen Systemen und
Systemkomponenten zu schaffen. Die Vorschläge des Arbeitskreises sollen alle
Betriebsphasen eines intralogistischen Systems, so z.B. die Auswahl, die Realisierung, den
Betrieb, die Unterhaltung und die Modernisierung, gleichermaßen berücksichtigen.
Die Systemarchitektur für die Intralogistik (SAIL), von dem hier die Rede sein wird, ist ein
erster Standardisierungsvorschlag zur Modellierung von Intralogistik-Steuerungssystemen.
Arbeitskreis „Innovation und Standardisierung“ Seite 2 von 47

Forum Intralogistik im VDMA / Frankfurt – 22.05.2006
2. Zielsetzung der SAIL

Die in der Intralogistik durchgeführten Projekte sind in hohem Maße interdisziplinär und
verlangen von allen an der Umsetzung eines solchen Projektes beteiligten Unternehmen -
von den Planern, über die Lieferanten, bis hin zu dem Anlagenbetreiber – ein hohes Maß an
Zusammenarbeit. Sowohl die horizontale Integration unterschiedlicher Gewerke, das sind
z.B.: Stahlbau, Förderanlagen, Materialflussfunktionen, Automatisierungstechnik, Antriebe,
Sensoren, Identifikationstechnologien, IT-Systeme, Netzwerke und Kommunikation usw., als
auch die vertikale Integration der unterschiedlichsten Geschäftsprozesse, das sind z.B.:
Lagern, Kommissionieren, Fördern, Routen, Transportieren, Vereinzeln, Zusammenführen,
usw., sind nur durch ein effizientes und ökonomisches Zusammenspiel einer Vielzahl von
Partnern zu bewerkstelligen. Misserfolg oder Erfolg eines Projektes hängen dabei nicht nur
von der Qualität einzelner Gewerke oder einzelner Implementierungen ab, sondern ganz
entscheidend von dem synergetischen und nachhaltigen Zusammenwirken aller
Projektdisziplinen.
Als Hürden vor einem nachhaltigen Projekterfolg sieht der Arbeitskreis u.a.:
die komplexen Systemstrukturen mit den sich zwangsläufig ergebenden Schnittstellen. Diese
Schnittstellen bedeuten im Projektalltag ein erhebliches Risiko für Funktion,
Gestehungskosten und Betriebskosten eines Intralogistik-Systems. Sie sind die Passungen
in dem Puzzle der beteiligten Disziplinen. Ausgehend von der Hypothese, dass erfolgreiche
Partner und Lieferanten eines solchen Beziehungsgeflechtes gerade ihre eigenen
Lieferanteile, denn diese entstehen ja idR. durch die Fokussierung auf die eigene
Kernkompetenz, optimal und wirtschaftlich anbieten können, liegen gerade in den
Schnittstellen der Gewerke und der Systeme die großen Risiken.
die Integrationsrisiken intralogistischer Systeme. Bei genauerer Betrachtung stößt man
sowohl auf ein makroskopisches Organisationsdefizit an den Nahtstellen ganzer Gewerke,
als auch auf ein mikroskopisches Organisationsdefizit innerhalb der einzelnen Gewerke.
Letzteres resultiert aus der heterogenen Organisation von Projektteams - man denke hier nur
an den zunehmenden Einsatz von Subunternehmer-Netzwerken - aber auch aus den sich
immer wieder integrationsresistent zeigenden Kopfmonopolen innerhalb einer Organisation.

die auch heute oft noch monolithisch ausgeführten Standardlösungen in der

Steuerungstechnik. Rationalisierungseffekte beim „customizing“ beruhen dann eher auf der
fehleranfälligen Strategie „Wiederverwendung durch Kopieren“ als auf systematisch
implementierten modularen Wiederverwendungstrategien.
In der Beseitigung dieser Risiken erwartet der Arbeitskreis daher die größten
Innovationspotentiale für die Branche.
Die zentrale Fragestellung lautet folglich: „Wie muss man eine Logistik-Systemarchitektur
gestalten, um die erwähnten Risiken zu minimieren?“. Während es sich bei der
Lagerverwaltung eher um homogene Systeme aus einer Hand handelt, trifft man bei
Materialflusssystemen auf sehr heterogene Installationen. Ein erster Ansatzpunkt der
Arbeitskreisaktivitäten ist daher das Konzept für eine „Systemarchitektur für die Intralogistik“
(SAIL). Die Architektur wird bewusst offen ausgelegt und kann zu einem späteren Zeitpunkt
auf weitere Intralogistik-Systeme ausgedehnt werden.
3. Innovation durch Funktionsstandardisierung

Als erfolgserprobte Vorgehensweise bei der Rationalisierung technischer Gewerke hat sich
die konsequente Mobilisierung von Wiederverwendbarkeit durch den Einsatz von Standards
erwiesen. Für die Automatisierung von Materialflusssystemen sind Standards bekannt, der
Arbeitskreis hat sich mit diesen Standards, das sind beispielsweise die Richtlinienarbeiten
des VDI und des VDMA, befasst.
Bei einer Sichtung der vorliegenden Standards sind zwei Kernthesen zur Bewältigung der
Komplexität von Intralogistik-Systemen erkennbar:
eine Ebenenorganisation vor dem Hintergrund von Baumstrukturen und dezentralen
Konzepten.
eine noch nicht stark ausformulierte Funktionszerlegung und Funktionszuordnung zu der
gefundenen Ebenenorganisation.
Diese Sichtweisen legen den Fokus mehr auf die Beherrschbarkeit von Komplexität durch
Struktur als auf die Wiederverwendung von Bauelementen.

Mit SAIL schlägt der Arbeitskreis eine Weiterentwicklung der bewährten Ansätze vor. Der
Fokus liegt jetzt nicht mehr auf einer Ebenenzerlegung mit Funktionsabbildung auf die
gefundenen Ebenen, sondern rückt die Logistikfunktion in das Zentrum der Modellierung. Die
funktionale Zerlegung einer Intralogistikanlage bezweckt jetzt primär eine Modellierung durch
wiederverwendbare Bausteine. Eine Komplexitätsreduzierung und Hierarchisierung ergibt
sich als Sekundäreffekt dabei zwangsläufig.
Inspiriert durch die objektorientierte Programmierung, die bereits in anderen Brachen zu
einem Paradigmawechsel geführt hat, beispielhaft seien hier die Ansätze zur
„Komponentenbasierten Automatisierung“ in den Prozessleitsystemen der Verfahrenstechnik
genannt, erfolgt mit der SAIL eine Übertragung dieser erfolgreichen Ansätze auch auf die
Modellierung von Intralogistik-Systemen.
Maßgeblich für die gedankliche Aufarbeitung dieses Paradigmawechsels durch die

Anlagenbauer sind die folgenden Denkschritte:
Primäre Anlagenzerlegung nach Funktionen und nicht nach Ebenen.
Kapselung der gefundenen Funktionen in Komponenten.
Standardisierung von Komponenten.
Standardisierung der Schnittstellen der Komponenten.
Bereitstellung von standardisierten Steuerungskomponenten analog zu verfügbaren
Mechanikkomponenten.
Die Vorteile dieser funktionszentrierten Anlagenmodellierung lassen sich zielgruppen-

orientiert darstellen:
Eine modulare Baukastensicht der Anlage in der Planungsphase.
Eine transparente Funktionsbewertung in der Beschaffungsphase.
Eine klare Funktionsabgrenzung bei der interdisziplinären Zusammenarbeit während der
Realisierungsphase.
Eine eindeutige Schnittstellendefinition an den Bausteingrenzen während der
Realisierungsphase.
Eine hohe Verfügbarkeit durch klare Problemabgrenzung in der Betriebsphase.
Eine risikoarme Austauschbarkeit funktional abgegrenzter Teilgewerke oder Komponenten in
der Modernisierungsphase.

In der Summe bietet der hohe Wiederverwendungsgrad der gekapselten Funktionen von
SAIL einen klaren Kostenvorteil durch reduzierten Anpassungsaufwand, höhere
Standardisierung, reiferen Implementierungsgrad und kürzere Inbetriebnahmezeiten.
4. Grundlagen der SAIL

Mit SAIL wird eine einfache Integration von mechanischen Komponenten und
steuerungstechnischen Komponenten zu Teilgewerken – oder wie man in der
Produktionstechnik sagt, Halbfabrikaten - möglich. Der aktuelle Entwicklungsstand von SAIL
abstrahiert dazu fünf essentielle automatisierungstechnische Funktionen einer
Materialflussanlage, aus deren Kapselung unmittelbar die Komponentenliste von SAIL
entsteht (Tabelle 1). Sämtliche Materialflussanwendungen lassen sich auf die dargestellten
Funktionen reduzieren.
Hinweis: Die Vorstellung erfolgt hier nur konzeptionell, die verwendete Modellnotation und
die einzelnen Funktionen werden im zweiten Teil des Beitrages ausführlich erläutert
Tabelle 1: Fördertechnische Funktionen

Fördertechnische Funktion SAIL-Komponente
F:AS – Anlagensteuerung A:FE – Förderelement
Kleinste Einheit mit Antrieben und
Bedient direkt die Anlage.
Sensorik.
Steuert Eigensicherheit und Transport-
Enthält die Funktion Anlagensteuerung
abwicklung.
(F:AS).
F:RE – Richtungsentscheidung A:FG – Fördergruppe
Eine Zusammenfassung von Förder-
elementen, die nach außen als ein
Richtungsentscheidung an einem
Verzweigungspunkt erscheinen.
Verzweigungspunkt der Anlage.
Gemeinsame Funktion Richtungsent-
scheidung (F:RE).

F:FA – Fahrauftragsverwaltung A:FS – Fördersegment

Eine Zusammenfassung von
Verwaltet Richtungsanweisungen pro Fördergruppen.
Transportobjekt und Anlagenpunkt. Gemeinsame Funktion
Fahrauftragsverwaltung (F:FA).
F:RN – Ressourcennutzung A:FB – Förderbereich
Verteilt Transportobjekte auf freie
Ressourcen. Eine Zusammenfassung von
Berücksichtigt Belegungszustand, Fördersegmenten.
Transportkapazität, Struktur und Gemeinsame Funktion
vorliegende Transportaufträge. Ressourcennutzung (F:RN).
Erzeugt Fahraufträge.
F:TK – Transportkoordination
Schnittstelle zu den beauftragenden
Systemen. Gruppierung und Sequen- Wird in SAIL nicht als Automati-
zierung von Transportaufträgen. sierungsfunktion der Steuerungsebene
Strategische Entscheidungen abhängig angesehen und daher nicht als
von Verfügbarkeit, Laststeuerung und Komponente modelliert.
Betriebsstrategien.
Abbildung 1 stellt die vier Komponententypen von SAIL in einer gekapselten

Komponentensichtweise dar. Die Rechtecke stellen die vier Komponententypen A: xx dar.
Die Kreise repräsentieren die von den Komponenten wahrgenommenen Funktionen F: xx.
Die Kommunikationsbeziehungen sind hier noch nicht weiter ausgeführt, ersichtlich ist aber
die strenge Kapselung der Funktionen.

Bild 1: Kapselung der SAIL-Komponenten
Durch die konsequente Funktionskapselung wird erstmalig eine wiederverwendbare

Komponentenbibliothek für Logistikfunktionen definiert.
Die Abbildung 2 zeigt die Analogie zur mechanischen Komponentenbildung. SAIL definiert
auf der untersten Funktionsstufe äquivalente Automatisierungskomponenten für jede
Mechanikkomponente. Die SAIL-Komponenten enthalten dabei sowohl die
steuerungstechnischen Repräsentation der Mechanikfunktion als auch die visuelle
Repräsentation für Dialog und Darstellung.

Bild 2: Mechanikbaukasten und Steuerungsbaukasten
5. Die SAIL-Bausteinfamilie
Eine SAIL-Bausteinfamilie basiert auf den vier Komponententypen:
Förderelement
Fördergruppe
Fördersegment
Förderbereich.
Abhängig von spezifischen Leistungsmerkmalen der unterlagerten fördertechnischen
Systeme werden diese Komponententypen anbieterspezifisch implementiert. Unter
Berücksichtigung der vorgeschlagenen Funktionsaufteilung und ausgerüstet mit einer
generischen Schnittstelle, die die benötigte Flexibilität und Toleranz für
Schnittstellenerweiterungen mit sich bringt, können Intralogistik-Systeme durch Kombination
von SAIL-Komponenten unterschiedlicher Hersteller aufgebaut werden.
Das SAIL-Modell definiert die Bausteinschnittstelle derzeit rein funktional durch Festlegung
aller Kommunikationsinhalte, während die konkrete Umsetzung auf bestehende und
standardisierte Kommunikationsverfahren der Weiterentwicklung des Modells vorbehalten
bleibt.

Allen Bausteinen gemeinsam ist eine nachrichtenorientierte Kommunikationsschnittstelle mit

den Nachrichtentypen:
Parameter
Steuerdaten
Aufträge
Auftragsrückmeldungen
Statuswerte
Diagnosedaten
Speziell für die elementaren Förderelemente wird zusätzlich zur Kommunikationsschnittstelle
eine direkte signaltechnische Verriegelung zur Taktsteuerung benachbarter Elemente
vorgesehen.
Im Folgenden werden die generischen Komponenten der SAIL-Bausteinbibliothek

vorgestellt.
5.1 Basiskomponenten
Es werden zwei Ausprägungen von Basiskomponenten vorgeschlagen:
„Förderelement“ zur Steuerung elementarer 1- oder mehrachsiger Förderelemente
(Abbildung 3).
„Identifikationselement“ zur Steuerung eines Datenerfassungspunktes (Scanner, RFID..)
(Abbildung 4).

Bild 3: Förderelement (AE = Antriebselement)
Bild 4: Identifikationselement

5.2 Aggregationskomponenten
Durch Bottom-UP Synthese werden komplexe Materialflussfunktionen aus der Aggregation
untergeordneter Funktionen erzeugt. Im SAIL werden dazu neue Funktionsschalen um die
untergeordneten Funktionen gelegt und als Aggregationskomponente definiert.
Fördergruppe
Abbildung 5 zeigt die Fördergruppe als Aggregation von Förderelementen mit gemeinsamer
Richtungsentscheidung und ggf. gemeinsamem Identifikationselement.
Bild 5: Fördergruppe
Fördersegment
Abbildung 6 zeigt das Fördersegment als Aggregation von Fördergruppen mit gemeinsamer
Fahrauftragsverwaltung.

Bild 6: Fördersegment
Förderbereich
Abbildung 7 zeigt den Förderbereich als Aggregation von Fördersegmenten mit
gemeinsamer Ressourcennutzung.
Bild 7: Förderbereich

6. Verifikation des SAIL an Elementarobjekten

Der Nutzen der vorgestellten SAIL resultiert aus der konsequenten Anwendung der beiden
Konzepte „Zerlegung nach Funktion“ und „Kapselung in Komponenten“.
Um die Anwendungsreife und die Nutzbarkeit des Modells zu überprüfen, sollen die SAIL-
Konzepte an Beispielen verifiziert werden. Ein erstes Beispiel veranschaulicht die
Funktionskapselung an einfachen Fördertechnikkonfigurationen. Beispiele vollständig
umgesetzter Anlagen folgen im zweiten Teil des Beitrages („Funktionen, Daten und
Nachrichten in Theorie und Praxis“).
Abbildung 8 demonstriert die Funktionskapselung anhand einfacher elementarer

Fördertechnikkonfigurationen.
Konfiguration 1 und 4 beschreiben langsame Förderanlagen (z.B. Palettenfördertechnik), bei
denen die Funktionen Identifikation, Richtungsentscheid und Ausschleusung in einer
einzigen Materialflussposition darstellbar sind. Die Modellierung erfolgt als eine Komponente
„Fördergruppe (FG)“ mit der Gruppenfunktion „Richtungsentscheidung“ und unter
Verwendung von Elementarkomponenten „Förderelement (FE)“ und „Identifikationselement
(IE)“.
Konfiguration 2 und 3 beschreiben schnelle Förderanlagen (z.B. Behälterfördertechnik), bei

denen die Funktionen Identifikation, Richtungsentscheid und Ausschleusung über mehrere
Förderpositionen verteilt sind. Auch hier erfolgt die Modellierung als eine Komponente
„Fördergruppe (FG)“ unter Verwendung aller für die Gesamtfunktion notwendigen
Basiskomponenten. Die Erweiterung des Beispiels 2 nach 3 zeigt deutlich die
Leistungsfähigkeit des Modellierungsansatzes. Durch Kombination vielfältiger
Einzelelemente zu einer neuen Komponente ergibt sich eine signifikante Vereinfachung in
der Handhabung der Aggregation.

Bild 8: Verifikation an Elementarobjekten
7. Detaillierung und weitere Verifikation der SAIL

Eine Detaillierung und weitere Verifikation der SAIL erfolgt im zweiten Teil des Beitrages mit
dem Titel „Funktionen, Daten und Nachrichten in Theorie und Praxis“.

Teil 2:
Funktionen, Daten und Nachrichten in Theorie und Praxis
Dipl.-Ing. C. Gutbrod, Dr. Thomas + Partner GmbH, Karlsruhe
Kurzfassung
Dieser Teil befasst sich mit den zur Realisierung des Materialflusses notwendigen
Funktionen, Daten und Nachrichten, deren Abgrenzung und Interaktion. Neben der
theoretischen Beschreibung zur Modellbildung wird an ausgewählten Praxisbeispielen
gezeigt, wie auch heterogene Anlagen nach diesem Modell beschrieben und betrieben
werden können. Besondere Aufmerksamkeit wird der Erneuerung und Erweiterung
bestehender Anlagen zuteil, da dies ein Tätigkeitsfeld ist, das heute und in naher Zukunft
größere Bedeutung hat als der völlige Neubau von Logistiksystemen. Schließlich folgt eine
Auflistung der benötigten Daten und Nachrichten, wie sie sich aus dem Modell ergeben und
in den Praxisbeispielen bewährt haben.
Aufgaben und Aufgabenteilung in Intralogistiksystemen bezüglich der

Transportdurchführung
Sehr häufig wird bei der Beschreibung des Transportsystems in einem Logistikzentrum eines
der bekannten Ebenenmodelle (z.B. VDMA 15276) verwendet. Diese Modelle zeigen die
tatsächliche Geräteabgrenzung bzw. den tatsächlichen Lieferumfang eines
Gewerkelieferanten besser als den Funktionsumfang, den eine Komponente zur
Realisierung des Materialflusses beiträgt. Um eine bessere Austauschbarkeit jeder der
beteiligten Komponenten und eine hohe standardisierte Interaktionsfähigkeit dieser
Komponenten untereinander erreichen zu können, werden die erforderlichen Funktionen
identifiziert und beschrieben. Besonders in Logistikzentren mit einer gewachsenen
heterogenen Struktur an Förderanlagen ist es vorteilhaft, wenn die Funktionen als solche
vollständig beschrieben und gekapselt sind und es damit ermöglichen, leicht und ohne die
Gefahr von unerkannten Querwirkungen sowohl bestehende Teile als auch Erweiterungen
oder Neubauten modellieren zu können. Entscheidend für das Verständnis des Systems in

seiner Gesamtheit und des Zusammenspiels seiner Komponenten ist die klare Abgrenzung
der Funktionalitäten untereinander und die Möglichkeiten ihrer Zuordnung zu den
verschiedenen beteiligten Systemen sowie eine klare Definition der Nachrichten, die
zwischen den einzelnen Komponenten ausgetauscht werden.
Der Transportauftrag (TA)

Ausgangspunkt für die Durchführung eines Transportauftrages ist eine Anforderung aus dem
operativen Betrieb. Solche Anforderungen können z.B. Kommissionier- oder
Produktionsnachschübe, Wareneingänge oder Umlagerungen sein. Summarische
Anforderungen werden von einem Bestandsführungssystem soweit aufgelöst, dass eine oder
mehrere Bestandseinheiten als Transportobjekte ausgewählt werden, für die dann jeweils ein
Transportauftrag generiert wird. In der weiteren Betrachtung bezieht sich also ein
Transportauftrag immer auf genau ein identifizierbares Transportobjekt, das von seinem
momentanen Standort zu seinem Bestimmungsort (Endziel) zu bringen ist.
Der Fahrauftrag (FA)

Ein Transportauftrag wird untergliedert in einzelne Fahraufträge an Fördersysteme, die den
Transport dann tatsächlich durchführen. Diese Fahraufträge können entweder
vorausberechnet und beauftragt werden oder sie werden direkt entsprechend dem Anlagen-
und Transportzustand neu berechnet. Ein Fahrauftrag gilt immer nur für das beauftragte
Fördersystem bis zum Erreichen der Systemgrenze eben dieses Systems.
Die Zielfindung
Bei der Durchführung eines Fahrauftrags muss das transportierende System das im
Teiltransportauftrag spezifizierte Ziel entweder selbst finden können oder dem
Transportsystem wird im Auftrag mitgeteilt, wie das (dann nicht notwendig mitgeteilte)
Teiltransportziel zu erreichen ist. Im ersten Fall muss das Transportsystem an jeder
Verzweigungsstelle, an der eine Richtungsentscheidung zu treffen ist, durch Kenntnis
mindestens der eigenen Topologie entscheiden, in welche Richtung das Transportobjekt
weiterzutransportieren ist. Im zweiten Fall muss das beauftragende System für jede
Entscheidungsstelle dem beauftragten System die zu befahrende Richtung im Auftrag
mitteilen.

Die Ressourcennutzung
Bei der Durchführung der Transporte muss die Blockierung von Ressourcen vermieden
werden. Es darf z.B. keine Kreuzung befahren werden, wenn deren Ausfahrt nicht frei ist, da
sonst der Querverkehr behindert wird. Diese einfache Belegungssteuerung kann vom
Transportsystem selbst vorgenommen werden. Stehen betriebsstrategische Ziele bei der
Ressourcenbelegung im Vordergrund (welches von mehreren Transportobjekten erhält den
Zuschlag für eine knappe Ressource), dann muss die Verantwortung für die Benutzung einer
Ressource von einem System übernommen werden, das die Belegungssituation aller
Transportbereiche kennt und bei dem die entsprechenden Betriebsparameter bekannt und
die passenden Strategien implementiert sind. In der Regel sind dies komplexere Aufgaben,
die nicht mehr sinnvoll steuerungsnah implementiert werden können.
Die Nutzungsoptimierung der Transportinfrastruktur

Häufig treten bei der Nutzung einer Transportinfrastruktur verschiedene Betriebszustände
auf, die aus verschiedenen Phasen der operativen Tätigkeit herrühren. So sind z.B. in
Distributionszentren häufig Phasen anzutreffen, in den bevorzugt eingelagert oder
nachgeschoben oder kommissioniert wird. Um in jeder dieser Phasen die Infrastruktur, die im
Hochlastbetrieb ja auch immer eine knappe Ressource ist, optimal an der Grenze ihrer
Leistungsfähigkeit zu nutzen, müssen passende Strategien auch von den Transportanlagen
unterstützt werden. So müssen z.B. Vorfahrtsregeln bei Zusammenflüssen geändert werden
oder der Belegungsgrad von Kreisel- oder Staustrecken muss gesenkt werden, um spontane
Expresstransporte zu beschleunigen und vieles mehr.
UFOs und Schwarzfahrer

Transportsysteme sind in der Praxis gewollt oder ungewollt mit zwei Arten von
problematischen Transportobjekten konfrontiert: unidentifizierbaren Förderobjekten (UFOs)
und identifizierbaren Transportobjekten ohne Transportauftrag (Schwarzfahrer). Für beide
Typen muss eine Strategie entwickelt werden, mit der sie an einem Entscheidungspunkt
behandelt werden. In aller Regel sind UFOs auf einem Transportsystem störend, da sie nicht
weiter disponiert werden können, sie werden typischerweise schnellstmöglich ausgeschleust.
In bestimmten Anlagen bzw. zu bestimmten Betriebszuständen kann es durchaus sinnvoll
sein, identifizierbare Transportobjekte ohne Auftrag (Schwarzfahrer) auf der Anlage zu halten

um sie z.B. als schnell verfügbare Leergutreserve für unstetigen Bedarf an

Kommissionierplätzen vorzuhalten.
Entscheidungsfindung an einem Anlagenpunkt

In einer nicht stetig fördernden Transportanlage wird unmittelbar in der Steuerung
entschieden, ob ein Transportobjekt von einem Platz zu einem anderen weitergefördert
werden kann. Dies ist allein durch die physische Belegung der Anlage zu realisieren
(Belegungszustand des Folgeförderers). Nur wenn gefördert werden kann, ist zu prüfen ob
das Transportobjekt gefördert werden darf und falls ja in welcher Richtung es
weiterzufördern ist. Diese Entscheidungsfindung unterliegt hohen Anforderungen an die
Echtzeitfähigkeit und bestimmt in ihrer Architektur die Möglichkeit der Anpassung der
Nutzung einer Anlage nach den wechselnden Bedürfnissen des operativen Betriebs - positiv
wie negativ. Die Transportrichtungsermittlung (hier ist auch die Anweisung stehen zu bleiben
ein mögliches gewolltes Ergebnis) muss dabei sowohl mit Transportobjekten umgehen
können, die einen Transportauftrag haben, als auch mit UFOs und Schwarzfahrern. Daher
müssen auch Anweisungen hinterlegt sein, wie solche Transportobjekte zu behandeln sind.
Diese können dann auch ohne weiteres für Transportobjekte mit Fahrauftrag aber ohne
spezielle Anweisung für den aktuellen Punkt benutzt werden. In Transportsystemen, bei
denen das Transportgut an einem Entscheidungspunkt angehalten werden kann
(Einzelplatzförderer in Palettenförderanlagen), ist es möglich, für jedes Transportgut an
jedem Entscheidungspunkt neu anzufragen ob und wie weitergefördert werden soll.

Bild 1: Entscheidungskriterien beim Fördern
Der Fahrauftrag
Zu der oben beschriebenen Art der Entscheidungsfindung passt ein Fahrauftrag, der über
die Identnummer des Transportobjektes die Richtungsanweisung für eine
Entscheidungsstelle enthält. An allen anderen Entscheidungsstellen als der im Auftrag
spezifizierten wird gefahren nach den Anweisungen, die bei der Entscheidungsstelle für eben
diese Situation hinterlegt sind. Für langsame Anlagen (Palettenförderanlagen,
Staplerverkehr) ist das ausreichend. Bei schnellen Anlagen erhöht sich der
Kommunikationsaufwand und die Anforderung an die Reaktionsgeschwindigkeit so stark,
dass die Anlage nicht ohne Stockungen betrieben werden kann. Um dieses Problem zu
entschärfen, kann ein Teiltransportauftrag zwei Richtungsanweisungen enthalten. Damit ist
es dann möglich, im Zusammenspiel mit der o.g. Art der Richtungsentscheidungsfindung
Transporte auch auf komplexen Fördersystemen über weite Strecken mit vielen
Entscheidungsstellen mit einem Teiltransportauftrag oder sehr wenigen weiteren
Folgeaufträgen durchzuführen, ohne überhöhten Kommunikationsaufwand oder Stockungen
des Betriebes in Kauf nehmen zu müssen.

Aus einer systematischen Varianten- und Fallbetrachtung ergeben sich verschiedene Typen
von Fahraufträgen, die zum Teil auch in bestehenden Anlagen so anzutreffen sind.
Tabelle 1: Fahrauftragstypen
Typ Art der Daten Typische Verwendung
Richtungsentscheidung
RT Routingfähige RE, Tg-Nr, Quelle, Ziel Palettenfördersystem,
RoutingTaufe Transportgut taufen I-Punkt, Aufsetzen
RN Routingfähige RE Tg-Nr, Ziel PFS Normaltransport
RoutingNormal Sorter Abwurfziel
DA Direktanfrage, nicht Tg-Nr, Ort + Richtung PFS Normaltransport,
DirektAnfrage routingfähige RE,
Anweisung pro Punkt
AL Vorausberechnete Route Tg-Nr, Ort1 + Rtg, Alle Arten
AnweisungsListe im Auftrag Ort2 + Rtg. etc , Ziel +
Rtg.
UFA RE kennt Tg-Nr, Quelle + Rtg, Alle Arten
UniversalFahrA. Standardrichtungen Ziel + Rtg
Der Typ RT und RN ist weit verbreitet in Anlagen, deren Richtungsentscheidung routingfähig
ist, der Typ DA wird manchmal in langsamen nicht routingfähigen Systemen verwendet,
Fahraufträge des Typs AL sind theoretisch denkbar, benötigen aber eine Begrenzung in der
Anzahl der möglichen Zwischenziele, sie sind real nicht bekannt. Der Typ UFA ist eine
Erweiterung des weit verbreiteten Typs RT, er enthält Richtungsangaben für die adressierten
Punkte. Damit kann auch eine nicht routingfähige Richtungsentscheidung den Transport
durchführen. Falls die Richtungsentscheidung ein Transportgut ohne Auftrag oder ohne
Anweisung für den konkreten Punkt in einer Standardrichtung weiterfördern kann, ist dieser
Auftragstyp geeignet, auch auf sehr schnellen Anlagen Transporte über weite Strecken mit
wenigen Fahraufträgen durchzuführen.

Bild 2: Entscheidungskriterien bei der Ressourcennutzung
Allgemein kann eine Förderanlage als ein Netz von Punkten und Wegen verstanden werden.
Für die Erfüllung der betrieblichen Ziele nehmen vielerlei Faktoren Einfluss auf die
Entscheidung, wie die Anlage genutzt wird. Praktisch sind drei Problemkreise zu lösen. An
einer Zusammenführung muss neben der eigentlichen Vorfahrtregelung auch die Aufteilung
der Summen der Ressourcen der zu- und abführenden Strecken gelöst werden. An einer
Verzweigung muss entschieden werden, welche der Strecken zum Ziel führt und ob
gegebenenfalls auch ein Umweg eingeschlagen werden soll. Seltener aber dafür schwieriger
ist der Fall, wenn die Möglichkeit einer Kreisfahrt besteht und der Kreisel nicht als
Sortierkreisel konzipiert wurde. Ein Kreisel kann dann als Puffer verwendet werden, er bringt
aber keine nachhaltige Entlastung für überforderte Strecken. Alle diese Überlegungen
erfordern eine sorgfältige Überlegung, wo die Algorithmen zur Lösungsfindung implementiert
werden – vereinfacht ausgedrückt: auf welchem System welche Entscheidungslogik
programmiert wird. Danach richtet sich dann auch die Gliederung der Netztopologie. Jede
Entscheidungsinstanz muss das Netz nur so exakt kennen, dass ihre Entscheidungen von
den dann beauftragten Systemen auch realisiert werden können. Wie diese dann intern
arbeiten bleibt verborgen. In der Praxis hat sich hier in den vergangen Jahren eine Wandlung

vollzogen. Früher hat man die Netztopologie möglichst anlagennah bekannt gemacht, um an
Entscheidungspunkten die weitere Aktion so schnell berechnen zu können, dass ein
Fördergut möglichst ohne Stop weiterläuft. Damit musste dann die SPS als
Richtungsentscheider routingfähig sein Die Komponenten, die die betrieblichen
Nutzungsstrategien zu realisieren hatten, können dabei nicht oder nur sehr spät an
Fördersystemgrenzen Einfluss nehmen. Die technische Entwicklung in der
Datenübertragung (Netzwerke), bei der Geschwindigkeit der Rechner und bei den
Datenbanken erlaubt es heute, die Entscheidung über den Weitertransport in Systeme zu
verlagern, die nicht mehr so anlagennah sind, in denen dafür komplexere
Entscheidungsalgorithmen überhaupt oder einfacher zu implementiert werden können als in
speicherprogrammierbaren Steuerungen. Hier sind natürlich immer noch physikalische
Grenzen gegeben, es kommt also darauf an, die Funktionen je nach Anlagentyp richtig zu
positionieren.
Funktionen
Die bezüglich der Durchführung von Transporten identifizierten Funktionen werden hier
definiert, unabhängig davon wo und in welcher Technik sie tatsächlich implementiert sind.
Funktionen erhalten den Präfix 'F:'.
F:AS - Anlagensteuerung
Die Anlagensteuerung bedient direkt die Anlage. Sie realisiert alle Entscheidungen, die für
die Eigensicherheit der Anlage und die für die Durchführung eines Transportschrittes
notwendig sind. Auf dieser Ebene fällt also die Entscheidung, ob gefördert werden kann. In
der Regel wird dazu nur die Aufförderfreigabe des Folgeförderers betrachtet. Die Richtung,
in welche das Transportgut zu fördern ist, erhält die Anlagensteuerung als Ergebnis der
Funktion Richtungsentscheidung.

F:RE - Richtungsentscheidung
Die Richtungsentscheidung an einem bestimmten Anlagenpunkt für ein Transportobjekt
ermittelt aus den eingestellten Betriebsparametern des Punktes und den ggf. vorhandenen
Fahrauftragsdaten für das sich an diesem Punkt befindende Transportobjekt, ob und in
welcher Richtung weitergefördert werden soll. Vom Transportgut muss mindestens bekannt
sein, ob es ein unbekanntes Förderobjekt UFO ist. Ist das der Fall, kann in der Regel schon
entschieden werden, wohin dieses UFO zu transportieren ist. Wenn UFOs situationsbedingt
nach nichttrivialen Strategien geroutet werden sollen, muss eine entsprechende Zielanfrage
an eine externe Instanz F:RN gestellt werden. Für identifizierte Transportobjekte muss der
Transportauftrag betrachtet werden. Dazu wird bei der Fahrauftragsverwaltung F:FA die
Ermittlung der Auftragsdaten veranlasst. Je nach Komplexität der Anlage und der Struktur
der Fahraufträge und deren Speicherungsmöglichkeiten ist die Ermittlung der
Weiterfahrtrichtung aus dem Auftrag mehr oder weniger komplex, daher wird das in die
Funktion der Fahrauftragsverwaltung gelegt. Die Funktion Richtungsentscheidung erwartet
von der Fahrauftragsverwaltung für ein Transportgut am konkreten Entscheidungspunkt nur
die Aussage, ob das Transportgut ein Schwarzfahrer ist, also kein Fahrauftrag vorliegt, oder
in welche Richtung es weiter zu fördern ist. Ist das Transportobjekt ein Schwarzfahrer, richtet
sich die Behandlung nach fest programmierten Regeln oder besser nach einer
parametrierbaren Richtungsanweisung. Das gleiche gilt, wenn die Fahrauftragsverwaltung
für einen Nicht-Schwarzfahrer keine spezielle Richtungsanweisung geliefert hat. Ansonsten
wird das Transportobjekt in der spezifizierten Richtung gefördert.
F:FA - Fahrauftragsverwaltung
Die Fahrauftragsverwaltung stellt für die Funktionsgruppe F:RE die relevanten Daten des
Fahrauftrags zur Verfügung. Insbesondere muss sie über die Identifikation des
Entscheidungspunktes und des Transportobjekts die Information liefern, ob eine
Richtungsanweisung vorliegt und welche Ausprägung diese hat. Dieser Vorgang stellt hohe
Anforderungen an die Reaktionszeit. Ausserdem ist diese Funktionsgruppe dafür
verantwortlich, Fahraufträge anzulegen, zu verändern und zu löschen, wenn dies von der
beauftragenden Funktion Ressourcennutzung verlangt wird. Diese Vorgänge stellen keine
hohen Anforderungen an die Reaktionsgeschwindigkeit.

Bei der Beantwortung einer Richtungsanfrage wird zuerst der Fahrauftrag über die
Identnummer des Transportobjektes ermittelt. Ist diese Funktion routingfähig, reicht für die
Ermittlung der Richtung das Vorligen des Endzieles des Transportes. Die
Fahrauftragsverwaltung ermittelt dann selbst die konkrete Förderrichtung. Wenn diese
Funktion nicht routingfähig ist, dann wird im Fahrauftrag gesucht, ob für den aktuellen Punkt
eine Anweisung gegeben wird. Falls ja, wird diese übermittelt, falls nein, wird statt dessen
eben diese Tatsache übermittelt. Damit gewinnt man die Freiheit, je nach Erfordernis, für
sehr einfache Fahraufträge mit nur der Angabe des Endzieles oder mit einem oder mehreren
Wertepaaren Punkt/Richtung die jeweils passende Implementierung zu wählen.
F:RN - Ressourcennutzung
Die Ressourcennutzung kennt den aktuellen Belegungszustand der Transportsysteme,
deren mögliche Transportkapazitäten und Struktur, die vorliegenden Transportaufträge und
die notwendigen Parameter für die Strategien zur Nutzung der freien Ressourcen. Hier wird
entschieden, welches von mehreren konkurrierenden Transportobjekten eine freie
Ressource nutzen darf. Daraus resultiert die Vergabe oder Veränderung eines Fahrauftrages
an die Funktionsgruppe F:FA. Diese Funktionsgruppe bedient sich zur Verfolgung ihrer
Betriebsstrategien auch der Parametrierung der Entscheidungspunkte bei der
Funktionsgruppe F:RE.
F:TK - Transportkoordination
Diese Funktionsgruppe ist die, bei der die umgebenden, nicht zum
Materialflusssteuerungssystem gehörenden, Systeme ihre Transporte beauftragen,
Statusinformationen erlangen können und von der sie bei Beendigung die Vollzugsmeldung
erhalten. Die Transportkoordination sorgt dafür, dass ein bei dieser Komponente
beauftragter Transport richtig abgewickelt wird, also zur richtigen Zeit am richtigen Ort
fertiggestellt wird. Aus einer Vielzahl von Transportaufträgen (Hochlastbetrieb) werden die
passenden Betriebsstrategien ermittelt. Hier sind z.B. auch Funktionen zur Gruppierung und
Sequenzialisierung mehrer Transportaufträge angesiedelt, hier werden die Verfügbarkeiten
aller Bereiche und Systeme betrachtet und in der Laststeuerung für einzelne
Transportsysteme berücksichtigt. In dieser Funktionsgruppe findet z.B. auch die
Organisation von Sammeltransporten, Rundgängen und Batchbildung statt.

Anlagenelemente zur Kapselung der Funktionen bei der Modellierung

Eine Förderanlage wird aus verschiedenartigen Anlagenelementen modelliert, sie erhalten
den Präfix 'A:'
A:FE – Förderelement
Ein Förderelement ist die kleinste Einheit. Es besteht aus einem Antrieb für die
Hauptförderrichtung und die Antriebe für die abzweigenden Förderrichtungen sowie der
notwendigen Sensorik. Es besitzt nur die Funktion Anlagensteuerung (F:AS).
A:FG – Fördergruppe
Eine Fördergruppe ist dadurch gekennzeichnet, dass sie eine Gruppe von Förderelementen
mit der Funktion Richtungsentscheidung (F:RE) betreibt. Sie ist also eine Zusammenfassung
von Förderelementen, die zusammen ein mehr oder weniger komplexes Anlagengebilde
darstellen, das nach aussen als ein Verzweigungspunkt erscheint. Dem entsprechend besitzt
die Fördergruppe eine Richtungsentscheidungsinstanz F:RE mit deren Betriebsparametern.
A:FS – Fördersegment
Ein Fördersegment ist dadurch gekennzeichnet, dass es für eine Gruppe von Fördergruppen
die Funktion Fahrauftragsverwaltung (F:FA) bereitstellt.
A:FB – Förderbereich
Ein Förderbereich besteht aus einer Gruppe von Fördersegmenten, für die er die
koordinierende Funktion der Ressourcennutzung (F:RN) bereitstellt.
Typische Konfigurationen
Mit den definierten Funktionen ergeben sich typische Konfigurationen für deren Aufteilung
auf verschiedene Steuerungs- oder Rechnersysteme. In Bild 3 sind vier (A, B, C, D) gezeigt.
Konfiguration A ist typisch für völlig selbständige Transportsysteme, z. B. Anlagen mit
fahrerlosen Transportfahrzeugen, bei denen die Zuteilung von Fahraufträgen zu den
Fahrzeugen und die Routenfindung vollständig im Bereichsrechner realisiert sind.
Konfiguration B ist sehr häufig in allen Arten von Anlagen anzutreffen. Ein
Transportkoordinierungssystem (MFCS) bestimmt die Belegung der Ressourcen und die
Auswahl der Transporte nach betriebsstrategischen Kriterien und vergibt Fahraufträge an
das unterlagerte Transportsystem, das die Fahraufträge selbst verwaltet. Der Grad der dabei

möglichen Feinsteuerung durch die Ressourcennutzung hängt direkt davon ab, wie viele
Kommunikationspunkte im Transportnetz auf dieser Ebene bekannt sind, also wie kurz die
Leine ist, an der das Transportsystem geführt wird.
Bild 3: Typische Konfigurationen
Konfiguration C ist die klassische Anwendung eines Materialflussrechners (MFR). Ein

Lagerverwaltungssystem (LVS) erzeugt Transporte und übergibt sie entsprechend der
betrieblichen Erfordernisse an einen MFR. Dieser erzeugt und verwaltet Fahraufträge
entsprechend den hinterlegten Transportstrategien. Er beantwortet direkt Richtungsanfragen
der unterlagerten Anlagensteuerungen (UST), wobei sehr kurze Reaktionszeiten erreicht
werden müssen. Konfiguration D ist eher exotisch. Sie ist dadurch gekennzeichnet, dass die
unterlagerte Anlagensteuerung UST nur die Elementsteuerung enthält und schon die
Richtungsentscheidung in den MFR verlagert wurde. Diese Aufteilung ist äußerst kritisch
bezüglich der Reaktionszeiten, hat aber den Vorteil, dass die UST nur die zum Betrieb der
Förderer notwendigen Funktionen enthält und die Entscheidungsfunktionen mit ihren
vielfältigen Anforderungen und Einflüssen in einer unabhängigen zentralen Instanz gekapselt
sind. Nach der gleichen Überlegung ist die Ressourcennutzung im
Materialflusskoodinierungssystem MFCS angesiedelt, um damit bezüglich der
Reaktionsgeschwindigkeit relativ unkritisch komplexe Belegungsstrategien realisieren zu
können.

Praxisbeispiel Rhenus ICC: Palettenfördersystem, HRL und Staplerbereich

Das ICC der Rhenus AG in Giessen ist ein grosses Logistikzentrum, in dem vom
Materialflussrechner MFR ein Behältertransportsystem mit Sorter, ein Palettenfördersystem,
eine automatische Hochregalanlage mit gangwechselfähigen Regalbediengeräten und ein
grosser Staplerverkehrsbereich betrieben wird. Beim Wechsel der Nutzung des ICC von
einem Zentrum zur Filialbelieferung hin zu einem Logistikdienstleistungszentrum (auch) zur
Endkundenbelieferung konnte der vorhandene MFR nicht mehr angepasst werden. Umfang
und Anzahl der existierenden Steuerungen und deren mögliche unveränderte
Weiterverwendung ließen keine Freiheiten bei der Modellierung nach SAIL: Alle
unterlagerten Transportsysteme blieben unverändert. Interessant war nun, ob diese
Funktions- und Systemkonfiguration modellierbar ist. Die Steuerung der Behälteranlage ist
gegliedert in einen Behälterverwaltungsrechner, der für die steuernden SPSen an jedem
Scanner das Abbiege- bzw. Abwurfziel mitteilt. Er stellt die Funktionen
Fahrauftragsverwaltung F:FA und Richtungsentscheidung F:RE bereit. Damit ist er nach
SAIL ein Fördersegment A:FS. Die Kommunikation zwischen der Ressourcennutzung im
MFR und dem Auftragsrechner besteht lediglich aus Fahraufträgen des Typs RN mit der
Behälternummer und der Zielbahn. Die Funktion Ressourcennutzung ist hier trivial: es gibt
keine Einschränkung und keine Strategie: ein gefüllter Behälter wird an die Zielbahn
gefahren und ausgeschleust. Diese Funktionskonfiguration entspricht der Konfiguration B in
Bild 3.
Beim Palettenfördersystem ist vorgegeben, dass ein Fahrauftrag vom Typ RT verwendet
wird, wobei als Ziel jeweils der nächste Entscheidungspunkt eingetragen wird. Die Quelle
des Transportes wird mitgegeben weil die gesamte Anlage ohne Scanner betrieben wird. An
den Aufsetzpunkten von den Staplerbereichen und an den RBG-Abgabestellen wird damit
der Fahrauftragsverwaltung gleichzeitig ein Fahrauftrag vergeben und die Palette
identifiziert. Die Steuerungen können zwar selbstständig über weite Strecken routen und
dabei auch Kommunikationspunkte ohne Nachfrage überfahren, das aber wird nicht genutzt,
um die Anlage jederzeit so zu nutzen, wie der momentane Betriebszustand das erfordert. Im
Entwurf ist die gesamte Palettenförderanlage als ein Förderbereich A:FB modelliert, seine
innere Struktur entspricht der Konfiguration B in Bild 3.

Bild 4: Modellierung MFR Rhenus ICC
Die Regalanlage ist unterteilt in drei unabhängige Brandabschnitte mit je einer

Kopfsteuerung, die die Fahraufträge für alle Regalbediengeräte ihres Abschnitts
entgegennimmt und koordiniert. Jeder dieser Brandabschnitte ist also ein eigener
Förderbereich, für den im MFR je eine eigene komplizierte Ressourcennutzung benötigt wird,
weil bei der Vergabe der Aus- und Einlageraufträge an die einzelnen RBGs insbesondere die
Anzahl und Prioritäten der vorhandenen Aus- und Einlagerungen sowie der bekannte Zufluss
auf das Palettenfördersystem auf eine Gasse zu berücksichtigen sind. Der Typ des
Fahrauftrags und der Konfiguration entspricht dem des Palettenfördersystems.
Für den Betrieb des Staplerbereiches wird eine Ressourcennutzung benötigt, die jeden
Stapler als eigene Transportressource kennt und in Abhängigkeit seiner
Bereichszugehörigkeit und seiner technischen Eigenschaften mit einem Fahrauftrag belegt
wird. Der Fahrauftrag wird anstatt einer Steuerung an ein Dialogsystem übergeben, das die
weitere Abwicklung von der Aufnahme der Palette bis zur Abgabe erledigt. Aus Sicht der
Ressourcennutzung ist dieses Dialogsystem ein Fördersegment, das eben nur den einen
Fahrauftrag kennt, der gerade mit dem beauftragten "System" Staplerfahrer/Stapler
abgewickelt wird. So gesehen entspricht es der Funktionskonfiguration B in Bild 3, das
Transportsystem TS ist eben der Stapler mit seinem mobilen Terminal und dem
Dialogsystem als "Anlagensteuerung".

Praxisbeispiel Behälterfördersystem Renovierung BAUR NSS

Beim Versandhaus BAUR existiert eine Behälterförderanlage, mit der in der Hauptnutzung
Kartons als Nachschub aus dem Reservelager in die verschiedenen Kommissionierlager
transportiert werden, daher der Name NSS - NachschubSystemSteuerung. Dabei wird
sowohl vorsorglicher Nachschub als auch zeitkritische Nachversorgung gefahren. Neben
dieser Nutzung wird die Anlage auch als universelles Transportmittel für die verschiedensten
Dienste eingesetzt, wobei jede technisch realisierbare Quelle/Ziel-Beziehung tatsächlich
auch benutzt wird. Insbesondere wird die Beschickung der Folienpackmaschinen aus der
Kommissionierzone immer wichtiger, weil der Anteil kleiner Sendungen direkt zum
Endkunden steigt. Daraus folgt die Forderung nach einer Verfügbarkeit von mindestens 99%
für die Gesamtanlage, was für jede einzelne beteiligte Komponente bedeutet, dass ihre
Verfügbarkeit nahe 100% liegen muss. Die an der Steuerung beteiligten Systeme waren am
Ende ihres Lebenszyklus angelangt, teilweise waren beim Hersteller keine Ersatzteile mehr
lieferbar. Also wurde eine komplette Erneuerung notwendig.
Die Istzustandsanalyse ergab, dass die Aufteilung der Funktionen Konfiguration D aus Bild 3
entsprach. Die SPSen realisierten nur die reine Elementsteuerung, an einer
Entscheidungsstelle zeigten sie einem kleinen Prozessrechner (MMC) durch digitale Signale
(ein Signal für jeden Meldepunkt) das Vorhandensein eines Behälters an. In der MMC waren
die Richtungsentscheidung und die Fahrauftragsverwaltung angesiedelt, bei ihr waren auch
die Leselichtschranken für die Behälteridentifikation angeschlossen. In kürzester
Reaktionszeit musste die MMC den Behälter identifizieren, den Auftrag auswerten, die
Richtungsentscheidung fällen und per Signal an die SPS melden, wie abzubiegen ist. Die
MMC wurde von einem weiteren Rechner (HP1000) mit den Fahraufträgen versorgt. Dessen
Aufgaben entsprachen ungefähr der Funktion der Ressourcennutzung F:RN und weiteren
betriebswichtigen Funktionen, die dem Block Transportkoordination TK zuzuordnen sind.
Der erste Ansatz bei der Neukonzeption der Anlagenelemente sah vor, eine Aufteilung nach
der Konfiguration B in Bild 3 vorzunehmen, wobei ein neuer Rechner die Aufgaben der
Transportkoordination und der Ressourcennutzung und der dazugehörigen Dialoge zur
Pflege der Betriebsparameter übernehmen sollte (siehe Bild 5).

Bild 5: Funktionsverteilung Istzustand (blau) und Sollzustand (grün)
Da die Umstellung und auch der elektrische Umbau im laufenden Betrieb erfolgen mussten,
wurde jede vorhandene SPS genau wieder durch eine neue ersetzt, die damit auch die
Förderelemente (A:FE) aus diesem Bereich zu betreiben hatte. Die vorhandene Elementlogik
entsprach dem Konzept einer Architekturkomponente A:FE. Damit wurde es möglich, die
vorhandenen Programme für diese Aufgabe durch maschinelle Umsetzung in die neue
Steuerungsgeneration zu übertragen. Die Kommunikation eines Förderelementes mit der
Funktion Richtungsentscheidung F:RE blieb prinzipiell gleich: es wird weiterhin ein digitaler
Signalaustausch verwendet, nur wird jetzt nicht mehr über wirkliche elektrische Signale
zwischen verschiedenen Rechnern kommuniziert sondern über logische Signale (Merker) im
Hauptspeicher. Die Funktionsgruppe F:RE liegt jetzt im gleichen Rechner wie die
Anlagensteuerung, nämlich der SPS. In der Modellierung wurde durch die strikte
Signalkopplung jedem Entscheidungspunkt – also einer Architekturkomponente A:FE –eine
eigene Instanz der Funktion Richtungsentscheid zugeordnet. Damit entstand aus jedem
Verzweigungspunkt mit seinen zu- und wegführenden Förderern jeweils eine eigene
Komponente vom Typ Fördergruppe A:FG. Die Identifikation des am Entscheidungspunkt
vorbeifahrenden Behälters erfolgt durch Scanner direkt durch die Instanz F:RE. Die
programmtechnische Implementierung der Richtungsentscheidung wurde so gelöst, dass im
Programmablauf für jede Entscheidungsstelle, hier repräsentiert durch sein logisches Signal,
ein Unterprogramm (Funktionsbaustein) aufgerufen wird, dem der Name des

Entscheidungspunktes als Aktualparameter mitgegeben wird. Dieser Programmbaustein

liefert dann die Richtungsanweisung in Form einer Zahl, die dann wieder in logische Signale
zur Steuerung der Richtung umgesetzt wird. Damit ist erreicht, dass bei der Programmierung
einer Fördergruppe nur die Signale richtig "angeschlossen" werden müssen, die
Entscheidungslogik ist zentralisiert und gekapselt im Programmbaustein F:RE.
Die Funktion Richtungsentscheidung benötigt bei jeder Entscheidung auch Informationen
über den Fahrauftrag des Transportguts, den sie von der Funktion F:FA erfragen kann. Bei
der Zuordnung der Funktionsgruppen zu Geräten wurde die Aufteilung mit einer
steuerungsnahen Fahrauftragsverwaltung angestrebt. Das wurde so auch in zwei Bereichen
realisiert. Dort liegt die Fahrauftragsverwaltung für alle Fördergruppen einer Steuerung auch
in dieser SPS. Die Kommunikation zwischen der Richtungsentscheidung und der
Fahrauftragsverwaltung (zwischen F:RE und F:FA) erfolgt durch Aufruf eines
Programmbausteines, der als Aktualparameter die Identnummer des Transportgutes und die
Identifikation des aktuellen Entscheidungspunktes (also der aktuellen Fördergruppe A:FG)
erhält und die Richtungsinformation zurückliefert.
Im Bereich der Kommissionierung ist die Förderstrecke in jedem Stockwerk und damit in
jedem Steuerungsbereich ein großer in sich geschlossener Ring, von dem aus zu den
Kommissionierbahnhöfen ausgeschleust wird, auf dem es aber keine Zu- oder
Zusammenflüsse gibt. Der Übergang von solch einem Ring von und zu den anderen
Anlageteilen erfolgt jeweils an genau einer Stelle aus bzw. in die Anlage des
Zwischenbaues. Damit sind alle Entscheidungspunkte in einem Stockwerk rein sequenziell
miteinander verbunden, die Transportgüter erreichen mit sehr hoher Wahrscheinlichkeit den
nächsten Punkt in der Reihenfolge wie sie den vorigen passiert haben. Daraus ergibt sich die
Möglichkeit, die Funktionen der Fahrauftragsverwaltung aufzuteilen: die Richtungsanfrage
aus der Funktion F:RE kann durch Nachschau in einer der Fördergruppe zugeordneten Liste
sehr einfach beantwortet werden. Wird das Transportgut nicht in der Liste des aktuellen
Punktes gefunden, erfolgt keine Nachforschung in einer generellen Liste des Förderbereichs,
es wird in Kauf genommen, dass in diesem Fall, der ja nur einen manuell aufgesetzten
Behälter betreffen kann, dieser Behälter als Schwarzfahrer behandelt wird, er wird dann
weiter auf dem Ring gehalten und erst am Übergang zum Zwischenbau dorthin
ausgeschleust. Dort erfolgt eine vollständige Auftragsermittlung, falls nötig wird der Behälter

nun wider in den Ring eingeschleust und fährt nun mit Daten. Dieses Konzept ermöglicht es,
in allen Steuerungen dieses Förderbereiches eine Einfachstimplementierung der Funktion
F:FA zu realisieren, die eben nur in der Liste (FIFO) eines Punktes über die
Transportgutnummer die gegebenenfalls hinterlegte Richtungsanweisung ermittelt. Die Liste
ist im Speicher direkt bei den Daten mit den Betriebsparametern des Punktes im
Hauptspeicher abgelegt, der Aufruf der Fahrauftragsverwaltung aus der
Richtungsentscheidung geht hier über einen Programmbaustein, der nur diesen Teil der
Aufgabe erfüllt und sehr kurze Ausführungszeiten benötigt.
Bild 6: Architektur BAUR NSS und Aufteilung der Funktionen auf die Geräte
Für alle Steuerungen dieses Förderbereiches ist in einer eigenen SPS eine komplizierte
Variante der Fahrauftragsverwaltung implementiert. Wird ein Fahrauftrag von der
Ressourcennutzung erzeugt, geändert oder storniert, dann ermittelt die Funktion FA die
betroffenen Fördergruppen und erzeugt, ändert oder löscht in deren Auftragsliste die Daten.
Diese Funktion ist vergleichsweise kompliziert, aber bezüglich der Ausführungszeit relativ
unkritisch.
Diese Aufteilung hat sich trotz ihrer Komplexität bewährt und ist vorteilhaft einzusetzen,
wenn in kleinen Steuerungen sehr viele Entscheidungen pro Zeiteinheit zu fällen sind. Es ist
dann möglich, solche Anlagen – die sich natürlich vom Layout her eignen müssen – mit

günstigen Steuerungen zu betreiben, ohne Nachteile der Funktionalität und der

Modellierbarkeit in Kauf nehmen zu müssen.
Datenhaltung und Nachrichtenaustausch

Jede Funktionsgruppe hat bestimmte Daten bereitzuhalten und sie kommuniziert mit
anderen Funktionsgruppen. Es ist wichtig, hierbei einerseits die Anforderungen an die
Reaktionszeit und andererseits die Klarheit und Einfachheit des Nachrichtenflusses zu
beachten. Die technische Realisierung wird hier nicht betrachtet. Daten erhalten den Präfix
'D:', Nachrichten 'N:'. Um den Umfang der Daten bzw. der Nachrichten ungefähr abschätzen
zu können, dienen folgende Angaben aus realisierten Systemen:
Identifikation Transportobjekt: Zeichenkette 6 bis 22 Bytes, nicht zwingend numerisch.
Typisch sind 18 Bytes als NVE nach EAN128.
Identifikation eines Anlagenpunktes: Innerhalb eines Förderbereiches 4 bis 8 Bytes, auf der
Ebene eines gesamten Logistiksystems ca. 24 Bytes
Richtungsangabe: 2-stellige Zahl, in besonderen Ausnahmefällen (grosse Sorter) auch bis zu
4-stellig. Oft reicht ein Codevorrat für "Stop", "links", "rechts" und "geradeaus", jedoch ist bei
Verschiebewagen mit mehreren Anfahrpunkten oder Sortern mit ihren vielen Abwurfpunkten
oder bei langen Ausschleuserstrecken die Verwendung von Nummern für die Bezeichnung
der Abgänge erforderlich.
Betriebsparameter eines Punktes: 5 Zahlen als Richtungsangaben, zwei boolsche Werte.
Sinnvoll verwendet man die selben Codes wie für die Richtungsangabe im Fahrauftrag.
F:AS - Anlagensteuerung
Daten
Die Anlagensteuerung hält keine Daten oder nur wenige gerade solange, wie diese zur
Ansteuerung der Antriebe benötigt werden.

Nachrichten
N:RA - Richtungsanfrage an F:RE (ausgehend):
Wird ein Transportobjekt an einen Entscheidungspunkt aufgefördert, dann wendet sie sich
mit der Bezeichnung des Anlagenpunktes und (falls vorhanden) der
Transportobjektidentifikation an die Funktionsgruppe F:RE und erhält von dieser eine
Handlungsanweisung in der Form einer Richtungsinformation.
N:RI - Richtungsinformation von F:RE (eingehend):
direkt umsetzbare Anweisung für die Folgerichtung des Transportobjekts, kann auch "Stehen
bleiben" sein.
N:UM - Überfahrtmeldung an F:RE (ausgehend):
Wird ein Transportobjekt von einem Anlagenpunkt abgefördert, wird dies unter Angabe der
tatsächlich gefahrenen Richtung gemeldet.
F:RE - Richtungsentscheidung
Daten
Die Richtungsentscheidung hält für jeden Anlagenpunkt, an dem eine
Richtungsentscheidung getroffen werden muss, einen Parametersatz vor, mit dessen Hilfe
die Entscheidungslogik gesteuert wird. Diese Daten können verloren gehen, sie sind
jederzeit wieder aus der Funktionsgruppe F:RN zu gewinnen.
D:BP - Betriebsparameter Punkt:
Richtungsangaben für UFOs, Schwarzfahrer, Stauumfahrung, Zielanfragen,
Überfahrmeldungen
Nachrichten
N:RA - Richtungsanfrage von F:AS (eingehend):
Die Richtungsanfrage von F:AS wird mit den eigenen Parametern bearbeitet soweit dafür die
Punktparameter ausreichen. In der Regel werden zusätzlich die Daten des Fahrauftrags
benötigt. Daher wendet sich F:RE ihrerseits mit einer Richtungsanfrage an die
Funktionsgruppe F:FA.
N:RA - Richtungsanfrage von F:RE an F:FA (ausgehend):

Mit der Bezeichnung des aktuellen Punktes und der Identifikationsnummer des
Transportgutes wendet sich F:RE an F:FA um die Informationen für die weitere Bearbeitung
der Richtungsentscheidung zu erhalten.
N:RI - Richtungsinformation von F:FA (eingehend):
Information über das Vorliegen einer Information. Falls ja, Anweisung für die Folgerichtung
des Transportobjekts, kann auch "Stehen bleiben" sein.
N:RI - Richtungsinformation an F:AS (ausgehend):
direkt umsetzbare Anweisung für die Folgerichtung des Transportobjekts, kann auch "Stehen
bleiben" sein.
N:ZA - Zielanfrage an F:RN (ausgehend):
Ist kein Fahrauftrag vorhanden und verlangt die Parametrierung des Anlagenpunktes einen
solchen als Voraussetzung für den Weitertransport, dann stellt diese Funktionsgruppe eine
Zielanfrage an F:RN, erwartet aber nicht direkt eine Antwort.
N:UM - Überfahrtmeldung von F:AS (eingehend):
F:AS meldet die Überfahrt eines Punktes durch ein Transportobjekt in einer bestimmten
Richtung.
N:UM - Überfahrtmeldung an F:RN (ausgehend):
Wird ein Transportobjekt von einem Anlagenpunkt abgefördert (UM von F:AS) und verlangt
der Punktparameter eine Nachricht, dann wird diese Überfahrmeldung an F:RN gesendet.
N:BP - Betriebsparameter Punkt von F:RN (eingehend):
Überfahrmeldungen
F:FA - Fahrauftragsverwaltung
Daten
D:FA - Fahrauftrag:
Die Fahrauftragsverwaltung hält alle Fahraufträge in einer Weise vor, die geeignet ist, einen
sehr schnellen Zugriff über die Identnummer zu realisieren. Die Fahraufträge können
verloren gehen, sie sind jederzeit wieder von der Funktionsgruppe F:RN zu gewinnen.
Es sind jeweils der Quellort und die Abfahrtrichtung von der Quelle sowie der Zielort und die
am Ziel gewünschte Weiterfahrtrichtung (!) zu speichern.

Nachrichten
N:RA - Richtungsanfrage von F:RE (eingehend):
Die Richtungsanfrage von F:RE wird aus der Tabelle der Fahraufträge über die
Identifikationsnummer des Transportobjektes bearbeitet.
N:RI - Richtungsinformation an F:RE (ausgehend):
Information über das Vorliegen eines Fahrauftrages (kein Auftrag vorhanden, Auftrag
bekannt, aber keine Vorschrift für den aktuell angefragten Anlagenpunkt,
Richtungsanweisung) werden als Folge der Richtungsanfrage von F:RE an F:RE gesendet.
N:FA - Fahrauftrag oder Auftragsänderung von F:RN (eingehend):
wird in die Tabelle eingetragen
N:FS - Fahrauftragstorno von F:RN (eingehend):
Auftrag wird gelöscht
N:DA - Anfrage Download von F:RN (eingehend):
F:RN leitet Downloadsequenz ein.
N:DF - Freigabe Download an F:RN (ausgehend):
F:FA ist bereit, die Aufträge zu empfangen.
N:DE - Ende Download von F:RN (eingehend):
F:RN meldet das Ende der Downloadsequenz.
F:RN - Ressourcennutzung
Daten
Die Ressourcennutzung speichert alle Daten zur Fahrauftragssituation, zum
Belegungszustand der Fördermittel und die Betriebsparameter der einzelnen Anlagenpunkte
persistent. Sie muss alle Daten jederzeit an F:FA und F:RE nachliefern können.
D:BP - Betriebsparameter Punkt
Richtungsangaben für UFOs, Schwarzfahrer, Stauumfahrung, Defaultrichtung
D:RB - Ressourcenbelegung Punkt oder Weg
Kapazität, Anzahl Transportobjekt dorthin unterwegs, Anzahl Transportobjekte dort stehend
D:TA - Transportauftragsdaten
Standorte, Richtungen, beauftragter Transporter, Status

Nachrichten
N:ZA - Zielanfrage von F:RE (eingehend):
F:RE fragt an, wohin ein bestimmtes Transportobjekt zu transportieren ist. Aus der
Zielanfrage wird der momentane Standort des Transportobjektes gepflegt.
N:UM - Überfahrtmeldung von F:RE (eingehend):
Mit der Überfahrtmeldung wird der momentane Standort, die Transportrichtung und der
aktuelle Transporter gepflegt.
N:FA - Fahrauftrag oder Fahrauftragsänderung an F:FA (ausgehend):
Das Transportsystem erhält einen Fahrauftrag. Übermittelt werden die Identnummer, die
Quell- und Zielpunkte sowie die Richtungsanweisungen für diese Punkte
N:FS - Fahrauftragstorno an F:FA (ausgehend):
Auftrag wird gelöscht
N:BP - Betriebsparameter Punkt an F:RE (ausgehend):
Überfahrmeldungen.
N:TA - Transportaufträge oder Auftragsänderungen von F:TK (eingehend):
Transportauftrag mit allen Daten, die zur Einsteuerung nach den gültigen Strategien benötigt
werden.
N:TS - Transportauftragstorno von F:TK (eingehend):
N:SP - Strategieparameter von F:TK (eingehend):
Parameter, die zur Steuerung der Belegungsstrategien benötigt werden.
N:TQ - Transportauftragsquittung an F:TK (ausgehend):
Transportauftrag wird quittiert. Hierbei wird mitgegeben, warum und wo ein Transport
beendet wurde.
N:DA - Anfrage Download an F:RN (ausgehend):
F:RN leitet Downloadsequenz ein.
N:DF - Freigabe Download von F:RN (eingehend):
F:FA ist bereit, die Aufträge zu empfangen.
N:DE - Ende Download an F:RN (ausgehend):
F:RN meldet das Ende der Downloadsequenz.

Downloadsequenz
Eine Besonderheit in der Übermittlung der Nachrichten zwischen den Funktionen F:RN und
F:FA ist der Download der Fahraufträge. Es kann vorkommen, dass durch manuelle Eingriffe
in die Förderanlage (Wegnehmen von Transportobjekten) oder Probleme in der
Kommunikation oder Überlauf der Fahrauftragstabelle die Fahrauftragsdaten in F:FA nicht
mehr konsistent zur Anlagenbelegung sind. Dies kann beseitigt werden durch einen
Datendownload. Der Download kann sowohl von F:RN als auch von F:FA initiiert werden.
Geht die Initiative von F:RN aus, dann sendet F:RN die Anfrage N:DA an F:FA. F:FA stellt
sicher, dass seine Tabelle geleert wird und keine Anfragen von F:RE beantwortet werden
(Anlagenstillstand soweit möglich). Dann sendet F:FA an F:RN die Downloadfreigabe N:DF,
ebenso wenn F:FA den Download initiieren will. Nun sendet F:RN alle Fahraufträge an F:FA,
die laut Datenlage auf diesem Fördersegment unterwegs sein müssten oder sollten.
Anschliessend wird F:FA durch die Nachricht N:DE mitgeteilt, dass jetzt wieder der
Regelbetrieb aufgenommen werden kann, die Sequenz ist damit beendet.
F:TK - Transportkoordination
Daten
Je nach Komplexität der Transportinfrastruktur und der Nutzungsstrategien sind hier mehr
oder wenig viele applikationsspezifische Daten zu halten. Die Datenhaltung der
Transportaufträge selbst sowie deren Durchführungsfortschritt ist weitgehend unabhängig
von der Komplexität der oben genannten Punkte und somit einer Standardisierung
zugänglich. Für die Standardisierung bedeutet dies, dass der momentane bzw. letzte
Standort sowie der aktuelle Transporter als wichtigsten Zustandsdaten zum Transport die
entscheidenden Grössen sind.
Nachrichten
Die Schnittstelle zu den externen Systemen ist - wie auch die Daten - stark
applikationsspezifisch, jedoch kann bei der Vergabe und Quittierung von Transportaufträgen
postuliert werden, dass folgenden Angaben ausreichen: Identnummer und Typ des
Transportobjektes, dessen Standort und dessen Ziel bzw. die Folge von Zielen sowie der
späteste Bereitstellzeitpunkt.

N:TA - Transportaufträge oder Auftragsänderungen an F:RN

N:TS - Transportauftragstorno an F:RN
N:SP - Strategieparameter an F:RN
N:TQ - Transportauftragsquittung von F:RN
Beispiele für Nachrichten und Daten
Bild7: Datenhaltung und Kommunikation nach Komponenten und Ebenen

Aus der Realisierung mehrerer Anlagen seien hier Daten und Nachrichten dargestellt, die in
der Kommunikation zwischen F:RN und F:FA bzw. F:RE benutzt wurden. In allen
Nachrichten wird im Feld TG-Nummer die Zeichenfolge "NOREAD" übertragen, wenn sie
sich auf ein nicht identifiziertes Transportgut bezieht. Die hier vorgestellten Nachrichten sind
Beispiele aus ausgeführten Anlagen, das Telegramm besteht aus reinen ASCII-Zeichen. Die
Typbezeichnung 'A' kennzeichnet alphanumerische Felder, 'N' kennzeichnet numerische
ganzzahlige Felder, 'F' kennzeichnet Felder für numerische gebrochen rationale Zahlen und
'B' kennzeichnet Felder, in denen logische Werte (boolsche Werte) übertragen werden. Die
Zahl bezeichnet die Länge des Feldes

Tabelle 1: Daten und ihre Repräsentation in Nachrichten

Feldname Format Bemerkung
Gerät A4 Adressiertes bzw. meldendes Gerät
Kennung A2 Nachrichtenkennung
TG-Nummer A18 Transportgutnummer,
"NOREAD" falls no read
Quelle A4 Quellpunkt bzw. adressierter oder
meldender Punkt
Quellaktion N4
Ziel A4
Zielaktion N4
Überfahrgrund N2
Absolutes Warten B2 '1' = unbedingt warten
'0' = nicht unbedingt warten
Schwarzfahrtrichtung N4
Vorzugsrichtung N4
Noreadrichtung N4
Staurichtung N4
Überfahrmeldung B2 ' 1' = ÜF. melden
' 0' = ÜF. nicht melden

Nachrichten zwischen F:RN und F:FA bzw. F:RE

N:PK Punktkonfiguration
F:RN an F:RE oder F:TK an F:RE

Gerät A4 Adressiertes Gerät
Kennung A2 'PK'
Punkt A4 adressierter Punkt
Absolutes Warten B2
Schwarzfahrtrichtung N4
Vorzugsrichtung N4
Noreadrichtung N4
Staurichtung N4
Überfahrmeldung B2
N:FA Fahrauftrag
Dies ist die umfassendste Form des Fahrauftrages. Damit können Anlagen betrieben
werden, bei denen die Funktion F:FA und F:RE nicht routingfähig sind. Bei schnellen
Stetigförderanlagen (Behälter- oder Kartontransportsysteme oder Sorter) kann mit dieser
Form und der richtigen Parametrierung der Punkte in der Komponente F:RE ein
vergleichsweise geringer Kommunikationsaufwand erreicht werden. Routingfähige
Steuerungen benötigen die Quellaktion in keinem Fall während die Zielaktion sinnvoll
eingesetzt werden kann.

F:RN an F:FA

Kennung A2 'FA'
TG-Nummer A18 Transportgutnummer
Quelle A4
Quellaktion N4
Ziel A4
Zielaktion N4
N:FS Fahrauftragstorno
F:RN an F:FA

Kennung A2 'FS'
TG-Nummer A18 Transportgutnummer
N:FG Freigabe
Für ein angefragtes Transportgut existiert kein Transportauftrag. Daher kann auch kein
Fahrauftrag erzeugt werden. Also wird der Punkt freigefahren.
F:RN an F:RE

Gerät A4 adressiertes Gerät
Kennung A2 'FG'
Punkt A4 freizugebender Punkt
Aktion N4 Freifahrrichtung

N:ZA Zielanfrage
F:RE an F:RN

Gerät A4 meldendes Gerät
Kennung A2 'ZA'
TG-Nummer A18 Transportgutnummer, ggf.
'NOREAD'
Standort A4 aktueller Punkt
N:UM Überfahrmeldung
Die Überfahrmeldung ist die Übermenge der Freifahrmeldung eines Punktes, der
Vollzugsmeldung eines Transportes oder der eigentlichen Überfahrmeldung. Aus Sicht der
meldenden Funktion ist der semantische Unterschied unerheblich, der ist allein innerhalb der
Funktion F:RN zu ermitteln und auszuwerten. Er ergibt sich nur aus dem Kontext des
Fortschritts eines Transportauftrags. Im Überfahrgrund meldet die sendende Funktion
lediglich aufgrund welcher Vorgabe die Aktion ausgeführt wurde. Das sind also Codes für
Angaben wie "Quellaktion ausgeführt", "Zielaktion ausgeführt", "Noreadrichtung befahren",
"Vorzugsrichtung befahren" usw.
F:FA an F:RN bzw. F:RE an F:RN

Kennung A2 'UM'
TG-Nummer A18 Transportgutnummer, ggf.
'NOREAD'
Standort A4 aktueller Punkt
Aktion N4 befahrene Richtung
Überfahrgrund N2

N:DA Downloadanfrage
F:RN an F:FA

Kennung A2 'DA'
N:DF Downloadfreigabe
F:FA an F:RN

Kennung A2 'DF'
N:DE Downloadende
F:RN an F:FA

Kennung A2 'DE'

Kontakt:
Jens Karsten Rohrbäch

Projektleiter Forum Intralogistik im VDMA
Lyoner Straße 18
60528 Frankfurt am Main
Tel. +49 (0)69 6603 1508

Fax +49 (0)69 6603 2508

Beteiligte Firmen:
Arbeitskreis „Innovation und Standardisierung“ des Forum Intralogistik im VDMA


SAIL - Empfehlung Des FIL

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SAIL - Empfehlung Des FIL

Hochgeladen von

Copyright:

Verfügbare Formate

VDMA, Frankfurt am Main / Stand: 18. Mai 2006

Wiederverwendung durch Standardisierung

Dipl.-Ing. R. Sang, Eckelmann AG, Wiesbaden;

1. Hintergrund der System-Architektur-Entwicklung

Arbeitskreis „Innovation und Standardisierung“ Seite 2 von 47

2. Zielsetzung der SAIL

Arbeitskreis „Innovation und Standardisierung“ Seite 3 von 47

die auch heute oft noch monolithisch ausgeführten Standardlösungen in der

3. Innovation durch Funktionsstandardisierung

Arbeitskreis „Innovation und Standardisierung“ Seite 4 von 47

Maßgeblich für die gedankliche Aufarbeitung dieses Paradigmawechsels durch die

Die Vorteile dieser funktionszentrierten Anlagenmodellierung lassen sich zielgruppen-

Arbeitskreis „Innovation und Standardisierung“ Seite 5 von 47

4. Grundlagen der SAIL

Tabelle 1: Fördertechnische Funktionen

Arbeitskreis „Innovation und Standardisierung“ Seite 6 von 47

F:FA – Fahrauftragsverwaltung A:FS – Fördersegment

Abbildung 1 stellt die vier Komponententypen von SAIL in einer gekapselten

Arbeitskreis „Innovation und Standardisierung“ Seite 7 von 47

Bild 1: Kapselung der SAIL-Komponenten

Durch die konsequente Funktionskapselung wird erstmalig eine wiederverwendbare

Arbeitskreis „Innovation und Standardisierung“ Seite 8 von 47

Bild 2: Mechanikbaukasten und Steuerungsbaukasten

Arbeitskreis „Innovation und Standardisierung“ Seite 9 von 47

Allen Bausteinen gemeinsam ist eine nachrichtenorientierte Kommunikationsschnittstelle mit

Im Folgenden werden die generischen Komponenten der SAIL-Bausteinbibliothek

Arbeitskreis „Innovation und Standardisierung“ Seite 10 von 47

Bild 3: Förderelement (AE = Antriebselement)

Arbeitskreis „Innovation und Standardisierung“ Seite 11 von 47

Arbeitskreis „Innovation und Standardisierung“ Seite 12 von 47

Arbeitskreis „Innovation und Standardisierung“ Seite 13 von 47

6. Verifikation des SAIL an Elementarobjekten

Abbildung 8 demonstriert die Funktionskapselung anhand einfacher elementarer

Konfiguration 2 und 3 beschreiben schnelle Förderanlagen (z.B. Behälterfördertechnik), bei

Arbeitskreis „Innovation und Standardisierung“ Seite 14 von 47

Bild 8: Verifikation an Elementarobjekten

7. Detaillierung und weitere Verifikation der SAIL

Arbeitskreis „Innovation und Standardisierung“ Seite 15 von 47

Funktionen, Daten und Nachrichten in Theorie und Praxis

Dipl.-Ing. C. Gutbrod, Dr. Thomas + Partner GmbH, Karlsruhe

Aufgaben und Aufgabenteilung in Intralogistiksystemen bezüglich der

Arbeitskreis „Innovation und Standardisierung“ Seite 16 von 47

Der Transportauftrag (TA)

Der Fahrauftrag (FA)

Arbeitskreis „Innovation und Standardisierung“ Seite 17 von 47

Die Nutzungsoptimierung der Transportinfrastruktur

UFOs und Schwarzfahrer

Arbeitskreis „Innovation und Standardisierung“ Seite 18 von 47

um sie z.B. als schnell verfügbare Leergutreserve für unstetigen Bedarf an

Entscheidungsfindung an einem Anlagenpunkt

Arbeitskreis „Innovation und Standardisierung“ Seite 19 von 47

Bild 1: Entscheidungskriterien beim Fördern

Arbeitskreis „Innovation und Standardisierung“ Seite 20 von 47

Arbeitskreis „Innovation und Standardisierung“ Seite 21 von 47

Bild 2: Entscheidungskriterien bei der Ressourcennutzung

Arbeitskreis „Innovation und Standardisierung“ Seite 22 von 47

Arbeitskreis „Innovation und Standardisierung“ Seite 23 von 47

Arbeitskreis „Innovation und Standardisierung“ Seite 24 von 47

Arbeitskreis „Innovation und Standardisierung“ Seite 25 von 47

Anlagenelemente zur Kapselung der Funktionen bei der Modellierung

Arbeitskreis „Innovation und Standardisierung“ Seite 26 von 47

Bild 3: Typische Konfigurationen

Konfiguration C ist die klassische Anwendung eines Materialflussrechners (MFR). Ein