Inhaltsverzeichnis
Wie ist eine Systemarchitektur für den Materialfluss aufgebaut?
Ein automatisierter Materialfluss wird nicht von einem System gesteuert, sondern von einer Kette aufeinander aufbauender Ebenen. Ganz oben plant das ERP betriebswirtschaftlich, ganz unten bewegt eine SPS einen Antrieb. Dazwischen liegen das Lagerverwaltungssystem (LVS/WMS), das Bestände und Aufträge führt, und der Materialflussrechner (MFR), der daraus konkrete Transportbefehle für Fördertechnik, Regalbediengeräte und Fahrzeuge macht.
Diese Ebenen unterscheiden sich nicht nur in ihren Aufgaben, sondern vor allem in ihrem Zeithorizont: Das ERP denkt in Tagen und Wochen, das LVS in Minuten, der Materialflussrechner in Sekundenbruchteilen, die SPS in Millisekunden. Daraus folgt die wichtigste Architekturregel überhaupt – eine Funktion gehört auf die Ebene, deren Zeitverhalten zu ihr passt. Wer eine zeitkritische Entscheidung nach oben verlagert oder eine dispositive Entscheidung nach unten in die Steuerung programmiert, baut sich ein System, das entweder zu langsam oder nicht mehr änderbar ist.
Diese Seite beschreibt das Zusammenspiel der Ebenen, ordnet die gängigen Normen und Begriffe ein und benennt die Entscheidungen, die in Projekten erfahrungsgemäß den größten Hebel haben.
Was ordnet ISA-95 beziehungsweise IEC 62264 ein – und was nicht?
Der internationale Bezugsrahmen für diese Schichtung ist ISA-95, international übernommen als IEC 62264. Teil 1 (Modelle und Terminologie) liegt als IEC 62264-1 Edition 2.0 vom Mai 2013 vor; in den USA existiert die modifizierte Übernahme ANSI/ISA-95.00.01-2025. Der Standard beschreibt die Integration von Unternehmens- und Fertigungssystemen in fünf Ebenen:
| ISA-95-Ebene | Inhalt laut Standard | Entsprechung im Materialfluss |
|---|---|---|
| Level 4 | Geschäftsplanung und Logistik des Unternehmens | ERP |
| Level 3 | Manufacturing Operations Management: Ausführung, Qualität, Instandhaltung, Bestandsführung | LVS/WMS, MES – teilweise auch der dispositive Anteil des MFR |
| Level 2 | Überwachen und Bedienen des Prozesses | SCADA, Prozessleitsystem, ausführender Anteil des MFR |
| Level 1 | Messen und Stellen | SPS, Sensorik, Aktorik |
| Level 0 | Der physische Prozess selbst | Fördertechnik, RBG, Fahrzeuge, Ware |
Wichtig für die ehrliche Einordnung: ISA-95 ist aus der Prozess- und Fertigungsindustrie heraus entstanden. Der Standard kennt die intralogistischen Begriffe Lagerverwaltungssystem und Materialflussrechner nicht als eigene Kategorien. Die Zuordnung in der rechten Spalte ist deshalb eine fachliche Übertragung, keine Normaussage – sie ist in der Branche üblich und hilfreich, aber niemand kann sich darauf berufen, ein MFR sei „normgemäß Level 2“. Besonders der Materialflussrechner sitzt in der Praxis quer: Seine Auftragsdisposition gehört gedanklich nach Level 3, seine Telegrammkommunikation mit der Anlage nach Level 2.
Für die deutschsprachige Lagerlogistik ist zusätzlich die VDI-Richtlinie VDI 3601 „Warehouse-Management-Systeme“ (Ausgabe September 2015) relevant. Sie definiert Begriffe, Aufgabenbereiche und Leistungsanforderungen eines WMS und ist damit das Gegenstück zu ISA-95 auf der Lagerebene. Was ein Lagerverwaltungssystem im Einzelnen leistet, erklärt die Seite Warehouse Management System (WMS).
Hinweis zum Stand: Die genannten Ausgabestände sind über die Normendatenbanken von IEC, ISA und VDI belegt. Die Volltexte sind kostenpflichtig und wurden für diese Seite nicht eingesehen; ob ANSI/ISA-95.00.01-2025 inhaltlich von der IEC-Fassung abweicht, ist hier bewusst nicht behauptet.
Was macht das LVS, was der Materialflussrechner – und wo verläuft die Grenze?
Das ist die Schnittstelle, an der in Projekten die meiste Zeit verbrannt wird, weil die Grenze nicht technisch, sondern durch Vereinbarung entsteht.
Das Lagerverwaltungssystem beantwortet die Frage was, woher, wohin und warum: Es kennt Bestände, Lagerplätze, Chargen und Auftragsstrukturen, wendet Ein- und Auslagerstrategien an und erzeugt daraus Transportaufträge – „Behälter 4711 von Wareneingangsplatz 12 nach Lagerplatz A-03-14-2“.
Der Materialflussrechner beantwortet die Frage wie: Er zerlegt den Transportauftrag in Einzelbewegungen, wählt den Weg durch die Anlage, verteilt Aufträge auf Regalbediengeräte oder Fahrzeuge, überwacht Kapazitäten, Laufzeiten und Zielverfolgung und reagiert auf Stau, Störung und Zustandsänderungen der Anlage. Nach unten spricht er mit den Steuerungen, nach oben meldet er Vollzug oder Fehler.
| LVS / WMS | Materialflussrechner (MFR/MFS) | |
|---|---|---|
| Leitfrage | Was soll bewegt werden – und warum? | Wie kommt es dorthin? |
| Kennt | Bestand, Artikel, Charge, Lagerplatz, Auftrag | Anlagentopologie, Strecken, Geräte, Zustände |
| Erzeugt | Transportaufträge | Fahr- und Förderbefehle, Telegramme |
| Reagiert auf | Auftragslage, Bestandssituation, Priorität | Stau, Störung, Belegung, Gerätezustand |
| Bei Ausfall | Anlage läuft kurzfristig weiter, Nachschub und Disposition stehen | Materialfluss steht praktisch sofort |
Die Grenze ist nicht überall gleich. Es gibt drei übliche Schnitte, und jeder ist begründbar:
- Getrennte Systeme. LVS und MFR sind eigenständige Anwendungen mit dokumentierter Schnittstelle. Vorteil: klare Verantwortung, austauschbare Teile, üblich bei mehreren Anlagenbauern. Nachteil: eine Schnittstelle mehr, die spezifiziert, getestet und gepflegt werden muss.
- Integrierte Plattform. Beide Funktionen liegen in einem System und teilen sich Datenmodell und Oberfläche. Vorteil: keine Synchronisationslücke, ein Ansprechpartner, durchgängige Diagnose. Nachteil: die Auswahlentscheidung bindet beide Ebenen an einen Anbieter.
- Materialflusssteuerung im ERP. Bei SAP-Landschaften kann die Materialflusssteuerung als SAP EWM-MFS innerhalb von EWM laufen und direkt mit den Steuerungen kommunizieren – ohne separaten Materialflussrechner. Was EWM leistet und wo die Grenzen liegen, erklärt die Seite SAP EWM.
Eine dieser Varianten ist nicht pauschal besser. Entscheidend sind Anlagengröße, Zahl der beteiligten Gewerke, vorhandene ERP-Strategie und die Frage, wer die Anlage nach der Inbetriebnahme betreibt und weiterentwickelt.
Wie unterscheiden sich MES, WES und WCS von LVS und MFR?
Diese Abkürzungen werden in der Branche uneinheitlich verwendet – teils, weil sie aus unterschiedlichen Märkten stammen, teils weil Anbieter ihre Produkte hineindefinieren. Die nüchterne Sortierung:
| Begriff | Herkunft | Was gemeint ist | Verhältnis zur Materialfluss-Architektur |
|---|---|---|---|
| MES – Manufacturing Execution System | Fertigung, ISA-95 Level 3 | Führt Fertigungsaufträge auf dem Shopfloor aus, erfasst Ist-Daten, steuert Qualität und Ressourcen | Parallelsystem zum LVS auf gleicher Ebene: Das MES steuert die Produktion, das LVS das Lager. Beide müssen sich über die Materialversorgung verständigen. |
| WCS – Warehouse Control System | Angloamerikanische Intralogistik | Steuert die Automatiktechnik: Geräteansteuerung, Streckenführung, Lastverteilung | Funktional weitgehend das, was im deutschsprachigen Raum Materialflussrechner heißt. In der Praxis synonym verwendbar, wobei „WCS“ oft enger nur die Geräteanbindung meint. |
| WES – Warehouse Execution System | Angloamerikanische Intralogistik, jüngerer Begriff | Koordinationsschicht zwischen WMS und WCS: Auftragsfreigabe in Wellen, Balancierung von Personal und Automatik in Echtzeit | Kein fester Platz im Ebenenmodell. Manche Anbieter meinen ein eigenständiges Zwischensystem, andere ein WMS mit Echtzeitfunktionen, wieder andere ein WCS mit Auftragslogik. |
Für die Praxis ist wichtig: WES ist der am wenigsten trennscharfe der drei Begriffe. In Ausschreibungen und Angeboten sollte man ihn deshalb nie ungeprüft übernehmen, sondern nach Funktionen fragen – wer gibt die Aufträge frei, wer wählt den Weg, wer spricht mit der SPS, wer führt den Bestand? Wenn diese vier Fragen beantwortet sind, ist die Architektur geklärt, unabhängig davon, welches Akronym auf dem Deckblatt steht.
Wie ein MES im Detail arbeitet und wo es an die Lagerlogistik anschließt, erklärt die Seite Manufacturing Execution System (MES); die vorgelagerte Planung beschreibt die Seite PPS-System.
Wie unterscheidet sich der Materialflussrechner von SPS und Prozessleitsystem?
Der Materialflussrechner ist kein Echtzeitsystem im steuerungstechnischen Sinn. Er läuft auf Standard-IT, kommuniziert überwiegend über TCP/IP und hat damit kein deterministisch garantiertes Zeitverhalten im Millisekundenbereich. Genau deshalb liegt alles, was harte Echtzeit oder Sicherheit erfordert, in der SPS: Verriegelungen, Antriebssteuerung, Not-Halt, Kollisionsschutz. Der MFR entscheidet, wohin ein Behälter fährt; die SPS sorgt dafür, dass dabei nichts kollidiert. Die Grundlagen dazu erklärt die Seite SPS – speicherprogrammierbare Steuerung.
Ein Prozessleitsystem (PLS) wiederum ist die Antwort der Verfahrenstechnik auf dieselbe Ebene: Es überwacht und regelt kontinuierliche Größen wie Druck, Temperatur oder Durchfluss. Im Stückgutmaterialfluss übernimmt diese Rolle eher ein Visualisierungs- oder SCADA-System, das oft direkt Teil des Materialflussrechners ist – siehe die Seite Prozessleitsystem (PLS).
Diese Trennung hat eine praktische Konsequenz für die Verfügbarkeit: Fällt der Materialflussrechner aus, bleiben die Anlagenteile physisch beherrschbar, aber es werden keine neuen Transporte mehr disponiert. Fällt die SPS aus, steht das Gewerk. Redundanzkonzepte gehören deshalb auf beide Ebenen – und in die Spezifikation, nicht in die Inbetriebnahme.
Jede Ebenengrenze ist eine Schnittstelle, und jede Schnittstelle hat ihre eigene Technik-Tradition:
- ERP ↔ LVS: in SAP-Landschaften klassisch über IDoc und BAPI/RFC, in neueren Architekturen über OData oder REST/JSON-Schnittstellen; bei anderen ERP-Systemen meist REST oder dateibasierter Austausch. Charakteristisch ist der batch- oder auftragsbezogene Charakter: wenige, fachlich große Nachrichten. Die typischen Fallstricke beschreibt die Seite ERP-Anbindung und Systemintegration.
- LVS ↔ MFR: Transportauftrags- und Statusnachrichten, häufig als Message Queue, REST-Schnittstelle oder proprietäres Telegrammformat. Hier entscheidet sich, wie gut ein System bei Störungen wieder synchron wird – der wichtigste Punkt der Spezifikation ist deshalb nicht das Format, sondern das Wiederanlaufverhalten.
- MFR ↔ SPS: traditionell zeichenbasierte Telegramme über TCP/IP mit anlagenspezifisch vereinbartem Aufbau, daneben herstellerspezifische Kopplungen (etwa S7-Kommunikation) und zunehmend OPC UA als herstellerübergreifender Standard. Innerhalb der Automatisierung selbst arbeiten Feldbusse wie PROFINET, PROFIBUS oder EtherCAT.
- MFR ↔ mobile Robotik: für fahrerlose Transportfahrzeuge und AMR hat sich die von VDA und VDMA herausgegebene Schnittstelle VDA 5050 als gemeinsame Sprache zwischen Leitsteuerung und Fahrzeug etabliert – der praktische Nutzen liegt darin, Fahrzeuge verschiedener Hersteller in einer Flotte zu betreiben.
- Auswertung und Leitstand: Datenströme aus allen Ebenen laufen zusätzlich in Monitoring-, Kennzahlen- und Leitstandsysteme – häufig über MQTT, Message Broker oder direkte Datenbankanbindung.
Hinweis zum Stand: VDA 5050 wird laufend fortgeschrieben. Diese Seite nennt bewusst keine Versionsnummer, weil der aktuelle Stand projektbezogen zu prüfen ist – maßgeblich ist die zwischen Leitsteuerung und Fahrzeuglieferant vereinbarte Version.
Wie eine solche Architektur bis zu autonomen Fahrzeugen durchgezogen wird, zeigt das Praxisbeispiel Softwareplattform für autonome Transportrobotik.
Wer verantwortet was – Anlagenbauer oder Softwarehaus?
Technisch ist die Ebenengrenze klar; vertraglich ist sie es selten. Der übliche Schnitt: Der Anlagenbauer liefert Mechanik, Elektroplanung und SPS-Programmierung und garantiert die Funktion des Gewerks. Das Softwarehaus liefert LVS und Materialflussrechner und garantiert die Durchgängigkeit der Prozesse. Die Schnittstelle dazwischen gehört formal beiden – und damit im Zweifel niemandem.
Woran es in der Praxis hängt:
- Die Telegrammspezifikation. Wer sie schreibt, bestimmt die Architektur. Sie sollte vor der Vergabe existieren und Bestandteil beider Verträge sein, nicht Ergebnis der ersten Inbetriebnahmewoche.
- Die Leistungszusage. Eine Durchsatzzusage über die gesamte Kette lässt sich nur halten, wenn klar ist, wessen Software welchen Anteil der Zykluszeit verantwortet. Ohne diese Aufteilung endet jede Leistungsdiskussion in gegenseitiger Zuweisung.
- Die Störungsdiagnose. Wenn ein Behälter verschwindet, muss über alle Ebenen hinweg nachvollziehbar sein, wo er zuletzt gemeldet wurde. Durchgängige Protokollierung mit gemeinsamer Zeitbasis ist deshalb kein Komfort, sondern Voraussetzung für den Betrieb.
- Die Zuständigkeit nach Abnahme. Änderungen an Strategien und Abläufen fallen jahrelang an. Wer sie ausführen darf und kann, entscheidet über die Betriebskosten der Anlage weit stärker als der Anschaffungspreis.
Ein Softwarehaus, das beide Seiten spricht – Steuerungstechnik und Unternehmens-IT –, ist an dieser Stelle mehr als bequem: Es kann die Schnittstelle spezifizieren, bevor sie zum Streitpunkt wird. Genau darum geht es bei der Systemintegration in der Intralogistik.
Architekturfehler zeigen sich fast nie bei der Inbetriebnahme. Sie zeigen sich beim ersten Umbau, bei der ersten Erweiterung, beim ersten Anbieterwechsel – also drei bis zehn Jahre später, wenn niemand mehr da ist, der die ursprüngliche Entscheidung begründen kann. Die wiederkehrenden Muster:
- Dispositive Logik in der SPS. Der Klassiker: Eine Auslagerstrategie oder eine Prioritätsregel wird „schnell in der Steuerung“ gelöst, weil das zur Inbetriebnahme der kürzeste Weg war. Jede spätere Änderung wird damit zum Steuerungsprojekt mit Anlagenstillstand statt zur Parameteränderung.
- Undokumentierte Punkt-zu-Punkt-Verbindungen. Jede Direktkopplung zwischen zwei Systemen ist einzeln harmlos. Zwanzig davon ergeben eine Landschaft, in der niemand mehr sagen kann, welche Konsequenz das Abschalten eines Systems hat.
- Bestandsführung an zwei Stellen. Wenn ERP und LVS beide „den“ Bestand führen, gibt es früher oder später zwei Wahrheiten – und Diskussionen darüber, welches System recht hat, statt über den Prozess.
- Fehlende Mandanten- und Mehrstandortfähigkeit. Eine Lösung, die exakt auf ein Werk zugeschnitten ist, lässt sich beim Rollout auf das zweite nicht kopieren, sondern nur nachbauen.
- Keine Testumgebung. Wo es keine Möglichkeit gibt, Änderungen gegen eine simulierte Anlage zu prüfen, wird jede Anpassung im laufenden Betrieb getestet – mit entsprechender Risikobereitschaft und entsprechend seltenen Änderungen.
Die Gegenmaßnahme ist unspektakulär und wirkt: Verantwortlichkeiten je Ebene festlegen, Schnittstellen dokumentieren, Änderbarkeit als Anforderung formulieren. Diese drei Punkte kosten in der Planung Tage und sparen im Betrieb Jahre.
Woran erkennt man eine tragfähige Systemarchitektur?
Sieben Fragen, die sich ohne Anbietergespräch beantworten lassen und in Summe ein belastbares Bild ergeben:
- Ist für jedes Datenobjekt festgelegt, welches System es führend hält?
- Ist jede Schnittstelle dokumentiert – Format, Richtung, Frequenz, Fehlerfall, Wiederanlauf?
- Liegt jede Funktion auf der Ebene, deren Zeitverhalten zu ihr passt – insbesondere: steckt keine dispositive Logik in der SPS?
- Lassen sich Strategien und Parameter ohne Steuerungseingriff ändern?
- Gibt es eine Testumgebung, in der Änderungen vor dem Produktivgang geprüft werden können?
- Ist über alle Ebenen hinweg nachvollziehbar, wo sich eine Ladeeinheit zuletzt befand?
- Ist geklärt, wer welche Ebene nach der Abnahme weiterentwickelt?
Wo mehr als zwei dieser Fragen offen sind, ist nicht die Technik das Risiko, sondern die Zuständigkeit.
Wie grenzen sich PPS, ERP und MES ab?
| System | Fokus | Verhältnis zum PPS |
|---|---|---|
| PPS | Plant und steuert die Fertigung: Mengen, Termine, Kapazitäten | – |
| ERP | Steuert das gesamte Unternehmen: Warenwirtschaft, Personal, Finanzen, Vertrieb | Breiter angelegt. Viele ERP-Systeme enthalten das PPS als Modul. |
| MES | Steuert und überwacht die Fertigung in Echtzeit und erfasst Ist-Daten (BDE/MDE) | Prozessnäher. Setzt um, was das PPS geplant hat, und meldet die Ist-Daten zurück. |
In der Praxis ist das PPS häufig als Modul in ein ERP-System integriert.
Wo werden PPS-Systeme eingesetzt?
Vor allem von produzierenden Industrieunternehmen, die kosteneffizient nach hohen Qualitätsstandards fertigen müssen: Automobilindustrie, Metallverarbeitung, Kunststoffindustrie, Getränkeindustrie, Nahrungs- und Genussmittelindustrie, Medizintechnik, Maschinen- und Anlagenbau, Elektroindustrie, Werkzeugbau und weitere Produktionsbetriebe.
Der Druck auf Fertigungsprozesse nimmt weiter zu: Weltweiter Preisdruck, kleinere Losgrößen und kurze Durchlaufzeiten verlangen eine immer feiner abgestimmte Produktionsplanung und -steuerung.
Wie geht es von hier aus weiter?
Diese Seite beschreibt das Zusammenspiel der Ebenen im Materialfluss und die Entscheidungen, die dahinterstehen. Wie eine solche Architektur in einem konkreten Betrieb entworfen, umgesetzt und über Jahre weiterentwickelt wird – vom Schnitt zwischen LVS und Materialflussrechner über die ERP-Anbindung bis zur Steuerungsanbindung –, zeigt die Seite Systemintegration und Architektur für die Intralogistik. Welche Bausteine dafür zur Verfügung stehen, beschreibt die Plattformseite LOMAS.
Häufige Fragen zur Systemarchitektur im Materialfluss
Üblich ist eine Kette aus fünf Ebenen: ERP für die betriebswirtschaftliche Planung, LVS/WMS für Bestände und Lageraufträge, Materialflussrechner für die Umsetzung in Transportbefehle, SPS für die deterministische Steuerung der Anlagentechnik und die Anlage selbst als physische Ebene. Die Ebenen unterscheiden sich vor allem im Zeithorizont – von Tagen im ERP bis zu Millisekunden in der SPS.
Das Lagerverwaltungssystem entscheidet, was von wo nach wo bewegt werden soll, und führt dazu Bestände, Lagerplätze und Aufträge. Der Materialflussrechner entscheidet, wie dieser Transport durch die Anlage läuft: Wegewahl, Gerätezuteilung, Zielverfolgung, Reaktion auf Stau und Störung. Er kommuniziert direkt mit den Steuerungen.
ISA-95, international als IEC 62264 übernommen, beschreibt die Integration von Unternehmens- und Fertigungssystemen und teilt sie in die Ebenen 0 bis 4 ein. Teil 1 (Modelle und Terminologie) liegt als IEC 62264-1 Edition 2.0 von Mai 2013 vor. Der Standard stammt aus der Fertigungswelt und kennt die intralogistischen Begriffe LVS und Materialflussrechner nicht als eigene Kategorien – deren Zuordnung ist eine fachliche Übertragung, keine Normaussage.
Ein Warehouse Control System (WCS) steuert die Automatiktechnik und entspricht funktional weitgehend dem, was im deutschsprachigen Raum Materialflussrechner heißt. Ein Warehouse Execution System (WES) wird als Koordinationsschicht zwischen WMS und WCS beschrieben, die manuelle und automatisierte Bereiche in Echtzeit ausbalanciert. Der Begriff WES wird von Anbietern allerdings sehr unterschiedlich verwendet und sollte in Ausschreibungen immer über konkrete Funktionen geklärt werden.
Nur bei automatisierten Anlagen. In einem manuell betriebenen Lager mit Staplern und mobiler Datenerfassung genügt das LVS. Sobald Fördertechnik, Regalbediengeräte oder fahrerlose Fahrzeuge im Spiel sind, wird eine Materialflusssteuerung benötigt – entweder als eigenes System, als Bestandteil einer integrierten Plattform oder innerhalb des ERP, etwa als SAP EWM-MFS.
Weil die SPS für deterministische Steuerung und Sicherheit zuständig ist, nicht für Disposition. Eine Strategie in der Steuerung lässt sich später nur durch ein Steuerungsprojekt mit Test und Wiederinbetriebnahme ändern, während dieselbe Regel auf LVS-Ebene eine Parameteränderung im laufenden Betrieb wäre. Der kürzeste Weg bei der Inbetriebnahme ist hier regelmäßig der teuerste über die Lebensdauer der Anlage.
Weitere Fragen zur Systemarchitektur
Über welche Protokolle kommunizieren die Ebenen?
Zwischen ERP und LVS sind in SAP-Umgebungen IDoc, BAPI/RFC und zunehmend OData oder REST üblich. Zwischen LVS und Materialflussrechner kommen Message Queues, REST-Schnittstellen oder anlagenspezifische Telegrammformate zum Einsatz. Zwischen Materialflussrechner und SPS dominieren zeichenbasierte Telegramme über TCP/IP, herstellerspezifische Kopplungen und OPC UA; innerhalb der Automatisierung arbeiten Feldbusse wie PROFINET oder EtherCAT. Für fahrerlose Fahrzeuge hat sich die VDA-5050-Schnittstelle etabliert.
Wie migriert man eine Materialfluss-Architektur ohne Stillstand?
Schrittweise und entlang der Ebenen: eine Ebene nach der anderen erneuern, das neue System zunächst parallel mitlaufen lassen und die Ergebnisse vergleichen, die Anlage vorab in einer Emulation testen und für jeden Umschaltpunkt eine definierte Rückfallebene festlegen. Der gleichzeitige Tausch mehrerer Ebenen ist der häufigste Grund für ungeplante Stillstände.
Wer ist für die Schnittstelle zwischen Software und Anlage verantwortlich?
Formal beide Seiten – Anlagenbauer für die SPS, Softwarehaus für Materialflussrechner und LVS. Praktisch entscheidet die Telegrammspezifikation: Sie sollte vor der Vergabe vorliegen und Bestandteil beider Verträge sein. Fehlt sie, wird die Schnittstelle während der Inbetriebnahme verhandelt, und Durchsatz- oder Störungsdiskussionen enden in gegenseitiger Zuweisung.