Herr Dr. Dietmar Berthold ist seit 2001 bei der LEHMANN + PARTNER GmbH Erfurt in leitender Funktion in den Bereichen Entwicklung, Technologie und SIB-Datenmanagement tätig. Das Unternehmen bietet Produkte und Dienstleistungen für die Erfassung, Bewertung und das Management von Straßeninformationen an und ist sowohl im überörtlichen Netz als auch in kommunalen Straßennetzen tätig. Herr Dr. Berthold ist Beiratsmitglied des KIM-STRASSE e.V. und wirkt regelmäßig in OKSTRA-Expertengruppen mit. In der ARGE mit den Unternehmen INVER - Ingenieurbüro für Verkehrsanlagen GmbH Erfurt und HELLER Ingenieurgesellschaft mbH Darmstadt ist er im Rahmen eines Forschungsprojektes der BASt als Projektleiter tätig. 

Fast alle Prozesse, die eine Straße in ihrem Lebenszyklus durchläuft, werden heutzutage IT-technisch unterstützt. Die in der Prozesskette Planung – Bau – Betrieb eingesetzten IT-Verfahren nutzen jedoch historisch bedingt unterschiedliche Datenmodelle. Durch datentechnische Insellösungen und Medienbrüche ist oftmals eine aufwendige Neuerhebung von bereits vorhandenen Informationen erforderlich. Es werden Wege aufgezeigt, die einen qualitätsgesicherten und medienbruchfreien Informationsfluss bei der Übernahme von Entwurfsdaten in den Bestand nach ASB (Straßeninformationsbank/SIB) auf Basis des OKSTRA^® möglich machen. Ein gemeinsames Bezugssystem in Entwurf und Bestand ist dabei eine Grundvoraussetzung. Die verwendeten linearen Bezugssysteme (Hauptachse des Entwurfs, ASB-Bestandsachse) stimmen in vielen Situationen schon überein. Für einige Sonderfälle, wo dem nicht so ist, können aber bereits moderate Anpassungen in Regelwerken Abhilfe schaffen. Die zweite wichtige Voraussetzung ist, dass gleichartige Objekte in Entwurf und Bestand fachlich auf gleiche Weise beschrieben sein müssen. Auf Basis einer detaillierten Analyse der relevanten OKSTRA^®-Schemata ergeben sich Schlussfolgerungen, wie die Objekte und ihre Attribute aufeinander abgebildet bzw. welche Inhalte der Regelwerke harmonisiert werden müssen. Eine Überführung der Daten aus dem Entwurfssystem in die SIB wäre nach der Harmonisierung über spezielle OKSTRA^®-Schnittstellen zu realisieren. Der Übergabeprozess selbst kommt mit wenigen Nutzereingriffen aus. Aufgrund wirtschaftlicher Erwägungen wird das Verfahren nicht für jeden Sonderfall komplett anwendbar sein. Für diese werden alternative Lösungen zum Einsatz kommen müssen. Die Harmonisierung der gleichartigen Objekte in Entwurf und Bestand ist ein wichtiger Schritt, das bereichsübergreifende gemeinsame Verständnis für die Objekte des Straßen- und Verkehrswesens – das erklärte Ziel des OKSTRA^® – zu fördern.

Der Fachvortrag zur Veranstaltung ist im Volltext verfügbar. Das PDF enthält alle Bilder und Formeln.

Das Thema wurde im Rahmen eines Forschungsprojektes der BASt (FE 04.222/2008/ARB) in den Jahren 2009/2010 von drei Unternehmen bearbeitet, die in den Fachdisziplinen Planung und Bauvorbereitung, Bestandsverwaltung und Betrieb sowie Datenmanagement und Softwareentwicklung im Straßenwesen in Deutschland führend tätig sind: LEHMANN + PARTNER GmbH (Erfurt), INVER - Ingenieurbüro für Verkehrsanlagen GmbH (Erfurt) und HELLER Ingenieurgesellschaft mbH (Darmstadt). Das Projekt wurde durch eine Betreuungsgruppe aus Vertretern des Forschungsgebers und mehrerer Straßenbauverwaltungen sowie der OKSTRA^®-Pflegestelle begleitet. 

Einführung

Fast alle Prozesse, die eine Straße in ihrem Lebenszyklus durchläuft, werden heutzutage IT-technisch unterstützt. Die in der Prozesskette Planung – Bau – Betrieb eingesetzten IT-Verfahren haben jedoch teilweise keinen datentechnischen Bezug zu ihren vorangehenden bzw. nachfolgenden Prozessen. Durch datentechnische Insellösungen entstehen Medienbrüche, so dass eine – in der Regel aufwendige – Neuerhebung von bereits vorhandenen Informationen erforderlich ist.

Grundsätzlich ist ein automatisierter und medienbruchfreier Datenfluss zwischen den Teilprozessen erstrebenswert. Nicht zuletzt deswegen wurde vor einigen Jahren der Objektkatalog für das Straßen- und Verkehrswesen OKSTRA^® entwickelt. Dessen Grundgedanke ist es, durch Definition bestimmter Informationseinheiten (Objekte) in allen Prozessen ein gemeinsames Verständnis für das Gesamtobjekt „Straße“ und seine Teilobjekte zu entwickeln, darauf aufbauend ein prozessübergreifendes Datenmodell aufzubauen und auf dieser Grundlage die Daten frei von Medienbrüchen austauschen zu können.

Der OKSTRA^® wurde seinerzeit in mehreren Teilprojekten entwickelt, wobei sich jedes Teilprojekt mit bestimmten Bereichen befasste. Die Modellierung im Bereich der Bestandsdaten (für die Phase Betrieb) erfolgte auf Basis der vorhandenen Regelwerke – vor allem der ASB mit ihrer vorwiegend funktionalen Sicht auf die Objekte – während in den Bereichen Entwurf und Vermessung (für die Phase Planung/Bau) die bewährten Datenmodelle der Entwurfssysteme mit ihrem konstruktiv-geometrischen Ansatz und die RAS-Verm die Grundlage bildeten. Auch die laufende Fortschreibung des OKSTRA^® basiert auf diesen beiden Quellen. Die Folge ist, dass der Datenkatalog des OKSTRA^® zum Teil deutliche Unterschiede in der Modellierung ähnlicher Sachverhalte aufweist und zwischen den beiden Bereichen nicht harmonisiert ist. Damit nutzen auch die derzeit angewendeten IT-Fachverfahren unterschiedliche Datenmodelle und es fehlen die datentechnischen Schnittstellen für den jeweils anderen Bereich, so dass eine Datenübertragung an den Nahtstellen beider Bereiche bislang nicht ohne Medienbruch gelingt.

Betrachtet man die Objektmodellierungen in beiden Bereichen dagegen getrennt voneinander, so kann man feststellen, dass innerhalb der Bereiche gute Voraussetzungen zu einer medienbruchfreien Übertragung bestehen und Datentransfers auf Basis von OKSTRA^®-Schnittstellen in der Praxis auch durchgeführt werden. Der Datenaustausch per OKSTRA^® über alle Prozessschritte hinweg gehört jedoch noch nicht zum täglichen Geschäft der Straßenbauverwaltungen. Dafür sind noch organisatorische und technische Voraussetzungen zu schaffen.

Abbildung 1: Lebenszyklus einer Straße als Kreislaufprozess

Im Forschungsprojekt wurde die Machbarkeit eines qualitätsgesicherten und medienbruchfreien Informationsflusses untersucht und es wurden Wege aufgezeigt, die dies künftig ermöglichen sollen. Der Schwerpunkt lag auf der Übernahme von Entwurfsdaten in den Bestand nach ASB auf Basis des OKSTRA^®. 

Geschäftsprozesse und Regelwerke

Die Forschungsarbeit startete mit der Analyse der einschlägigen Regelwerke (z.B. ASB Netz, ASB Bestand, RAS-Verm, ZTV-Verm, RAS-L, RAA) und der datentechnischen Standards, vor allem des OKSTRA^®, sowie von einigen vorausgehenden Untersuchungen, die diese Thematik berühren. Es zeigte sich sehr rasch, dass gegenüber dem Geschäftsprozess, der in den Regelwerken gefordert ist (Mustergeschäftsprozess), in der Praxis derzeit noch verschiedene Kompromisse eingegangen werden. Dies hat unterschiedliche Ursachen.

Abbildung 2: Problembereiche bei der Anwendung einschlägiger Regelwerke in der Praxis

Zur Verifikation des tatsächlichen Geschäftsprozesses wurden von den Forschungsnehmern mit mehreren Straßenbauverwaltungen, Fachgremien und der OKSTRA^®-Pflegestelle Interviews geführt. Es wurden die einschlägigen Geschäftsprozesse, die praktische Anwendung bzw. Auslegung der technischen Regelwerke, die genutzten organisatorischen und datentechnischen Schnittstellen sowie die eingesetzten IT-Verfahren im Detail erfragt.

Im Ergebnis der Interviews zeigte sich, dass man allenfalls von einem typischen Geschäftsprozess sprechen kann, bei dem es länderweise Unterschiede gibt und der die vermuteten Abweichungen gegenüber dem Mustergeschäftsprozess aufweist. Die Abweichungen sind bei höher klassifizierten Straßen in der Regel geringer als bei denen mit niedrigerer Straßenklasse.

Aus den Gesprächen ergab sich eine Reihe von Ansatzpunkten zur Optimierung der angewendeten Regelwerke. Darauf aufbauend konnten wesentliche organisatorische und technische Aspekte der Prozesskette im Detail untersucht werden. 

Objektmodellierung und Modellverfahren

Erklärtes Ziel des Forschungsprojektes war es, die Grundlagen der Objektmodellierung in Entwurf und Bestand zu harmonisieren. Das ist ein qualitativ höherer Anspruch, der über die in jüngster Zeit untersuchten und auch praktizierten Verfahren hinausgeht, per Datenkonvertierung einen Ausführungsentwurf (oder auch einen Bestandsplan) in die SIB zu übertragen. Datenkonvertierungen nutzen die Tatsache aus, dass man die im Entwurf vorhandene geografische Objektverortung auf das Netzknotensystem nach ASB projizieren kann, schaffen allerdings keine tatsächliche Objektharmonisierung als Basis für eine automatische OKSTRA^®-basierte Übertragung eines Ausführungsentwurfs in den Bestand.

Den Informationsgehalt der zu untersuchenden Objekte kann man grob in die drei Kategorien Verortungsinformationen, fachliche Attribute sowie Meta- und sonstige Daten unterteilen.

Die Untersuchungen ergaben, dass ein medienbruchfreies Übertragungsverfahren, welches mit minimalen Nutzereingriffen auskommt, zwei wesentliche Voraussetzungen erfüllen muss:

1. Voraussetzung ist ein einheitliches (gemeinsames) Bezugssystem in Entwurf und Bestand, damit die Verortungsinformationen eindeutig und unter Verzicht auf komplexe und ggf. laufende Interaktionen des Anwenders erfordernde Algorithmen übertragen werden können.

2. Andererseits ist es erforderlich, dass für die gleichartigen Objekte die fachlichen Inhalte im Entwurf wie im Bestand auf vergleichbare Art und Weise beschrieben werden, d.h. es müssen harmonisierte Fachobjekte vorliegen. Erforderlich ist darüber hinaus stets auch die Harmonisierung der vielen Attributen zu Grunde liegenden Schlüsseltabellen.

Abbildung 3: Informationsgehalt von Objekten im Straßenwesen

Unter diesen Voraussetzungen ist ein Datenübertragungsverfahren, bestehend aus den zwei Schritten „OKSTRA-Export für Bestand“ (= neue Schnittstelle am Entwurfssystem) und „OKSTRA- Import vom Entwurf“ (= neue Schnittstelle am Bestandssystems/SIB) möglich. Das Verfahren kommt mit wenigen Nutzereingriffen aus und ist frei von der algorithmisch nicht unproblematischen Projektion von geografischen Koordinaten auf ein neues Bezugssystem.

Die Überführung der Metadaten und sonstigen Daten erfordert in der Regel keine zusätzlichen Voraussetzungen. 

Harmonisierung Bezugssysteme

Fast alle Verortungsinformationen beziehen sich auf eine bestimmte Achse, die das (lineare) Bezugssystem für die Objekte bildet. Im Entwurf ist dies zumeist die Hauptachse des Entwurfs, bei der Bestandsdokumentation die ASB-Bestandsachse. Basiselemente der Bezugssysteme sind jeweils abstrakte Knoten und Kanten.

Abbildung 4: Objekte im Entwurf und im Bestand

Die beiden genannten Achsen sind jedoch bezüglich ihrer Lage im Raum nicht per se identisch. Während im Entwurf die Achslagen nicht eindeutig durch das Regelwerk determiniert sind, um dem Entwerfer die notwendigen Spielräume zur Optimierung des Straßenentwurfs einzuräumen, sind die Bestandsachse und auch die Fahrbahnachse nach ASB eindeutig festgelegt.

Falls Entwurfsachse und Bestandsachse zusammenfallen, ist die Übertragung der Verortungsinformationen fast trivial: die Stationswerte sind durch eine einfache lineare Transformation zu ermitteln, die Abstände zur Achse sind sogar identisch. Dies ist in dem in Abbildung 4 dargestellten – stark vereinfachten – Fall gut zu erkennen. Zielführend ist es daher, in möglichst vielen Fällen ein für Entwurf und Bestand gemeinsames Bezugssystem zur Verfügung zu haben.

In der Praxis des Straßenbaus ist die identische Lage der Entwurfs- und Bestandsachse im Bereich der freien Strecke und in einfach gestalteten Knotenpunkten in vielen Fällen bereits gegeben bzw. wäre durch kleinere Änderungen von Prozessen und/oder Regelwerken künftig erreichbar.

Abbildung 5: Beispiele mit identischer Lage von Entwurfs- und Bestandsachse

Unter dieser Voraussetzung wurde im Projekt ein datentechnisches Modellverfahren entwickelt, wie (harmonisierte) OKSTRA^®-Fachobjekte aus dem Entwurf in den Bestand überführt und auf der ASB-Bestandsachse verortet werden können. Das Verfahren geht von einem übergeordneten Knoten-Kanten-Modell aus, welches als zwei Spezialfälle das Bezugssystem des Entwurfs, bestehend aus Achselementen und Achshauptpunkten, und das Netzknotensystem nach ASB, bestehend aus Abschnitten/Ästen und Nullpunkten, enthält. Das ebenfalls in der ASB beschriebene für Routingzwecke geeignete Modell aus Straßenelementen und Verbindungspunkten ordnet sich hier ebenfalls mit unter.

Abbildung 6: Übergeordnetes Knoten-Kanten-Modell

Die Transformation der Verortungsinformation aus dem einen in das andere Bezugssystem wäre Gegenstand des Schnittstellenmoduls „OKSTRA-Import vom Entwurf“. Algorithmisch werden dazu nur SIB-Standardwerkzeuge (Netzoperationen wie AoA teilen, verschmelzen, drehen, die in einer geeigneten Abfolge hintereinander ausgeführt werden müssen) benötigt, die automatisch ablaufen können oder die der fachkundige Nutzer der SIB überwacht bzw. steuert. Durch Netzoperationen werden auch die fachlichen Attribute der Objekte auf korrekte Weise transformiert. Objekte, die aus dem Entwurf stammen, können bzgl. ihrer Objektposition nach ASB stets mit hohem Detaillierungsgrad gespeichert werden.

Sonderfälle, in denen eine identische Lage der Achsen in Entwurf und Bestand nicht herstellbar ist (z.B. Äste, Kreisverkehrsplätze, Übergang RQ 15,5 auf 10,5 durch Fahrbahnrandverziehung), deckt das Modellverfahren zunächst nicht ab. Dafür könnten andere Lösungen zum Einsatz kommen, welche z.B. die Verortungsinformationen der Entwurfsobjekte auf geografischem Wege auf das Netzknotensystem projizieren.

Um diese Sonderfälle in der Praxis zu reduzieren, reichen schon kleinere Anpassungen in den Geschäftsprozessen und Regelwerken aus. Zwei aus Sicht der Forschungsnehmer wichtige Anpassungsvorschläge, die im Projekt erarbeitet wurden, lauten:

• Die Anwendung der Regellösung für die Lage der Entwurfsachse sollte bei symmetrischen, sich nicht ändernden Querschnitten im Regelwerk festgeschrieben werden, d.h. der Entwurfsbearbeiter soll in diesen Fällen seinen Spielraum bei der Wahl der Achse ohne zwingenden Grund nicht ausnutzen.
• Die Definition der Bestandsachse für zweibahnige Strecken sollte in der ASB Netz wie folgt gefasst werden:
  „…Die Bestandsachse nach ASB wird als Mitte zwischen den beiden Fahrbahnachsen festgelegt. …“

Harmonisierung Fachobjekte

Durch das in Abbildung 6 skizzierte übergeordnete Knoten-Kanten-Modell werden die Netzmodellierung und die Verortung der Fachobjekte in Entwurf und Bestand technisch kompatibel. Der zweite, nicht minder wichtige Schritt für eine künftige automatisierte Datenübertragung besteht in der fachlich-inhaltlichen Harmonisierung der gleichartigen Objekte aus Entwurf und Bestand. Dazu war eine detaillierte Untersuchung auf der Ebene der Objektattribute und OKSTRA^®-Schlüsseltabellen notwendig. Es ergaben sich konkrete Schlussfolgerungen, wie der künftige „OKSTRA-Export für Bestand“ als Schnittstellenmodul am Entwurfssystem ausgeführt werden muss.

Die ideale Harmonisierung würde darin bestehen, gleichartige Objekte nur einmal im OKSTRA^® zu modellieren (vollständige Harmonisierung). Bei den meisten Objekten ist dies jedoch nicht möglich oder wegen des damit verbundenen sehr tiefen Eingriffs in alle etablierten Prozesse und technischen System zu aufwendig.

Daher wird der Weg einer "sanften" Harmonisierung (Teilharmonisierung) vorgeschlagen. Dabei werden alle gleichen Attribute in Superklassen ausgelagert. Die restlichen Attribute müssen im Übernahmeprozess "umgerechnet" werden. Das heißt, für diese muss eine mehr oder weniger komplexe Abbildungsvorschrift angegeben werden können. Diese Umrechung wäre u.a. Gegenstand der Schnittstelle „OKSTRA-Export für Bestand“ am Entwurfssystem.

Beispiel Querschnitte

Am Beispiel der Querschnitte soll dies erläutert werden. Hier ist die Herangehensweise in Entwurf und Bestand deutlich unterschiedlich. Während im Entwurf die Trennung zwischen Erdbau/Geländemodellierung und Herstellung der befestigten Fläche auch im OKSTRA^®- Datenmodell seinen Niederschlag findet (Querprofile und Deckenbuch), wird im Bestand der hergestellte Straßenkörper als Ganzes betrachtet (Querschnittsdaten).

Da sich der Entwurfsbearbeiter auch künftig hier nur mit den Querprofilen und dem Deckenbuch befassen soll, muss die Schnittstelle „OKSTRA-Export für Bestand“ die Querschnittsdaten im sogenannten Trapezmodell nach ASB ausgeben. Da Querprofile und Deckenbuch im Entwurf üblicherweise in verschiedenen Stationsrastern vorliegen, welches für die Querschnittsdaten nach ASB nicht notwendigerweise relevant ist, sind im Schnittstellenmodul entsprechende Verschneidungsalgorithmen zu implementieren. Diese ordnen auch die auf der Bestandsseite benötigten fachlichen Attribute zu (Streifenart, Abstände zur Achse, abgewickelte Breite von Böschungen u.ä.). In Einzelfällen, wo dies nicht eindeutig möglich ist, wird eine Begutachtung und ggf. Nachkorrektur beim Import in die SIB durch den fachkundigen SIB-Bearbeiter erforderlich sein.

Im Zuge der Harmonisierung der OKSTRA^®-Objekte, die den Straßenquerschnitt beschreiben, muss durch ein geeignetes Mapping ein Zusammenhang zwischen den derzeit nicht harmonisierten Schlüsseltabellen in Entwurf (Art_verallgemeinerte_Spur, Art_Profillinie) und Bestand (Streifenart) hergestellt werden.

Anpassungsbedarf im Bereich der Regelwerke gibt es hier hinsichtlich der einheitlichen Verwendung von Fachbegriffen wie „Fahrbahn“ und „Fahrbahnrand“, die derzeit in den Entwurfsregelwerken (RAS-Q, RAL, RAA) anders definiert sind als in der ASB.  

Künftiger Geschäftsprozess

Mit dem beschriebenen Verfahren für die automatisierte Datenübernahme ergibt sich nach erfolgter Harmonisierung der OKSTRA^®-Objekte, nach Umsetzung der formulierten Modifikationen in den Regelwerken und nach Implementierung der benötigten Schnittstellen an den Systemen ein Soll-Geschäftsprozess.

Dieser sieht im Kern vor, dass Daten aus dem Entwurf in den Bestand weitgehend ohne Medienbruch übertragen werden können. Die Überwachung des Imports in die SIB durch einen fachkundigen Bearbeiter ist ebenso möglich wie sinnvoll, wie auch Feldvergleiche und Nacherfassungen bei einigen Objekten und Attributen vorgesehen sind. Letztere können im Zuge der meist ohnehin notwendigen örtlichen (Um-) Stationierung erfolgen.

Durch die Möglichkeit, dass ein fachkundiger Bearbeiter den Übernahmeprozess in die SIB steuert, können Streckenbereiche, die als Sonderfälle zu behandeln sind, von diesem erkannt und beim automatischen "OKSTRA-Import vom Entwurf" ausgenommen werden.

Für das reibungslose Funktionieren der Datenübertragung sind jedoch auch Veränderungen bei einigen Teilprozessen erforderlich. Die bereits bestehenden Möglichkeiten zur Objektbildung in den Entwurfssystemen müssen in der Planungspraxis durchgängig umgesetzt werden. Wenn der Ausführungsentwurf künftig die Grundlage für die Datenübergabe an die SIB bildet, erlangt die Fortschreibung des Entwurfs in der Bauphase eine hohe Bedeutung. Dies umso mehr noch, da infolge des Wettbewerbsrechts statt der konkreten Ausprägung der Objekte bei der Bauausschreibung zunehmend nur noch deren funktionelle Anforderungen beschrieben werden.

Hinsichtlich der Wirtschaftlichkeit können einige qualitative, auf Erfahrungswerten beruhende Aussagen getroffen werden. So ist davon auszugehen, dass die Umsetzung des automatisierten Datenaustausches zu keinem nennenswerten Mehraufwand im Entwurfsprozess führen wird, da die neuen Prozesse hier weitgehend technischer Art sind und im Schnittstellenmodul "OKSTRA-Export für Bestand" implementiert werden. Das größte Einsparpotenzial im Prozess ergibt sich durch den weitgehenden Wegfall örtlicher Erfassungen zur Fortführung der SIB. Die Aufwendungen bei der Überwachung des "OKSTRA-Imports vom Entwurf" durch den SIB-Bearbeiter werden in etwa vergleichbar sein mit dem derzeitigen Aufwand bei der Übernahme und Prüfung von örtlich erfassten Fortführungsdaten. 

Zusammenfassung

Nach den im Forschungsprojekt gewonnenen Erkenntnissen ist hohes Potenzial zur Verbesserung der Wirtschaftlichkeit bei einer teilautomatisierten Datenübernahme von der Ausführungsplanung in die Straßeninformationsbank vorhanden.

Als nächster Schritt wäre es erforderlich, die Harmonisierung der fachlichen OKSTRA^®-Objektmodellierungen – ggf. zunächst auch prototypisch – umzusetzen, um das Datenübertragungsverfahren praktisch einsetzen und erproben zu können. Denn ein einheitliches (gemeinsames) Bezugssystem für Entwurf und Bestand liegt bei der überwiegenden Zahl von Straßenbaumaßnahmen – ggf. unter Ausnahme von Teilbereichen wie Knotenpunkte – bereits vor. Man denke hier beispielsweise an Baumaßnahmen auf BAB-Abschnitten.

Die Harmonisierung der gleichartigen Objekte in Entwurf und Bestand ist eine Voraussetzung, um dem „grenzenlosen Datenaustausch“ sowie dem erklärten Ziel des OKSTRA^®, bereichsübergreifend ein gemeinsames Verständnis für die Objekte des Straßen- und Verkehrswesens herzustellen, einen entscheidenden Schritt näher zu kommen.

Ein vollständiger und vollautomatischer Übernahmeprozess „im Hintergrund“ würde dieses Verständnis nur bedingt fördern. Vielmehr tragen aus Sicht der Forschungsnehmer überschaubare und in den Grundzügen für den Sachbearbeiter nachvollziehbare Teilprozesse, die seine Arbeit erleichtern und effizienter machen und die er auch selbst überwachen und steuern kann, viel besser diesem Ziel Rechnung. Der OKSTRA^® leistet damit gleichermaßen einen Beitrag, um noch bestehende organisatorische Brüche in der Prozesskette Planung – Bau – Betrieb zu überwinden.