Diskussion:Los1: Pflegekonzept IVS-RA

Einführung 

Spezifikationen und Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand des IVS-Rahmenarchitektur und der drei daran gekoppelten IVS-Referenzarchitekturen nur eine Momentaufnahme einem noch zu schaffenden Pflegeprozesses, des IVS-Architektur Prozesses.

Das Prozessmodell stellt als ein Kreislauf dar, der sich grundsätzlich in vier Phasen unterteilen lässt. Ein Feedback der Nutzer als Rückkopplung zu den aktuellen Versionen der Standardisierungsentwicklung ist von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirkt häufig als Initialzündung für die weitere Pflege des Standards. Die in der Folge von IT-Spezialisten entwickelten Lösungen (Pflege des Standards) werden in einer neuen (Unter-)Version dem Markt zur Realisierung zur Verfügung gestellt. Durch die Dokumentation des Pflegeprozesses (Ereignisverfolgung / ®Issue-Tracking) sowie die Veröffentlichung von Ergebnissen von Forschungsprojekten und des Standardisierungsprozesses werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Die Zertifizierung der Standardisierungsergebnisse gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz des Standards bei den Nutzern gefördert und damit die Voraussetzung für dessen Durchsetzung am Markt geschaffen werden. Ohne ein gewisses Maß an Marktakzeptanz kann der Standardisierungsprozess nicht überleben. Durch die Implementierung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden ggf. Mängel des Standards erkennbar, was wiederum durch ein entsprechendes Feedback in den Prozess eingebracht wird und damit die Weiterentwicklung der Standardisierung vorantreibt.

Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:

• Wie passt sich der Standard an neue Anforderungen an?
• Wie reagiert der Standard auf die Entdeckung von Fehlern?

Zudem muss in diesem Zusammenhang auch geklärt werden, wer sich an den Kosten dieses Standardisierungsprozesses beteiligt bzw. Ressourcen für die Pflege des Standards bereitstellt, einhergehend mit der Frage nach den eigentlichen Nutznießern. Einerseits sind es die Städte und Kommunen, Bund und Länder oder gar die EU, die als Anwender in einem komplexen Zusammenspiel von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit technischem Vorsprung am Markt behaupten zu können.

Im Vergleich mit der Pflege von DATEX II (internationaler Prozess), der mit einem Aufwand von etwa 100 Mann-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, kann man beim IVS-Architektur Prozess(nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

Generell muss gelten, dass die Anforderungen an den IVS-Architektur Prozesses von der technischen Ausprägung der Spezifikation weitgehend unabhängig sind. Um den Prozess erfolgreich zu gestalten, muss es beispielsweise eine Konvergenz mit OCIT-C geben.

Die Pflege der OTS-Instrumente (OTS-Systemmodell, OCA-Vorgehensmodell, OTS-Leitfaden) wird von der OCA im Rahmen der AK-Arbeit übernommen. Hierbei erfolgt eine Fokussierung auf den Pflege- und Unterstützungsprozess der Spezifikation.

Aufgaben des IVS-Architektur Prozesses]]

Die grundsätzlichen Aufgaben des OTS-Prozesses unterteilen sich in die Bereiche „Pflege des Standards“, „Entwickler-/ Anwenderunterstützung“, „Öffentlichkeitsarbeit“ sowie der „Selbstverwaltung des Prozesses“. Die Arbeiten zur Pflege des Standards erfordern IT-Kompetenz und können u. U. nur von Experten (Hersteller, (außer)universitäre Einrichtungen, beratende Unternehmen) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

·         OTS 2 Schnittstellenstandard (Fehlerbehebung und Erweiterung)

·         OTS-Testrahmenwerk (Konformitäts- und Interoperabilitätstests)

·         OTS 2 Referenzimplementierung

Für die Pflege eines Standards sollten transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung des Standards auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades (vgl. (15)) bzw. nach einer definierten Prioritätenliste von Experten (IT-Spezialisten) zeitnah behandelt werden. Die Ergebnisse des Pflegeprozesses werden i.d.R. veröffentlicht, in die Spezifikationen (Protokoll, Dienste, Datenmodell) eingearbeitet und in die entsprechenden Standardisierungsgremien eingebracht.

Für OTS 2 wurde in Zusammenarbeit mit dem Deutschen Institut für Normung e.V. (DIN) der Standard „DIN SPEC 91213“ nach dem PAS Verfahren erstellt. Der Teil 1 (4) erläutert Entscheidungsträgern den Anwendungsbereich und potentiellen Nutzen bzw. Mehrwert der OTS 2 Schnittstellenspezifikation. Der Teil 2 (5) spezifiziert die OTS 2 Schnittstelle zwischen zwei Kommunikationspartnern, die über ein Netzwerkprotokoll miteinander kommunizieren, und deren Implementierung über den OTS 2 Protokollstapel.

Im Falle der DIN SPEC ist es möglich, alle drei Jahre ab dem Zeitpunkt der ersten Veröffentlichung des Standards im Rahmen vom DIN begleiteten Standardisierungsworkshops eine Überarbeitung vorzunehmen und die entstandene neue Version zu veröffentlichen.

Herstellerunabhängige standardisierte Konformitätstests geben Auftraggebern Investitionssicherheit und Herstellern Resonanz zu ihrer Implementierung. Die Konformität, als Maß für die Güte einer herstellerspezifischen Implementierung, wird durch die Betrachtung abgegrenzter Ebenen z.B. Unit-Ebene, Integrations-Ebene, System-Ebene, etc. und Funktionalitäten bewertet. Die Konformität bestätigt nicht zwangsläufig auch die Interoperabilität eines Systems. Während für Konformitätstests die isolierte Betrachtung des zu testenden Systems zugrunde liegt, zeigen weitergehende Interoperabilitätstests die Verbundfähigkeit an.

Für den OTS-Prozess stellt das OTS-Testrahmenwerk das notwendige Werkzeug dar, Interoperabilitäts- und Konformitätstests durchführen zu können. Es liefert die Referenzpunkte, an denen sich der Grad der Interoperabilität und Konformität messen lassen. Ziel ist es, dass Konformität mit Interoperabilität einhergeht.

Die Herausforderung liegt hier in der Verankerung eines Prozesses, der Probleme des Standards aufgreift und zu neuen Testfällen führt. Die Objektivität der Testfälle wird gesteigert, indem innerhalb des Prozesses alle Stakeholder z.B. Auftraggeber, Betreiber und Hersteller das Testrahmenwerk pflegen und weiterentwickeln.

Das Testrahmenwerk bildet zudem die sichere Basis für eine zukünftige Zertifizierung. Ein zertifizierter Standard bringt für die Anwender folgende Vorteile:

·         Höhere Gewissheit der Fehlerfreiheit bei geprüften als bei ungeprüften Implementierungen

·         Kein Vorhalten eigener Testsysteme

·         Informationen über die Konformität aus Testergebnissen einsehbar

·         Vergleichbarkeit unterschiedlicher Hersteller hinsichtlich der Qualität der Implementierung

Aber auch die Hersteller profitieren aus folgenden Gründen von einer Zertifizierungsmöglichkeit:

·         Sicherstellung der Konformität der Implementierung bzgl. der Spezifikation

·         Leichtere Identifizierbarkeit von fehlerhaften Implementierungen bei Verfügbarkeit von abgestimmten Konformitätstests (+ Testfällen)

·         Vermeidung von Auseinandersetzungen zwischen Herstellern durch Vorlage objektiver Testergebnisse

·         Zusätzliche Qualitätssicherung bei der Entwicklung durch Konformitätstests

·         Bessere Marktpositionierung durch positiv geprüfte Implementierungen

Eine Referenzimplementierung ist im Allgemeinen eine Implementierung einer Spezifikation, die als endgültige Auslegung dieser Spezifikation verwendet wird (16). Sie soll primär die im jeweiligen Standard beschriebenen Merkmale so präzise wie möglich umsetzen. Die Gebrauchstauglichkeit spielt dabei meist nur eine untergeordnete Rolle. Aufgabe des Pflegeprozesses ist es, die Referenzimplementierung entsprechend der Weiterentwicklung des Standards anzugleichen.

Im Projekt OTS 2 wurde eine Demonstrationsanwendung in der Programmiersprache Python als Referenzimplementierung entwickelt, die die wesentlichen Protokollmechanismen enthält und damit die Realisierbarkeit der OTS 2 Spezifikation veranschaulicht. Anstelle der Demonstrationsanwendung wäre zu einem späteren Zeitpunkt eine voll funktionsfähige Open Source Referenzimplementierung denkbar.

Neben den vorherigen Aspekten, die mit der Pflege des Standards zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

Zum einen sei hier der Entwickler- bzw. Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung der Spezifikation, die Ergebnisse des Testrahmenwerks und weiterführende, unterstützende Dokumentationen. Letztere können sich aus Tutorials, ®Guidelines, ®Webinars, etc. zusammensetzen. Für eine Kollaboration von Entwicklern des Standards, Entwicklern, die den Standard in ihre Produktpalette integrieren und Anwendern, die den Standard in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen Foren, Wiki, etc. eingerichtet und betrieben werden. Beide Werkzeuge/Plattformen benötigen eine aktive Moderation, wenn sie im Rahmen einer problemorientierten Unterstützung als Helpdesk eingerichtet werden sollen. Aufgetretene Probleme können in einem Issue-Tracking-System dokumentiert werden. Es dient dazu, den reibungslosen Ablauf daraus resultierender Aufgaben zu gewährleisten und die Pflege des Standards zu unterstützten.

Im Projekt OTS 2 wurde dazu mit der Internetplattform www.opentrafficsystems.org der Grundstein gelegt. Dort finden sich alle Informationen rund um OTS. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den OTS-Prozess. Über das Portal sind nicht nur viele Informationen (Spezifikationen, Erweiterungen, OTS-Referenzimplementierung, OTS-Instrumente u.v.m.) erhältlich. Über das Contentmanagementsystem Typo3 war es auch möglich, ein Issue-Tracker-Modul zu integrieren. Dieses bietet eine Feedback-Möglichkeit für Nutzer von OTS 2 (Fehlerreports, Anforderungen an OTS, Erweiterungen des OTS-Protokollstapels usw.). Erste Versuche haben dessen Funktionalität bestätigt. Mit der Etablierung des OTS-Prozesses kann dieses Modul operativ eingesetzt werden. Die folgende Abbildung 55 zeigt das OTS-Portal.

[[File:]]

Abbildung 55: OTS-Internetportal

Zu den beschriebenen Aufgaben der Pflege des Standards bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Standardisierungsergebnisse zeitnah einem breiten Nutzerkreis zur Verfügung stellen zu können und andererseits einen geeigneten „Kanal“ für die Rückkopplung bereit zu halten. Nur über eine nachhaltig gewährleistete Kommunikation kann der Prozess wirklich lebendig gehalten werden. Diesbezüglich werden die Unterhaltung des Internetauftritts inkl. Newsletter, die Durchführung von Nutzerforen, Workshops usw. sowie die Repräsentation auf geeigneten (externen) Veranstaltungen (z.B. auf Messen und Kongressen) wichtige Aufgabenfelder darstellen.

Im Projekt OTS 2 wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise in die Entwicklung des OTS 2 Kommunikationsstandards und des Prozesses so früh, wie möglich, einzubeziehen. Zu den insgesamt drei Veranstaltungen (ein OTS-Symposium, zwei OTS-Workshops) wurde jeweils folgendes Fachpublikum eingeladen:

·         Baulastträger und Betreiber der öffentlichen Hand
Eingeladen wurden die Mitglieder der OCA (38 Stadt- und Landesverwaltungen aus Deutschland, Österreich und der Schweiz)

·         Hersteller aus dem Bereich der Verkehrstechnik

·         Verbände und Fachgremien aus dem Bereich der Verkehrstechnik

·         Interessenten aus anderen Forschungsprojekten, wie SIM-TD und DISTEL

·         Weitere Interessenten
Beispiel ist die DB-Netze AG, die sich mit dem Thema Zertifizierung von Systemen in verteilten Systemlandschaften aktiv auseinandersetzt

·         Fachpresse

Auf der Veranstaltung wurden die geleisteten inhaltlichen Arbeiten bzw. Ergebnisse im Projekt vorgestellt und das Feedback des Fachpublikums zurück in das Projekt eingespeist. Über die Veranstaltungen wurde erreicht, das Interesse am Projekt und seinen Ergebnissen zu wecken und das Fachpublikum an der Verfolgung des OTS-Prozesses zu binden. In diesem Bezug konnte festgestellt werden, dass die Besucherzahlen des Internetportals dauerhaft anstiegen.

Letztendlich sollten auch Ressourcen für die Verwaltung des OTS-Prozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des OTS-Prozesses, ggf. Verwaltung von Finanzen usw. umfasst. Für diese Aufgaben könnte ein Sekretariat eingerichtet werden.

Gemessen an den Aufgaben scheint eine Realisierung des OTS-Prozesses recht komplex und aufwendig zu sein. Es ist jedoch zu bedenken, dass je transparenter und offener der Pflegeprozess und breiter der Support (auch mit wenigen Mitteln) aufgestellt werden kann, die Chancen für eine breitere Akzeptanz bei Herstellern und Anwendern des offenen Kommunikationsstandards OTS 2 steigen.

Letztendlich stellt sich nun die Frage, wer diese Aufgaben übernehmen soll und kann. Würde niemand die Pflege des Standards übernehmen, würde er verkümmern.

Im OCIT-Prozess haben bisher Hersteller die Pflege der OCIT-Standards übernommen. Die gesammelten Erfahrungen haben gezeigt, dass die Anwender und die OCA als ihre Interessenvertretung u.U. ihre Interessen, Wünsche und Ziele nicht vertreten sahen oder diese nur schwer durchzusetzen waren, da der Pflegeprozess für die Anwender weder offen noch transparent war. Dies führte in der Vergangenheit häufig zu Dissensen und verhärteten Fronten. Daher ist die Führung des OTS-Prozesses allein durch Hersteller keine Option.

Von einem Engagement allein durch die Anwender bzw. der OCA kann ebenfalls abgesehen werden, da die OCA-Beitragsfinanzierung die Kosten für den OTS-Prozess nicht abdecken würde. Ausgehend vom internationalen DATEX II Pflegeprozess, der mit einem Aufwand von etwa 100 Mann-Wochen pro Jahr (entspricht ca. 300-400 T€) betrieben wird, werden die Kosten für den nationalen OTS-Prozess auf ein Viertel dieser Kosten (75-100 T€) pro Jahr geschätzt. Zudem fehlt der OCA die erforderliche IT-Kompetenz. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IT-Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob der Standard (evtl. durch fehlende Akzeptanz) durch Hersteller umgesetzt wird.

Daher wird empfohlen, dass der OTS-Prozess von Anwendern und Herstellern gemeinsam betrieben wird. Die Finanzierung kann so auf mehreren Schultern verteilt werden z.B. durch Bereitstellung von freiwilligen Herstellerressourcen und eine finanzielle Unterstützung durch Anwender (z.B. über Projekte bzw. Erwerb der Produkte). Die Kosten des Prozesses können durch eine politische Förderung und eine Öffnung des Prozesses durch Beteiligung von sonstigen Interessenten (z. B. universitäre und außeruniversitäre Einrichtungen) zusätzlich vermindert werden. Die Zusammenführung von technischem Know-How der Hersteller und Praxiswissen der Anwender bringt für beide Seiten wesentlichen und in dieser Domäne bisher selten erreichten Nutzen; mündet sie auf der einen Seite in Realisierungssicherheit, auf der anderen Seite in Vertrauen und Kundenakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im OTS-Prozess (Feedback) durch die Anwender maximiert.

1.1.1.3   Organisation des OTS-Prozesses

1.1.1.3.1     Überblick

Um den OTS-Prozess für Hersteller und Anwender offen und transparent zu gestalten, bedarf es einer für alle Beteiligten klaren Organisation mit definierten Regeln. Die Organisation des OTS-Prozesses orientiert sich dabei an bereits bestehende erfolgreiche Organisationen (vgl. (17), (18), (19), (20), (21)).

Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

Abbildung 56: Organisation des OTS-Prozesses

1.1.1.3.2     Stakeholder

Wie zuvor beschrieben, wird empfohlen, dass der OTS-Prozess von Anwendern und Herstellern gemeinsam betrieben wird. Ergänzt werden diese Gruppierungen mit der Beteiligung von sonstigen Interessenten, wie z.B. beratende Unternehmen oder (außer-)universitäre Einrichtungen. Anwender und Hersteller, aber auch Sonstige, können in Interessensvertretungen organisiert sein. Welche Interessensvertretungen mit den jeweiligen Gruppierungen z.B. assoziiert sein können, zeigt die folgende Tabelle:

Gruppierung	Interessensvertretung
Anwender	Open Traffic Systems City Association e.V. (OCA e.V.) (17) Verband deutscher, österreichischer und schweizer öffentlicher Baulastträger, der sich dafür einsetzt, in Bezug auf Anlagen, Systeme und Komponenten der Straßenverkehrstechnik, Verkehrstelematik und des Verkehrsmanagements ·         den Wettbewerb zu fördern, ·         die Wirtschaftlichkeit und Qualitätssicherung bei Beschaffung und im Betrieb zu fördern, ·         Ausschreibungsverfahren zu vereinfachen und zu verkürzen, ·         den direkten Informationsaustausch zwischen den betroffenen Verwaltungsabteilungen auf nationaler und internationaler Ebene zu fördern, ·         die Anforderungsprofile zu bündeln, und so die Position der Baulastträger gegenüber der Industrie zu stärken.
Hersteller	OCIT Developer Group (ODG) (22) Die ODG ist eine Arbeitsgemeinschaft der Signalbaufirmen Siemens AG, AVT Stoye GmbH, Stührenberg GmbH und Swarco Traffic Systems GmbH. Sie wurde mit dem Ziel gegründet, Schnittstellen für Systeme der Straßenverkehrstechnik (insbesondere auf der Feldebene) zu standardisieren.
	Open Communication Traffic Engineering Components (OTEC) (23) Die OTEC ist ein Konsortium zur Standardisierung der Kommunikation zwischen Komponenten der Straßenverkehrstechnik. Die OTEC-Partner sind Hersteller von Software-Komponenten und Applikationen für Straßenverkehrstechnik. Die Partner kooperieren bei der Entwicklung und Pflege von Schnittstellen und anderen Abstimmungen, die für die Offenheit von Verkehrssteuerungs- und Verkehrsmanagementsystemen notwendig sind. Ziel der Kooperation ist, standardisierte offene Schnittstellen, Objekt- und Datenmodelle zu definieren und zu dokumentieren.
	ODG&Partner (22) Um die Firmen PTV AG, Schlothauer & Wauer GmbH und GEVAS software GmbH erweiterte Arbeitsgemeinschaft der Signalbaufirmen zur Standardisierung von zentralen Schnittstellen
Sonstige Interessenten	Verband der Ingenieurbüros für Verkehrstechnik (VIV e.V.) (24) Der VIV verfolgt im Rahmen seiner Verbandstätigkeit folgende Ziele: ·         Sicherung unabhängiger Beratung auf dem Gebiet der Straßenverkehrstechnik ·         Spezifikation der Ingenieurleistungen auf dem Gebiet der Straßenverkehrstechnik ·         Definition von einheitlichen Leistungsbildern und Qualitätsansprüchen in der Straßenverkehrstechnik ·         Erarbeitung von einheitlichen Vertragsmustern, Haftungs- und Gewährleistungsregeln ·         Erarbeitung von gemeinsamen Verfahren zur Lösung von Aufgaben im Verkehrswesen ohne Bevorzugung von Einzelinteressen ·         Mitarbeit in einschlägigen Gremien und Organisationen
	Bundesanstalt für Straßenwesen (BASt) (25) Die BASt ist ein technisch-wissenschaftliches Institut des Bundesministeriums für Verkehr, Bau und Stadtentwicklung (BMVBS). Sie gibt dem Ministerium in technischen und verkehrspolitischen Fragen wissenschaftlich gestützte Entscheidungshilfen und wirkt maßgeblich bei der Ausarbeitung von Vorschriften und Normen mit.

Die in der Tabelle genannten könnten im Wesentlichen die Stakeholder des OTS-Prozesses darstellen. Gemeinsam würden Sie die Interessensgruppe für den OTS-Prozess bilden.

1.1.1.3.3     Organe des OTS-Prozesses und ihre Funktion

Es gibt zwei primär beteiligte Organe im OTS-Prozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:

Das Lenkungskomitee (LK) erstellt und steuert das Arbeitsprogramm. Dabei sind die Festlegung des Arbeitsprogramms und die Zuteilung entsprechender personeller oder finanzieller Ressourcen iterativ und zyklisch (z.B. jährlich) ablaufende (Verhandlungs-)Prozesse. Die Sitzungen des LK finden in regelmäßigen, z.B. halbjährlichen Abständen statt.

Es bemüht sich zudem um eine Zusammenarbeit mit anderen relevanten Interessengruppen und leistet Öffentlichkeitsarbeit, wie z.B. die Organisation von Workshops oder Symposien. Die allgemeinen technischen Aufgaben werden vom LK auf den assoziierten Arbeitsausschuss übertragen.

Das LK besteht aus Anwendern und Herstellern zu gleichen Teilen (z.B. 4/4), ergänzt um sonstige Interessenten. Anwender und Hersteller werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf Herstellerseite mehrere Interessenvertretungen sind die Herstellerstimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Anwendern und Herstellern besitzen die sonstigen Interessenten kein Stimmrecht. Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des OTS-Prozesses an die vertretenen Interessenvertretungen.

Generell kann das LK bei seinen Aufgaben durch ein Sekretariat unterstützt werden. In diesem Fall ist die Finanzierung zu klären. Es sollte aber auch geprüft werden, ob ein Mitglied des LK die Sekretariatsfunktion ehrenamtlich übernehmen kann.

Der Arbeitsausschuss (AAS) erhält sein Mandat vom LK und berichtet im Gegenzug z.B. jährlich über die Fortschritte seiner Arbeiten. Daher sollte der Leiter des AAS an den Sitzungen des LK teilnehmen. Der AAS besteht aus technischen Experten, die von den Interessensvertretungen entsendet werden. Ggf. können zur temporären Unterstützung auch externe technische Experten zur Mitarbeit im AAS berufen werden. Die Finanzierung der Experten ist im Einzelfall zu klären.

Aufgabe des AAS ist es, sich mit dem Management und der Weiterentwicklung der zu pflegenden Spezifikationen zu beschäftigen. Dies schließt den Anwender-Support, das Benutzer-Feedback (Fehlermeldungen, Erweiterungen usw.) über die Internetseite und die Verwaltung derselben ein. Zu diesem Zweck ist der Einsatz eines Issue-Trackers unerlässlich, in dem das Benutzer- Feedback und die Aufgaben dokumentiert und einzelnen Bearbeitern des AAS zugeordnet werden. Der für Benutzer transparente Umgang mit dem Feedback wurde mit Hilfe der Business Process Modelling Notation (BPMN 2.0 (26)) modelliert. Die dort abgebildeten Prozesse orientieren sich an der ISO 14817 (15).

Zusätzlich zu den oben genannten Aufgaben führt der AAS alle erforderlichen technischen Arbeiten zur Unterstützung der laufenden Standardisierung von OTS durch Standardisierungsorgane (hier DIN) aus. Begünstigt durch verteiltes Arbeiten auf einem gemeinsamen Datenbestand (z.B. SVN-Repository), ein definiertes Konfigurationsmanagement und Kommunikation über einen Emailverteiler, können die Sitzungen des AAS nach Bedarf stattfinden und auf ein Minimum reduziert werden.

Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.

1.1.1.3.4     Entscheidungsfindung

Das Entscheidungsorgan im OTS-Pflegeprozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des OTS-Prozesses (5). Um Entscheidungen über aufgeworfene Fragen im LK zu erreichen wird eine Abstimmung durchgeführt. Bei jedem Abstimmungs-Gegenstand hat jeder teilnehmende Interessensvertreter eine Stimme. Die Stimmen fehlender Interessenvertreter und Stimmenthaltungen haben keinen Einfluss auf den Ausgang der Abstimmung über ein Thema, es sei denn die Position der abwesenden Interessengruppe wurde dem LK zuvor mitgeteilt.

Ein abwesender Interessensvertreter kann dem LK seine Position vor der Abstimmung bekannt geben. Sie muss dem Vorsitzenden des LK in schriftlicher Form vorliegen. Der Vorsitzende des LK hat dafür zu sorgen, dass diese Position in der Abstimmung Berücksichtigung findet.

Abstimmungen können auf zwei Arten geschehen:

·         während eines Treffens des LK

·         per E-Mail über den LK Email-Verteiler

Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:

·         Zustimmung,

·         Ablehnung,

·         Enthaltung.

Abwesende und Stimmenthaltungen werden nicht berücksichtigt und haben somit keinen Einfluss auf das Ergebnis der Abstimmung. Zur Erreichung der Beschlussfähigkeit für eine gültige Entscheidung des LK müssten jedoch mindestens 50% der verfügbaren Stimmen entweder als Zustimmung oder als Ablehnung abgegeben werden (d.h. die Mehrheit der LK Teilnehmer muss sich für eine bestätigte Position ausgesprochen haben).

Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt.

Haben Erweiterungen des OTS 2 Standards/ OTS-Testrahmenwerks oder Problemlösungen des AAS zur Berücksichtigung von Änderungswünschen oder Behebung gemeldeter Fehler Auswirkungen auf die Abwärtskompatibilität zu einer vorherigen Version, beträgt die erforderliche Mehrheit im LK 75%.

Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung des OTS 2 Standards/ OTS-Testrahmenwerks erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

Alle Änderungen des OTS 2 Standards, darunter auch Erweiterungen, die in den Standard integriert werden sollen, werden alle drei Jahre im Rahmen einer Überprüfung/Überarbeitung des Standards den entsprechenden Standardisierungsorganen (hier DIN PAS Workshop) zugeführt.

1.1.1.4   Fazit

Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:

Jeder lebendige Standard braucht einen lebendigen Pflegeprozess. Dieser Prozess wird aber nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben, sondern muss von den Stakeholdern, wie Anwender, Hersteller und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufrieden-stellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen. Die Akzeptanz des Standards wird gesteigert, wenn der Pflegeprozess für alle Stakeholder offen und transparent ist.

Zudem braucht der Prozess paritätische Verhältnisse, um alle Interessen auszugleichen. Dies bedeutet zum einen ein gleichmäßiges Verhältnis von Stimmen im entscheidenden Gremium (hier Lenkungskomitee). Zum anderen müssen die Kosten für den Prozess von den Stakeholdern getragen werden, die auch einen Nutzen haben – dabei muss der Nutzen die Kosten natürlich substantiell übertreffen. Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:

•           Bereitstellung von personellen Ressourcen

•           Finanzierung über den Verkauf von Produkten

•           Finanzierung über (geförderte) Projekte

•           Finanzielle Unterstützung durch die Politik

Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im OTS-Prozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeord-neter Interessen potentielle (finanzielle) Unterstützer – speziell das BMVBS und DG MOVE (IVS-Architektur Deutschland, Implementierung der EU IVS Richtlinie, Umsetzung des Urban Mobility Action Plan).

Generell scheint die Etablierung und Finanzierung des OTS-Prozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

1.2       OTS-Standardisierung

1.2.1       Problemstellung

Im Rahmen des AP6 – OTS-Standardisierung – sollten der Einsatz und die Verbreitung von OTS durch die offizielle Standardisierung bzw. Normung unterstützt und gestärkt werden. Aus einem De-Facto-Standard sollte ein offizieller Standard entstehen, um national und ggf. international eine bessere Positionierung zu erreichen. Für die Ausschreibungen des Kommunikationsstandards wird dadurch eine wesentlich sicherere und belastbarere Grundlage geschaffen.

Auch im Zusammenhang mit der Verwendung von DATEX II wurde eine formale Standardisierung als notwendig erachtet, um den Ansprüchen der vorhandenen Nutzergemeinde zu genügen. Es sollte dabei recherchiert werden, inwiefern ein Anschluss an die laufenden Normierungsarbeiten bzgl. DATEX II möglich bzw. sinnvoll ist, oder ob ein neuer Standardisierungs-oder Normierungsprozesses angestoßen werden muss.

In jedem Fall sollten die Entwicklungen so weit vorangetrieben werden, dass die OTS 2 Schnittstellenspezifikation formal und inhaltlich auf ein standardisierungsfähiges Niveau gehoben wird und der Status eines fortgeschrittenen oder mindestens aussichtsreich begonnenen Standardisierungs- oder Normierungsprozess auf deutscher, nach Möglichkeit auch europäischer Ebene, erreicht wird.

In dem Fall, dass sich dies als nicht praktikabel erweisen sollte, z.B. weil die erforderliche öffentliche Konsensbildung übermäßig viel Zeit in Anspruch nehmen würde, so sollte alternativ untersucht werden, ob der Status einer Publicly Available Specification (PAS) oder eines CEN Workshop Agreement (CWA) anzustreben ist.

Um die Standardisierungsbemühungen ggf. auch nach dem Ende des Projekts fortführen zu können sollte eine Möglichkeit gefunden werden, wie die Standardisierung in den OTS-Prozess eingebettet werden kann.

1.2.2       Ergebnisse

Im Rahmen des AP6 – OTS-Standardisierung – hat sich die AP-Leitung im Projekt mit dem Thema Standardisierung/Normung von OTS 2 beschäftigt und geprüft, inwiefern aus diesem Gebiet innerhalb der Projektlaufzeit vernünftige Ergebnisse erzielt werden können.

Dabei wurde festgestellt, dass durchaus zwischen Normung und Standardisierung zu unterscheiden ist.

Eine Norm wird von einem offiziellen Gremium erarbeitet, bei dem die Teilnahme für alle interessierten Parteien offen ist und alle Seiten gleiches Mitspracherecht haben, dessen Entscheidungsprozesse auf Konsens basieren und definierte Berufungsinstanzen ein unabhängiges Verfahren garantieren. Solche Gremien sind z.B. die ISO (International Organization for Standardization) auf internationaler Ebene, CEN (European Committee for Standardization) auf europäischer Ebene und das DIN (Deutsches Institut für Normung) auf nationaler Ebene.

Eine Norm benötigt von Beginn des Prozesses bis zur fertigen Norm mehrere Jahre. Dies und der Umstand, dass ein Konsens über eine in einem Forschungsprojekt mit wenigen Beteiligten entstandene Schnittstellenspezifikation allein schon auf nationaler Ebene unwahrscheinlich ist, schlossen den Weg der Normung aus.

Im Gegensatz dazu kann ein Standard von einem Konsortium spezifiziert werden, das erwartet, dass sich dieser Standard langfristig am Markt durchsetzen wird. Der Konsens beschränkt sich zunächst auf die mitwirkenden Mitglieder. Spezifikationsgegenstand können Produkte, Systeme oder Dienstleistungen sein.

Auf diesem Gebiet bieten das DIN und das CEN Unterstützung durch entsprechende öffentliche Verfahren (Publicly Available Specification, CEN Workshop Agreement), die weitaus weniger Zeit in Anspruch nehmen (ca. 6 Monate bzw. ca. 8 Monate), einen normativen Charakter haben und in Deutschland öffentlich über den Beuth Verlag zu beziehen sind. Zudem sind diese Spezifikationsverfahren eine optimale Ausgangslage für die Erstellung einer Norm zu einem späteren Zeitpunkt, wenn sich der Standard etabliert hat und ein breiterer Konsens erzielt werden kann.

Auf der Basis dieser Erkenntnisse, einer Absprache mit dem Deutschen Institut für Normung e.V. (DIN) und der Abstimmung mit den OTS 2 Partnern, gelangte die AP-Leitung zu der Überzeugung, dass eine OTS 2 Standardisierung nach dem DIN SPEC PAS-Verfahren aus Projektsicht der beste Weg ist.

Das CWA-Verfahren wurde zunächst nicht weiter berücksichtigt, da für dieses Verfahren etwas mehr Zeit eingeplant werden muss, als für das PAS-Verfahren. Zumal hätte dafür die bestehende OTS 2 Schnittstellenspezifikation in englischer Sprache vorliegen müssen.

Ergebnis des Projektes OTS 2 wäre damit nicht nur eine OTS 2 Schnittstellenspezifikation, die nach Projektende durch die OCA propagiert wird, sondern ein offizielles Dokument mit normativem Charakter, das später nach einer Etablierungsphase in den Status einer Norm gehoben werden kann.

Im Januar 2010 wurde mit den Arbeiten an der SPEC PAS begonnen und folgende interessierte Fachkreise zur Mitarbeit eingeladen:

• Baulastträger und Betreiber der öffentlichen Hand
  (Mitglieder der OCA: 38 Stadt- und Landesverwaltungen aus Deutschland, Österreich und der Schweiz)
• Hersteller aus dem Bereich der Verkehrstechnik
• Verbände und Fachgremien aus dem Bereich der Verkehrstechnik
• Interessenten aus anderen Forschungsprojekten, wie Dmotion, SIM-TD und DISTEL
• Weitere Interessenten
  Beispiel ist die DB-Netze AG, die sich mit dem Thema Zertifizierung von Systemen in verteilten Systemlandschaften aktiv auseinandersetzt

Letztendlich nahmen folgende Personen an der Erarbeitung der DIN SPEC (PAS) im Berichtszeitraum teil:

Tabelle 6: Teilnehmer DIN SPEC (PAS) Workshop zu OTS 2

Name	Institution
Bauer, Anton	Landeshauptstadt München
Engel, Christoph	Institut für Automation und Kommunikation e.V. ifak
Jahnke, Henry	Senatsverwaltung für Stadtentwicklung Berlin, Verkehrslenkung Berlin
Kaltwasser, Josef	AlbrechtConsult GmbH
Kanngießer, Volker	Straßenverkehrsamt Stadt Frankfurt am Main
Krause, Jan	Institut für Automation und Kommunikation e.V. ifak
Lange, Jörg (stellv. Obmann)	Senatsverwaltung für Stadtentwicklung Berlin Verkehrslenkung LVB
Leonhardt, Frank	Stadtlicht GmbH, Berlin
Lüpges, Christian (Obmann)	AlbrechtConsult GmbH
Ortgiese, Michael	PTV Planung Transport Verkehr AG, Karlsruhe
Rosier, Holger	ComNets Research Group, RWTH Aachen
Schön, Thilo	GEVAS software GmbH
Tollmann, Markus	Fachbereich Verkehrssteuerung Freie und Hansestadt Hamburg, Landesbetrieb Straßen, Brücken und Gewässer

In Zusammenarbeit mit den Teilnehmern des SPEC PAS Workshops wurde ein Businessplan erarbeitet, der das Ziel des Workshops erläutert, die notwendigen Arbeitsschritte beschreibt und einen detaillierten Zeitplan enthält.

Folgende Arbeitsschritte wurden definiert:

1.    Erstellung des Geschäftsplans

2.    Veröffentlichung des Geschäftsplans

3.    Erarbeitung des Manuskripts

• Auswahl der Teile der vorhandenen OTS 2 Schnittstellenspezifikation, die in die DIN SPEC überführt werden sollen
• Transfer der relevanten Teile der OTS 2 Schnittstellenspezifikation unter Berücksichtigung der formalen Vorgaben des DIN SPEC (PAS)-Verfahrens

4.    Veröffentlichung des Manuskripts

5.    Bearbeitung der eingehenden Stellungnahmen

6.    Verabschiedung der DIN SPEC (PAS) im Gremium

7.    Veröffentlichung als DIN SPEC (PAS)

Dabei wurde der nachstehende Zeitplan zugrunde gelegt:

Tabelle 7: Zeitplan Standardisierung OTS 2

Monat	Jan		Feb		Mar		Apr		Mai		Jun		Jul		Aug		Sep
1.-15. / 16.-31.	1	2	1	2	1	2	1	2	1	2	1	2	1	2	1	2	1	2
Aktivität
1.     Erstellung Geschäftsplan
2.     Veröffentlichung Geschäftsplan
3.     Erarbeitung Manuskript
4.     Veröffentlichung Manuskript
5.     Bearbeitung Stellungnahmen
6.     Verabschiedung DIN SPEC (PAS) im Gremium
7.     Veröffentlichung DIN SPEC (PAS)
Sitzungen

Nach der Verabschiedung und der Veröffentlichung des Businessplans wurde mit der Anpassung der OTS 2 Schnittstellenspezifikation an die formalen Kriterien einer PAS im März begonnen.

Im Rahmen des Workshops wurde beschlossen, die PAS in zwei Teile zu gliedern:

• Teil 1 Einführende Erläuterungen für Entscheidungsträger (4)
• Teil 2 Technische Spezifikation für Implementierer (5)

Der Teil 1 erläutert Entscheidungsträgern den Anwendungsbereich und potentiellen Nutzen bzw. Mehrwert der OTS 2 Schnittstellenspezifikation.

Teil 2 spezifiziert die OTS 2-Schnittstelle zwischen zwei Kommunikationspartnern, die über ein Netzwerkprotokoll miteinander kommunizieren, und ihre Implementierung über den OTS 2-Protokollstapel.

Die Workshopteilnehmer verabschiedeten einstimmig als letzte Handlung vor der Schließung des Workshops im September 2010 die beiden Teile des Standards, die dann beim DIN nochmals einer formalen Qualitätssicherung unterzogen wurden.

Seit dem 14.03.2011 ist die komplette OTS 2 Schnittstellenspezifikation beim Beuth-Verlag unter der Bezeichnung DIN SPEC 91213 downloadbar bzw. bestellbar.

Ergänzende Dateien (z.B. XML-Schema Dateien), die zur Realisierung der OTS 2 Schnittstelle benötigt werden, sind auf der Internetseite www.opentrafficsystems.org zum Download angeboten.

Parallel zur OTS 2 Standardisierungsinitiative hat die Firma Siemens den OCA-Vorstand im März 2010 über ihre Initiative informiert, die von ihr im Rahmen eigener Projekte entwickelte sog. OCPI-Schnittstelle unter der Bezeichnung OCIT-C einer Vervollständigung und Standardisierung der Deutsche Kommission Elektrotechnik Elektronik Informationstechnik im DIN und VDE (DKE) zuzuführen. Die Initiative begann im August 2009 in Zusammenarbeit mit den Firmen Schlothauer&Wauer, PTV AG und Swarco. Die Gründung des DKE Arbeitskreises fand im März 2010 statt.

Die Initiative ist aus OTS Sicht als positiv zu bewerten. Sie zeigt, welche Auswirkungen das Projekt OTS 2 und die Beharrlichkeit der OCA in Bezug auf die Standardisierung von Schnittstellen im Zentralen- und Verkehrsmanagementbereich hat. Es wurde von Seiten der Industrie verstanden, dass der Weg weg vom reinen Industriestandard, hin zu einem offenen und von allen Marktbeteiligten tragbaren Schnittstellenstandard beschritten werden muss. Dies wird im Markt der Straßenverkehrstechnik zu einer weiteren Öffnung der heute vielfach noch monolithisch aufgebauten zu den von der OCA geforderten herstellermischbaren Systemen beitragen.

Die OCA und die OTS 2 Projektpartner haben sich für einen offenen Austausch zwischen der vor einigen Jahren gestarteten und schon weit fortgeschrittenen, auf OCIT-Instations basierenden OTS-Standardisierungsinitiative und der noch jungen OCIT-C-Initiative ausgesprochen und werden diesen mit vorantreiben.

Im Idealfall können beide Initiativen konvergieren. Dies ist gerade in Bezug auf die europäische Standardisierung zwingend erforderlich ist. Einigkeit besteht auch darüber, dass über CEN TC278/WG8 und nicht über CENELEC standardisiert werden soll.

1.3       Veröffentlichungen

Alle wesentlichen und für die Öffentlichkeit interessanten Ergebnisse des Projektes OTS 2 wurden bzw. werden auf der Internetseite www.opentrafficsystems.org bereitgestellt.

Die Strukturierung des Downloadbereiches wurde an die Struktur des OTS-Rahmenwerks angelehnt. So werden, soweit möglich, alle wesentlichen Projektergebnisse den Säulen

• OTS-Kommunikation,
• OTS-Instrumente,
• OTS-Prozess

sowie den entsprechenden untergeordneten Bausteinen zugeordnet.