FGSV-Nr. FGSV 002/138
Ort Köln
Datum 28.02.2024
Titel Einfluss des OKSTRA®-Schemas auf die Fachanwendung „LASTRADA“ aus der Sicht des Softwareanbieters
Autoren Johannes Pacholski
Kategorien OKSTRA
Einleitung

In diesem Beitrag untersuchen wir den Einfluss der Einführung des OKSTRA®-Schemas auf die Fachanwendung „LASTRADA“ aus unserer Perspektive des Softwareanbieters und als Entwickler des Produkts. „LASTRADA“, 1995 ursprünglich für die Erstellung und Verwaltung von Asphaltkontrollprüfungs-Berichten entwickelt, bedient mittlerweile verschiedenste Bereiche der Qualitätssicherung von Baustoffen im Bauwesen und bietet durch eine modulare Struktur besonders hohe Flexibilität bei der Bereitstellung von Funktionalitäten. Die Anwendung konnte sich bis heute international in über 15 Ländern etablieren.

Wir betrachten hier die Relevanz der Einführung des OKSTRA®-Schemas in den spezifischen Domänen der Erstellung von Asphalt-Eignungsnachweisen mit Erstprüfungen und der Erfassung von Prüfdaten und Erstellung von Prüfberichten im Rahmen von Asphaltkontrollprüfungen sowie die davon betroffenen Softwaremodule und ihre Anwender.

Vor Beginn der Umsetzungsphase wurde die Entscheidung zur Nutzung der „OKLABI“, der OKSTRA®-Klassenbibliothek, getroffen und diese an die Anwendung angebunden. Im Anschluss an die Analyse und den Vergleich der bisherigen sowie zukünftigen Datenstrukturen,

-formate und Arbeitsabläufe, konnte für die Softwareentwicklung die Roadmap mit ihren Milestones erstellt werden. Wir möchten hier aus dieser Roadmap die Lösungsansätze aus unserer Sicht des Softwareherstellers vorstellen und damit den Einfluss des OKSTRA®-Schemas auf unsere Fachanwendung verdeutlichen. Die Darstellung beinhaltet die Integration eines neu zu entwickelnden Softwaremoduls zur Erstellung und Verwaltung von Asphalt-Eignungsnachweisen und damit verbunden Erstprüfungen, den Import und Export von Eignungsnachweisen und Kontrollprüfungen unter Anwendung von OKSTRA®-Profilen, sowie den Einfluss dieser Profile auf die Erfassung und Verarbeitung von Prüfdaten im Rahmen von Kontrollprüfungen. Abschließend geben wir einen kurzen Einblick in den Strukturwandel der Softwareentwicklung und einen kurzen Ausblick auf die Weiterentwicklungen, die im Zusammenhang mit dem OKSTRA®-Schema stehen.

PDF
Volltext

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

1 Vorstellung der Fachanwendung „LASTRADA“

LASTRADA wurde im Sommer 1995 als Anwendung zur Verwaltung von Prüfberichten für die Asphalt-Kontrollprüfung ins Leben gerufen. Der Mathematiker Dr. Jung, Firmengründer und Vorstand a. D. bekam von der „stra/lab Baustoff- und Straßenprüfung GmbH“ damals den Auftrag zur Programmierung.

28 Jahre später ist LASTRADA in über 15 Ländern bei mehr als 220 Unternehmen vertreten und bedient Baustoffproduzenten, Bauunternehmen, Prüfinstitute, Beratungsunternehmen, Forschungs- und Bildungseinrichtungen sowie die öffentliche Hand. Mit heutigem Stand werden allgemein folgende Tätigkeitsfelder durch den modularen Aufbau der Anwendung abgedeckt:

  • Design und Rezeptierung von Baustoffen gemäß Anforderung,
  • Werkseigene Produktionskontrolle der Baustoffproduktion,
  • Baustellenüberwachung in den Bereichen Asphalt, Beton, Baugrund und Geotechnik,
  • Erkundung und Überwachung von mineralischen Gewinnungsstätten,
  • Boden-, Schichten- und Baugrunderkundungen und Prüfungen,
  • Fremdüberwachung durch unabhängige Prüfinstitute,
  • Laborablaufsteuerung und Qualitätssicherung.

Die spezifische Nutzung in den unterschiedlichen Fachbereichen wird realisiert durch angepasste Dialoge und Strukturen in der Programmoberfläche sowie der Tabellenstruktur und Datenhaltung. Das bedeutet insbesondere. Der Anwender ist in der Lage, alle relevanten Daten zu erfassen und als Stammdaten vorzuhalten, die für die Auswertung von Baustoffrezepturen, Baustoffprüfungen und Bestandsuntersuchungen gemäß Anforderung erforderlich sind. Hierbei ist als Besonderheit hervorzuheben, dass diese Stammdaten durch den Anwender selbst verwaltet werden und damit nicht in Abhängigkeit eines Kataloges stehen, der durch uns als Softwareanbieter zu pflegen wäre. Eine Anpassung bei Veränderungen der Regelwerke oder Betreten eines neuen Marktes mit abweichenden Regelwerken ist dadurch in 90 % aller Fälle problemlos möglich.

Die Anwendungs-Architektur besteht aus einer Microsoft-Applikation, geschrieben in C++, die durch Programmbibliotheken ergänzt wird und ihre Daten in einer SQL-Datenbank hält. Zusätzliche Serverdienste erweitern die Applikation um Schnittstellen, die in den verschiedensten Ausprägungen vorhanden sind, vom geräte- bzw. anwendungsspezifischen Datenaustausch per proprietärer Schnittstelle über standardisierte Import- und Exportschemen bis hin zu API. Die Erweiterung um eine IIS-basierte WebAPI realisiert beispielsweise die Anbindung einer ergänzenden responsiven App, die für die zwei gebräuchlichsten Mobilbetriebssysteme zur Verfügung steht. Diese ermöglicht unseren Anwendern die Datenerfassung im Feldeinsatz und ist auch ohne Verbindung zur API lauffähig.

2 Vom OKSTRA®-Schema erfasste relevante Anwendungsgebiete

Mit mehrfacher Ankündigung in Rundschreiben (beispielsweise Krause, 2020) und Fachpublikationen (beispielsweise Kübler, 2023) wurde vom Referat Straßenbautechnik und Straßenerhaltung des Bundesministeriums für Digitales und Verkehr der Einsatz des OKSTRA®-Schemas für die Erzeugung und Weiterverarbeitung von Ergebnissen aus Kontrollprüfungen und Eignungsnachweisen angekündigt. Der Auftraggeber erwartet daher zukünftig von seinen Auftragnehmern die Einreichung der entsprechenden Nachweise und Prüfergebnisse im bundesweit standardisierten Datenformat. Die Rahmenbedingungen zu Datenschema, Profilen, Dateiformaten und Übertragungswegen sind dabei bereits festgelegt. Die folgenden Anwendungsgebiete fallen somit in den Geltungsbereich des OKSTRA®-Schemas:

  1. Ersteller von Erstprüfungen und Eignungsnachweisen für Auftragnehmer des Bundes von Straßenbaumaßnahmen in Asphaltbauweise – kurzum Asphaltmischgut-Lieferanten und Einbauunternehmen bzw. deren Dienstleister in Bezug auf eben jene Nachweise.

    Hier ist darauf hinzuweisen, dass Erstprüfungen als notwendiger Bestandteil von Eignungsnachweisen keine eigenständiger FeatureType im OKSTRA®-Schema sind. Der Eignungsnachweis enthält alle notwendigenAttribute, um eine Erstprüfung abzubilden. Es existiert aber ein separater DataType für Erstprüfungen, der im Eignungsnachweis referenziert werden kann. Dieser kommt zur Verwendung, sobald der Eignungsnachweis mehr als eine Erstprüfung enthält. Erläuterungen dazu finden Sie im nächsten Abschnitt.
  1. Nach RAP Stra von der Bundesanstalt für Straßenwesen anerkannte Prüfstellen, die vom Auftraggeber mit der Durchführung der Kontrollprüfung beauftragt Dabei findet in Vorbereitung auf die Erfassung der Prüfergebnisse die Dokumentation der Probenahme inklusive Geolokation in einer browserbasierten IT-Lösung zur Erfassung, Auswertung, Georeferenzierung und kartenbasierten Visualisierung von Baustoffprüfergebnissen im Straßenbau statt (EQUBAR: Erfassung, Qualitätsbeurteilung, Bewertung, Archivierung von Prüfdaten im Straßenbau).

    Beide Anwendungsgebiete, Asphalt-Eignungsnachweise mit Erstprüfungen und Asphalt-Kontrollprüfungen, befinden sich Form von spezialisierten Software-Modulen bereits seit mehreren Jahrzehnten in unserer Fachanwendung im Einsatz. Sie wurden in Zusammenarbeit mit den Anwendern und nach den Anforderungen der Regelwerke entwickelt, um den Arbeitsabläufen optimal zu entsprechen, diese zu unterstützen bei der Art und Weise der Eingabe und Auswertung, sowie konforme Ausgaben in Form von Erst- und Kontrollprüfungsberichten, CE-Kennungen, Leistungserklärungen, Eignungsnachweisen etc. sicherstellen zu können. Die entsprechenden Module sind Bestandteil der regelmäßigen Revision und werden fortlaufend weiterentwickelt.

3 Arbeitsabläufe der Fachanwender im Vergleich „vorher-nachher“ und OKSTRA®-bedingte semantische Änderungen

Um die Auswirkungen der Einführung des OKSTRA®-Schemas besser beurteilen zu können, ist ein kurzer Rück- und Ausblick notwendig, wie die Fachanwender die Daten bisher gehandhabt haben und zukünftig handhaben werden.

Im Rahmen einer Ausschreibung erfolgte die Abgabe durch den Auftragnehmer bisher in nicht maschinenlesbarer Form gedruckt oder als digitales Dokument. Dabei wird Bezug zu einer Asphalt-Erstprüfung genommen, die als Erstprüfungsbericht gemäß TL Asphalt-StB 07/13 dem Eignungsnachweis anzufügen ist. Die Eignung wird gegenüber allen gleichlautenden Anforderungen einer Ausschreibung mit einem einzigen Dokument oder mit einem Dokument je Leistungsposition erklärt. Sofern er nicht selbst Asphaltmischguthersteller ist, erhält der Bauunternehmer die Erstprüfungsberichte, CE-Kennzeichnungen und Leistungserklärungen von seinen Asphaltmischgutlieferanten beziehungsweise deren betreuenden Prüfstellen. In den meisten Fällen ist das Dokument zum Eignungsnachweis als Formblatt bereits mit angefügt und vom Auftragnehmer, um eigene Angaben zu ergänzen und zu unterschreiben. Im Falle von Liefergemeinschaften, also der Beteiligung von mehr als einem Asphaltmischwerk an einer Leistung, werden die Eignungsnachweise um weitere Erstprüfungsberichte oder Leistungserklärungen – früher Konformitätserklärungen – der Lieferanten ergänzt.

Die Variabilität für die Konstellation Eignungsnachweis::Erstprüfung::Leistungserklärungen lautete also unter Umständen 1:1:n. Eine Beurteilung der zu erwartenden Einbauqualität sowie die Planung von Instandhaltungsmaßnahmen sind bei der Abgabe von Konformitätserklärungen anstatt Erstprüfungen damit nur auf Grundlage der Daten einer einzigen Erstprüfung möglich. Entsprechende Vorgaben zu je nach Einbauschicht und Mischgutart möglichen Toleranzen zwischen den verwendeten Asphalt-Mischgütern mehrerer Lieferanten finden sich zwar im Regelwerk (ZTV Asphalt-StB 07/13), in welchem Umfang der erlaubten Toleranzen aber vom leitenden Eignungsnachweis des Auftragnehmers Abweichungen aufgetreten sind, ist bei dieser Art der Leistungserklärung nicht mehr überprüfbar.

Daher ist es nur nachvollziehbar, dass der Auftraggeber hier eine Veränderung der Datenlage mit der Einführung des OKSTRA®-Schemas durch eine Veränderung der Kardinalitäten herbeiführt, die bundeseinheitlich Gültigkeit findet. Die neue Variabilität für die Konstellation Eignungsnachweis::Erstprüfung lautet nun 1:n. Es ist also die Abgabe aller Erstprüfungen mit einem Eignungsnachweis erforderlich und die Abgabe von Konformitätserklärungen hinfällig. Diese Anforderung der Abgabe aller Erstprüfungen wurde von einzelnen Bundesländern, wie zum Beispiel in Bayern durch die Oberste Baubehörde (Bayern, 2017), bereits eingeführt. Für die Anwender in diesen Bundesländern dürfte sich die Umstellung daher, weil in fachlicher Hinsicht bereits vom Ablauf her gefordert und gewohnt, etwas einfacher gestalten.

Bild 1: Beispielprozess bisheriger Erzeugung von Eignungsnachweisen

Der ursprüngliche Ablauf in der Fachanwendung, in einem Modul die Erstprüfung zu erstellen, um Angaben zur Baumaßnahme zu ergänzen und anschließend ein Dokument zu erzeugen, wird damit den zukünftigen Anforderungen nicht mehr gerecht (Bild 1). Ein vormals nur teilweise digitalisierter Prozessschritt, der manuell vom Nutzer organisiert wurde, muss nun in der Anwendung realisiert werden. Der Anwender wird in die Lage versetzt werden, zu einem Eignungsnachweis eine oder mehrere Erstprüfungen zu erfassen oder auch zu importieren und den Eignungsnachweis im vom Auftraggeber vorgegebenen Format und dem Anforderungsprofil entsprechend auszugeben bzw. zur weiteren Verarbeitung durch beteiligte Akteure zu exportieren und bereitzustellen (Bild 2).

Bild 2: Beispielprozess zukünftiger Erzeugung von „OKSTRA®-Eignungsnachweisen“

Die Abgabe der Ergebnisse von Kontrollprüfungen (Bild 3) erfolgte bisher in ähnlicher Weise, teils mit erheblichen Unterschieden in den Anforderungen an die strukturelle Gliederung und den Inhalt zwischen den Auftraggebern, bis hin zu umfangreichen textuellen Auswertungen und Vorgaben zu Schriftart und -größe.

Kontrollprüfungen wurden in einem spezialisierten Modul nach folgendem Ablauf erfasst:

Nach der Anlage der Auftragsdaten und der Erfassung des Asphalt-Eignungsnachweises (in der Anwendung genannt „Deklaration“, da es sich um die vom Auftragnehmer deklarierten Leistungsdaten handelt), erfolgte die Verortung der „Stationen“ (die Orte der Probenahmen) sowie die Zuordnung der entnommenen Proben. Im Anschluss an die Durchführung der geforderten Prüfungen sowie der Dokumentation und Auswertung der Prüfergebnisse, wurden diese an den Auftraggeber übermittelt – teils gedruckt oder als Digitalisat, teils aber auch schon im digitalen Datenaustausch (z. B. LA Hannover oder hessenmobil), allerdings proprietär.

Bild 3: Beispielprozess bisheriger Asphaltkontrollprüfungen

Wie bereits erwähnt, erfolgt die Bereitstellung der Auftragsdaten, zugehörigen Eignungsnachweise sowie die Dokumentation der Probenahme zukünftig in EQUBAR. Der vom System zur Verfügung gestellte Datensatz „Prüfauftrag“ enthält neben den vom Anwender erfassten Probedaten auch den Eignungsnachweis sowie Auftragsdaten. Hier benötigt der Anwender zukünftig eine zuverlässige Importfunktion, die den Datensatz zur weiteren Bearbeitung und Dateneingabe in der Anwendung verfügbar macht. (Bild 4)

Bild 4: Beispielprozess für „OKSTRA®-Asphaltkontrollprüfungen“

4 Lösungsansätze aus Sicht der Programmierer und Umsetzung in der Anwendungsoberfläche

Die Verfügbarkeit der OKSTRA® Klassenbibliothek (OKLABI) war seit Beginn der Auseinandersetzung mit der Thematik zentraler Bestandteil der Umsetzungsplanung. Eine Klassenbibliothek anzubinden, die kostenfrei von der Bundesanstalt für Straßenwesen zur Verfügung gestellt wird, war jeder selbst entwickelten proprietären Lösung eindeutig vorzuziehen. Ein zusätzliches Argument aus der Entwicklung im Hinblick auf die bereits vorhandenen Erfahrungen in beiden Szenarien – der Anbindung externer Bibliotheken und dem Einsatz von intermediären Austauschdatenbanken – betraf die über Aktualisierungen der Anwendung hinweg bestehende Stabilität der Im- und Exportergebnisse beim Einsatz von Programmbibliotheken, so dass die Entscheidung für den Einsatz der OKLABI bereits im frühestmöglichen Stadium der Entwicklung getroffen werden konnte.

Wie bereits im zweiten Abschnitt erwähnt, ist eine von der Einführung des OKSTRA®-Schemas betroffene Nutzergruppe die der Ersteller von Erstprüfungen und Eignungsnachweisen für den Straßen- und Verkehrswegebau in Asphaltbauweise. Unsere Fachanwendung hält für die Erstellung und Verarbeitung der in diesem Zusammenhang anfallenden Daten ein dediziertes Softwaremodul vor. Dieses Modul koexistiert mit einem weiteren, welches auf die Anforderungen der verschiedenen Designmethoden des nordamerikanischen Marktes zugeschnitten ist. Beide Module sind in unterschiedlicher Gewichtung in mehr als zwölf Ländern in ihrer jeweils nationalen Ausprägung im Einsatz.

Unter der Maßgabe der Gültigkeit des OKSTRA®-Schemas für den Einzugsbereich des Bundesministeriums für Digitales und Verkehr und damit nur für den deutschen Markt und angrenzende Lieferanten, wurde eine Erweiterung des bestehenden Moduls verworfen. Von einer funktionalen Erweiterung im Bestand wären über die Landesgrenzen hinweg auch andere internationale Anwender betroffen gewesen. Bei einer weiteren Betrachtung der Anforderungen erwies sich diese Entscheidung als folgerichtig, da die Zusammenführung von mehreren Erstprüfungen in einem Eignungsnachweis der grundsätzlich angedachten Funktionsweise des Moduls widerspricht. Es geht hierin vorrangig um die Erstellung und Überprüfung von Rezepturen nach Anforderungen jeweiliger Regelwerke für die Herstellung von Asphaltmischgütern, kurzum Erstprüfungen. Das Softwaremodul behandelt dabei eine einzelne Erstprüfung als ein logisches Objekt und ist in seinem Aufbau und seiner Struktur auch nur auf die Verarbeitung genau dieses einen Objektes ausgelegt. Von dieser Ebene aus erreicht der Nutzer alle für die Verarbeitung notwendigen referenzierten Daten und ihre Varianten und erfasst weitere Daten und Prüfdaten, die einzigartig für die jeweilige Erstprüfung sind. Diese Arbeitsweise ist über den deutschen Nutzerkreis hinaus etabliert und sollte daher erhalten werden.

Um im Folgenden die Verarbeitung von einer oder mehreren Erstprüfungen im Zusammenhang mit der Erstellung eines Eignungsnachweises zu ermöglichen, also die Variabilität n:1 zu erfüllen, die im OKSTRA®-Schema vorgesehen ist, wurde das neue Objekt „AS-ENW“ (Asphalt-Eignungsnachweise) entwickelt. Dieses Objekt mit seinen dazugehörigen Tabellen, Relationen und einem expliziten Dialog für die Anwendungsoberfläche ermöglicht die fast unveränderte Beibehaltung des Moduls für Erstprüfungen, national wie international. In diesem neuen „AS-ENW-Modul“ werden bereits bekannte und erfasste Daten aus anderen Modulen zusammengeführt, um OKSTRA®-Eignungsnachweise nach n:1 zu erzeugen. Dabei übernimmt die OKLABI die Importfunktion für externe Asphalt-Erstprüfungen sowie die Validierung gegen OKSTRA®-Profile und die Exportfunktionen.

Im Ergebnis kann der Anwender das gewohnte System zur Erfassung und Verarbeitung von Daten der Asphalt-Erstprüfungen weiterverwenden. Erst im Kontext der Erstellung von Eignungsnachweisen im OKSTRA®-Format sowie in diesem Zusammenhang des Im- und Exports von Erstprüfungen und Eignungsnachweisen im OKSTRA®-Format muss das neue Modul verwendet werden und trägt damit auch zu einer Differenzierung der verschiedenen Anforderungen bei.

Bei der Erzeugung von begleitenden PDF/A-Dokumenten kann der Anwender auf die bereits vorhandenen Funktionen der Fachanwendung zurückgreifen, die heute einen Entwicklungsstand erreicht haben, der die Anforderungen weitestgehend erfüllt. Hier war ergänzend die Erweiterung um den Archivstandard des Portable Document Formats erforderlich. Zudem ist vom Auftraggeber eine Vereinheitlichung der Dokumentenvorlage geplant, so dass bundesweit ein einheitlich strukturiertes Dokument für die Abgabe von Eignungsnachweisen Anwendung finden kann, was die Handhabung sowohl für den Nutzer der Anwendung wie auch den Auftraggeber weiter vereinfacht.

Für die Anwender der RAP Stra Prüfstellen bedeuten die durch OKSTRA® bedingten Veränderungen voraussichtlich eine Erleichterung in der Handhabung der Daten, zumindest in unserer Fachanwendung. Da die Dokumentation der Probenahme in einem externen System erfolgt und der zum Import zur Verfügung gestellte Datensatz des Prüfauftrags auch die entsprechend zugeordneten Auftragsdaten und OKSTRA®-Eignungsnachweise enthält, entfällt an dieser Stelle für den Anwender das Zusammentragen von Dokumenten, Digitalisaten und weiteren Daten sowie die Eingabe dieser in den Softwaremodulen, die im Zusammenhang mit der Kontrollprüfung stehen. Importieren, prüfen, exportieren – im Idealfall. Der um Prüfdaten vervollständigte Datensatz wieder im EQUBAR dem Auftraggeber zur Verfügung gestellt. Auch hier übernimmt die OKLABI die Import- und Exportfunktion der Daten.

Derzeit noch in Diskussion befindlich ist eine Erweiterung der Anwendungsoberfläche, die dem Nutzer während der Eingabe von Prüfdaten ein visuelles Feedback zur Validität der Daten gibt. Die Voraussetzungen rein nach Datenlage wären dafür jedenfalls durch den vorhandenen Bezug zum Eignungsnachweis sowie das maßgebliche OKSTRA®-Profil bereits gegeben. Ungeachtet dieser Möglichkeit ist die Auswertung der Prüfergebnisse schon vor der Einführung des OKSTRA®-Schemas fester Bestandteil der Kontrollprüfung gewesen.

Eine offensichtliche Anpassung musste dennoch vorgenommen werden: Zur Probenahmestelle nach TP Asphalt-StB, Teil 27 gehören Bohrkerne die im Abstand von 5 bis 10 cm entnommen werden. Die Lokalisierung über eine Geokoordinate war bisher nicht Bestandteil und wurde in der Anwendung nachgepflegt.

5 Vor- und Nachteile einer monolithischen Anwendung im Wandel der Zeit

Für Softwareentwickler sind neue Anforderungen keine Überraschungen. Insbesondere als Hersteller einer Fachanwendung, die seit 1995 am Markt ist und mehrere Iterationen in Architektur und Struktur durchlaufen hat, werden wir regelmäßig mit Implementationsprojekten zum Datenaustausch betraut. Unsere Anwender vertrauen auf die Expertise, besonders wertvolle Daten der Qualitätssicherung mit anderen kritischen Systemen wie Prüfgeräten, Anlagen-Steuerungen, ERP und BI austauschen zu können, egal wie standardisiert oder proprietär die Schnittstelle gestaltet werden muss, um die Funktionalität zu gewährleisten.

Das Novum bestand hier vor allem in der Änderung der Variabilität, rechtzeitig erkennbar durch die herausragende Dokumentation des OKSTRA®-Schemas, des zugehörigen OKSTRA®-Profils und der durchgehenden Angabe der Kardinalitäten. Unsere Aufgabe als Softwareentwickler war es, dem Anwender eine Lösung anzubieten, die die fehlerfreie Entgegennahme und Weitergabe von Daten im OKSTRA®-Schema ermöglicht, auch wenn das die Einführung eines neuen Softwaremoduls und Anpassungen an bestehenden Modulen bedeutete. Die erreichte Art und Weise der Implementation sichert die Funktionalität und Bedienbarkeit in gewohnter Weise für internationale Anwender und minimiert gleichzeitig den erforderlichen Aufwand bei der Umstellung auf neue Prozessabläufe für Anwender im Einflussbereich des OKSTRA®-Schemas.

Schlussbemerkung

Seit einigen Jahren beschäftigen wir uns intern mit dem Wechsel der Architektur weg von einer monolithischen Anwendung hin zu einer Backend-Frontend-Architektur. Vor diesem Hintergrund gab also auch Stimmen aus dem Entwicklerkreis, die sich im Zuge des Datenaustauschs gerne mit einer API auseinandergesetzt hätten. Die Voraussetzungen dafür müssen jedoch auf den mit dem Austausch von OKSTRA®-Daten betrauten Systemen gegeben sein.

Bleibt also, die Weiterentwicklung aller beteiligten Systeme zu beobachten und auf Aktualisierungen im Sinne der Anwender zu reagieren. Wir rechnen mit der baldigen Ausweitung des OKSTRA®-Schemas auf Verkehrsflächenbefestigungen in Betonbauweise. Dann dürfen Sie an dieser Stelle von uns einen ähnlichen Beitrag erwarten.

Literaturverzeichnis

  1. Bayern (2018): Zusätzliche Technische Vertragsbedingungen und Richtlinien für den Bau von Verkehrsflächen aus Asphalt, Ausgabe 2007, Fassung 2013, ZTV Asphalt-StB 07/13, Bekanntmachung der Obersten Baubehörde im Bayerischen Staatsministerium des Innern, für Bau und Verkehr vom 18. August 2017, Az IID9-43415-004/08
  2. Forschungsgesellschaft für Straßen- und Verkehrswesen (2007): Zusätzliche Technische Vertragsbedingungen und Richtlinien für den Bau von Verkehrsflächenbefestigungen aus Asphalt, Ausgabe 2007/ Fassung 2013 (ZTV Asphalt-StB 07/13), Köln (FGSV 799)
  3. Dr. Krause, S. (2020): Info-Brief zur Digitalisierung von Prüfdaten im Straßenbau, BMVI 16. 1. 2020, AZ StB 27/7182.7/3-1/3247174
  4. Kübler, S. (2023): Auf dem Weg zu digitalen Prozessen und Prüfdaten im Straßenbau. Straße und Autobahn 4/2023, Kirschbaum Verlag, Bonn, 284-290