Unsere Straßeninfrastruktur ist eines der bedeutendsten Investitionsgüter und Grundlage für Wohlstand und Wachstum. Ihre Erhaltung ist notwendig, um unseren Wohlstand zu sichern und Wachstum zu ermöglichen. Ziel des systematischen Erhaltungsmanagements ist es, Straßen wirtschaftlich und technisch effizient zu erhalten, um mit den verfügbaren Mitteln eine möglichst hohe Angebotsqualität und Verfügbarkeit zu gewährleisten.

Erhaltungsmanagement ist ein kontinuierlicher Prozess, der für die Abwicklung und Steuerung Daten und Kennzahlen benötigt. So sind turnusmäßig Daten über den Ist-Zustand nötig, um den akuten Bedarf zu ermitteln. Anhand dieser Daten können Maßnahmen festgelegt und notwendige Finanzmittel abgeleitet werden. Es folgt die Aufstellung eines Bauprogramms, dass es in den Folgejahren abzuarbeiten gilt. Dieser Prozess wird operatives Erhaltungsmanagement genannt.

Die Frage nach den langfristig erforderlichen Erhaltungsmitteln zur Sicherstellung einer bestimmten Angebotsqualität wird im Rahmen des strategischen Erhaltungsmanagements beantwortet. Hierbei werden modellbasierten Verfahren eingesetzt, die den Ist-Zustand für einen bestimmten Analysezeitraum (typisch sind z.B. 20 Jahre) prognostizieren und eine optimale Erhaltungserhaltungsstrategie ermitteln.

Unsere Straßeninfrastruktur ist eines der bedeutendsten Investitionsgüter und Grundlage für Wohlstand und Wachstum. Ihre Erhaltung ist notwendig, um unseren Wohlstand zu sichern und Wachstum zu ermöglichen. Ziel des systematischen Erhaltungsmanagements ist es, Straßen wirtschaftlich und technisch effizient zu erhalten, um mit den verfügbaren Mitteln eine möglichst hohe Angebotsqualität und Verfügbarkeit zu gewährleisten.

Erhaltungsmanagement ist ein kontinuierlicher Prozess, der für die Abwicklung und Steuerung Daten und Kennzahlen benötigt. So sind turnusmäßig Daten über den Ist-Zustand nötig, um den akuten Bedarf zu ermitteln. Anhand dieser Daten können Maßnahmen festgelegt und notwendige Finanzmittel abgeleitet werden. Es folgt die Aufstellung eines Bauprogramms, dass es in den Folgejahren abzuarbeiten gilt. Dieser Prozess wird operatives Erhaltungsmanagement genannt.

Die Frage nach den langfristig erforderlichen Erhaltungsmitteln zur Sicherstellung einer bestimmten Angebotsqualität wird im Rahmen des strategischen Erhaltungsmanagements beantwortet. Hierbei werden modellbasierten Verfahren eingesetzt, die den Ist-Zustand für einen bestimmten Analysezeitraum (typisch sind z.B. 20 Jahre) prognostizieren und eine optimale Erhaltungserhaltungsstrategie ermitteln.

Aufbaudaten sind sowohl für das operative als auch das strategische Erhaltungsmanagement von wesentlicher Bedeutung. Zwar erhält man im Rahmen der Zustandserfassung und -bewertung (ZEB) qualitätsgesicherte und zuverlässige Informationen über den Zustand der Oberfläche der Straße, aber nur durch genaue Kenntnisse über den vorhandenen Straßenaufbau können Zustandsprognosen durchgeführt und Entscheidungen für die richtige Erhaltungs- oder Instandsetzungsmaßnahme getroffen werden.

Das ZEB-Verfahren ist in hohem Maße standardisiert und beinhaltet ein umfangreiches Qualitätsmanagement. Im Gegensatz dazu gibt es für die Erfassung und Qualitätssicherung von Aufbaudaten kein bundesweit geregeltes und standardisiertes Verfahren. Teils liegen plausible Daten vor, teils sind die Daten jedoch auch unvollständig, nicht mehr aktuell oder fehlerhaft.

Damit die Aufbaudaten zuverlässig, vollständig und in hoher Qualität vorliegen, sind verschiedene Aspekte zu betrachten:

• Die Bearbeitung von Aufbaudaten muss zeitnah und zuverlässig erfolgen. Optimal wäre es, wenn unmittelbar nach Durchführung einer Maßnahme die Fortschreibung der Aufbaudaten durch einen Mitarbeiter erfolgt, der die Maßnahme kennt und über die notwendige Fachkenntnis verfügt.
• Die Bearbeitung von Aufbaudaten muss einfach sein. Es gilt die vorhandenen Prozesse abzubilden, um die Anwender in ihrer Arbeit zu unterstützen. Nur somit kann eine hohe Akzeptanz bei den betroffenen Mitarbeitern erreicht werden.
• Die Aufbaudaten müssen in standardisierter Form (OKSTRA^®, ASB) in einer Straßendatenbank gepflegt werden. Nur somit kann sichergestellt werden, dass Netzoperationen und Historisierungen berücksichtigt werden und die Daten nachhaltig nutzbar sind.

Es wird deutlich, dass auf der einen Seite die Bearbeitung von Aufbaudaten prozessorientiert und einfach sein muss, auf der anderen Seite jedoch die notwendigerweise komplexen Datenmodellimplementierungen bedient werden müssen. Kurzum: Auf der einen Seite steht der Fachingenieur, auf der anderen Seite der (sehr komplexe) OKSTRA^®.

Wie sehen diese „Seiten“ im Detail aus? Im OKSTRA^® respektive der ASB sind Aufbaudaten geometrisch als viereckige gerade Prismen modelliert. Die räumliche Ausdehnung einer Aufbauschicht ist dabei durch einen Streckenbezug, vier Punktkoordinaten, eine Höhenkoordinate und eine Dicke definiert. Der Straßenaufbau kann somit sehr detailliert bzw. originalgetreu abgebbildet werden. Bei Baumaßnahmen werden oftmals nur der obere Teil des Aufbaus und häufig auch nur Teile des Querschnitts erneuert. Modelltechnisch müssen somit die vorhandenen Aufbauschichtprismen geschnitten, geteilt bzw. entfernt und die „Leerräume“ durch neue aufgefüllt werden. Erfolgt im Zuge einer Erhaltungsmaßnahme eine Verstärkung des Oberbaus werden die Auswirkungen auf die zugrunde liegenden Daten noch komplexer: Aufbauschichtprismen müssen nicht nur geteilt oder geschnitten, sondern auch in der Höhenlage angepasst werden.

Das alles interessiert den Fachingenieur meist nur wenig. Er kennt den Anfang und das Ende der Baumaßnahme, er weiß welche Querschnittselemente betroffen sind (zumeist sind es Fahrstreifen oder die halbe oder gesamte Fahrbahn), wie viel Material abgetragen und welches Material in welcher Stärke eingebaut wurde. Dementsprechend möchte er auch nur diese ihm bekannten Informationen eingeben und keine Umrechnungen oder gar geometrischen Transformationen durchführen.

Ziel eines Editors für Aufbaudaten muss es daher sein, beide Seiten optimal zu bedienen bzw. zu verbinden, d.h. ein am Bedarf des Fachingenieurs orientiertes, möglichst einfaches Frontend und eine im Hintergrund arbeitende Middleware, welche die Operationen auf der Straßendatenbank zuverlässig durchführt.

Diese Erkenntnis ist nicht neu. Vor über 10 Jahren wurde durch die HELLER Ingenieurgesellschaft mbH der erste grafische Aufbaudateneditor mit Direktzugriff auf eine Straßendatenbank entwickelt. Der Editor wurde von vielen Anwendern sehr geschätzt, da sie nicht mehr auf tabellarischer Ebene die Daten eingeben und kontrollieren mussten, sondern eine grafische Eingabe und Kontrolle möglich war. Einige Anwender vermissten jedoch die Möglichkeit, Daten tabellarisch einzugeben und fanden die grafische Eingabemöglichkeit lediglich interessant, aber nicht effizient. Diese Anwender waren meist sehr erfahren und geschult im Umgang mit der Datenbank. Neue oder weniger erfahrene Anwender hingegen bevorzugten die grafische Eingabemöglichkeit.

Im Laufe der Zeit wurde der grafische Aufbaudateneditor immer weiterentwickelt und um neue Funktionen zur Abbildung von Fachprozessen sowie zur Datenprüfung und Visualisierung erweitert, z.B.

• Funktion für das Fräsen und Einbauen
• Anlegen von Standardmaßnahmentypen
• Visualisierung auf Karten und Streckenbändern
• Erstellung von Berichten
• Durchführung von fachlichen Prüfungen
• Festlegung des Bearbeitungsbereichs per Fahrstreifen- bzw. Querschnittselement
• Planansicht der Straße mit Aufbauschnitten
• Copy- und Paste-Funktion von Aufbauten im Querschnittsband
• Erstellung und Verwaltung von Aufbaufavoriten

Die folgenden Screenshots zeigen beispielhaft einige der o.g. Funktionen:
Bilder in der PDF

In einigen Bundesländern ist der Einsatz des Editors zu einem nicht mehr wegzudenkenden Standard-IT-Fachverfahren geworden. Durch die neuen Funktionen, die im Zuge der laufenden Weiterentwicklung implementiert wurden, sind auch mittlerweile die meisten Skeptiker überzeugt und verwenden den Aufbaudateneditor gerne.

Der Aufbaudateneditor ist mittlerweile in 7 Bundesländern im Einsatz. 5 Bundesländer haben dabei eine Datenbank im Einsatz, bei denen ein älteres ASB-Datenbankmodell implementiert ist. Hinzu kamen jedoch in jüngster Zeit 2 Bundesländer, die über ein aktuelles OKSTRA^®-konformes Aufbaudatenmodell verfügen. Hierbei wurde einiges an Erfahrungen mit dem komplexen geometrischen Modelle gesammelt.

Zielsetzung des Aufbaudateneditors war es, die Bearbeitung von Aufbaudaten zu vereinfachen. Zudem bestand eine Anforderung darin, dass der Editor direkt auf Aufbaudaten in der Straßendatenbank zugreifen sollte. Aufbaudaten konnten somit schnell, effizient und zeitnah gepflegt werden.

Parallel dazu wurde in einigen Bundesländern jedoch ein anderer Ansatz verfolgt. Es wurde ein sehr einfaches Meldesystem entwickelt, mit dem – unabhängig von der Straßeninformationsbank – Maßnahmen und die damit verbundenen Änderungen am Aufbau in standardisierter Form erfasst wurden. Turnusmäßig wurden die Daten dann von einem Ingenieurbüro geprüft, aufbereitet und in die Straßendatenbank übernommen.

Der Vorteil bei dieser Vorgehensweise war, dass das Meldesystem sehr einfach zu bedienen war und bei den Anwendern eine hohe Akzeptanz aufwies. Die Meldung der Maßnahmen und der Änderungen am Aufbau wurden praktisch nebenbei erledigt. Zudem wurde durch Einbindung das Ingenieurbüros in die Datenaufbereitung eine Qualitätssicherungsinstanz geschaffen, welche alle Daten nochmals geprüft hat. Nachteilig war jedoch, dass die Daten zwar zeitnah erfasst, aber meist erst sehr viel später in der Straßenbank verfügbar waren, dass Netzänderungen manuell nachgepflegt werden mussten und dass zudem ein laufender Aufwand durch Beauftragung des Ingenieurbüros entstand.

Ein optimales Verfahren für die Aufbaudatenedition wird in einer Kombination der beiden o.g. Vorgehensweisen gesehen, d.h. einem Werkzeug, dass direkt auf die Datenbank aufsetzt, einem sehr einfacher Editor, mit dem lediglich Maßnahmen und die damit verbundenen Änderungen am Aufbau gemeldet werden, sowie einer Instanz, bei der die gemeldeten Aufbaudaten geprüft werden, bevor sie zeitnah in die Straßendatenbank übernommen werden.

Hessen Mobil hat seit knapp zwei Jahren den Aufbaudateneditor der HELLER Ingenieurgesellschaft mbH für die OKSTRA^®-Datenbank SIB-Hessen im operativen Einsatz. Dennoch werden die durchgeführten Erhaltungsmaßnahmen von den regionalen Standorten (Bauämtern) mit dem o.g. von der Straßenbankbank unabhängigen Meldesystem dokumentiert. Der Grund hier ist, dass das Meldesystem in den regionalen Standorten seit langem etabliert ist und eine hohe Akzeptanz genießt. Das Meldesystem weist jedoch zum einen keinen aktuellen Netzbezug auf und zum anderen wird noch ein alter Aufbauschichtenschlüssel verwendet. Zudem müssen die Meldungen, die in einemspeziellen Datenformat bzw. auch in Papierform vorliegen, in der Zentrale von Hessen Mobil durch einen Mitarbeiter mittels Aufbaudateneditor manuell eingepflegt werden, damit sie letztendlich in der Straßeninformationsbank verfügbar sind.

Das Verfahren zur Maßnahmenmeldung sowie das daran anschließende manuelle Einpflegen der Aufbaudaten über den Aufbaudateneditor in die SIB-Hessen soll nun durch ein neues Fachverfahren unterstützt werden. Mit eine Web-Anwendung können von den Fachanwendern der regionalen Standorte Maßnahmen sowie die daraus resultierenden Änderungen am Aufbau in gewohnter Weise eingegeben und dann per Knopfdruck an die Zentrale gemeldet werden. Dort laufen alle gemeldeten Maßnahmen im Aufbaudateneditor auf, können geprüft und entweder in die SIB-Hessen übernommen oder zurück an den Fachanwender zur Korrektur bzw. Klärung von Fragen gesendet werden.

Die folgende Abbildung zeigt den Ablauf schematisch.
Bild in der PDF.

Es hat sich in vielen Fällen gezeigt und immer wieder bewahrheitet, dass die Qualität von Daten mit der Akzeptanz des Fachverfahrens einhergeht, in dessen Rahmen die Daten erfasst und gepflegt werden. Akzeptanz wiederum kann nur erreicht werden, wenn die Werkzeuge die vorhandenen Fachprozesse abbilden, die Bedienung einfach ist und der Anwender darauf vertrauen kann, dass die zugrundeliegenden Datenmodelle zuverlässig bedient werden. Die Praxis hat gezeigt, dass dies mit dem vergleichsweise komplexen OKSTRA^® genauso möglich ist, wie mit älteren ASB-Implementierungen oder gar proprietäreren Standards.