Diskussion:Los1: Pflegekonzept IVS-RA: Unterschied zwischen den Versionen

Aus IVS-Wiki
Zur Navigation springen Zur Suche springen
 
(9 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
== Einführung ""
+
== Aufgabenstellung ==
  
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 IVS-Architektur Prozess.
+
Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (IVS-Rahmenarchitektur und die in den Losen 2-4 ausgeschriebenen drei Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.
  
 +
Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, die IVS-Rahmenarchitektur in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege der IVS-Rahmenarchitektur folgenden Aufgaben:
  
 +
*Um Wirkung und Nutzen der IVS-Rahmenarchitektur auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege der IVS-Rahmenarchitektur (IVS-Rahmenarchitektur Prozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung der in diesem Projekt definierten IVS-Rahmenarchitektur und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.
  
 +
*Für die Einführung und Umsetzung des IVS-Rahmenarchitektur Prozess muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.
  
 +
== Weiterentwicklung und Pflege der IVA-Rahmenarchitektur ==
  
So stellt sich das Prozessmodell 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.
+
=== Problemstellung ===
  
Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:
+
Das nationale Rahmenwerk für IVS-Architektur "Straße" (kurz: die IVS-Rahmenarchitektur) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste. Um Planungs- und Rechtssicherheit • in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und • der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss der IVS-Rahmenarchitektur quasi der Stellenwert eines Standards beigemessen werden. Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was die IVS-Rahmenarchitektur ist und wie die IVS-Rahmenarchitektur angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.
  
·         Wie passt sich der Standard an neue Anforderungen an?
+
Die IVS-Rahmenarchitektur muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten IVS-Rahmenarchitektur-Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, die IVS-Rahmenarchitektur als offenen Standard verfügbar zu machen, stellt an die an diesem IVS-Rahmenarchitektur-Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit der IVS-Rahmenarchitektur eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am IVS-Rahmenarchitektur Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.
  
·         Wie reagiert der Standard auf die Entdeckung von Fehlern?
+
Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem IVS-Rahmenarchitektur Prozess beteiligen können. Damit die IVS-Rahmenarchitektur ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.
  
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.
+
Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der IVS-Rahmenarchitektur Prozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.
  
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 OTS-Prozess (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.
+
=== Der IVS-Rahmenarchitektur Prozess ===
  
Generell muss gelten, dass die Anforderungen an den OTS-Prozess 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.
+
Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im IVS-Rahmenarchitektur Prozess, das folgende Abbildung visualisiert:
  
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.
+
[[File:IVS-RA-Prozess.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]
  
==== [[Los1:1.1.1.2_Aufgaben_des_OTS-Prozesses|1.1.1.2   Aufgaben des OTS-Prozesses]] ====
+
Das IVS-Rahmenarchitektur Prozessmodell stellt sich 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 IVS-Rahmenarchitektur ist von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirkt häufig als Initialzündung für die weitere Pflege des IVS-Rahmenarchitektur. Die in der Folge von IVS-Architekten entwickelten IVS-Rahmenarchitektur Versionen werden in einer neuen (Unter-)Version dem Markt zur Realisierung zur Verfügung gestellt.
  
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:
+
Durch die Dokumentation des IVS-Rahmenarchitektur Prozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des IVS-Rahmenarchitektur Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz der IVS-Rahmenarchitektur bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.
  
·         OTS 2 Schnittstellenstandard (Fehlerbehebung und Erweiterung)
+
Ohne ein gewisses Maß an Marktakzeptanz kann der IVS-Rahmenarchitektur Prozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version der IVS-Rahmenarchitektur erkennbar, was wiederum durch ein entsprechendes Feedback in den IVS-Rahmenarchitektur Prozess eingebracht wird und damit die Weiterentwicklung der IVS-Rahmenarchitektur vorantreibt.
  
·         OTS-Testrahmenwerk (Konformitäts- und Interoperabilitätstests)
+
Hieraus ergeben sich grundsätzlich folgende Fragen bzgl. des Standardisierungsprozesses:
 
 
·         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:
+
*Wie passt sich die IVS-Rahmenarchitektur an neue Anforderungen an?
 +
*Wie reagiert die IVS-Rahmenarchitektur auf die Entdeckung von Fehlern?
  
·         Höhere Gewissheit der Fehlerfreiheit bei geprüften als bei ungeprüften Implementierungen
+
=== Aufgaben des IVS-Rahmenarchitektur Prozesses ===
  
·         Kein Vorhalten eigener Testsysteme
+
Die grundsätzlichen Aufgaben des IVS-Rahmenarchitektur Prozesses unterteilen sich in die Bereiche
  
·         Informationen über die Konformität aus Testergebnissen einsehbar
+
*Pflege der IVS-Rahmenarchitektur,
 +
*Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.
  
·         Vergleichbarkeit unterschiedlicher Hersteller hinsichtlich der Qualität der Implementierung
+
Die Arbeiten zur Pflege der IVS-Rahmenarchitektur erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:
  
Aber auch die Hersteller profitieren aus folgenden Gründen von einer Zertifizierungsmöglichkeit:
+
*Pflege und Erweiterung der Basiskonzepte Pflege und
 +
*Erweiterung der IVS-Architekturbausteine Pflege und
 +
*Erweiterung des TOGAF-basierten Vorgehensmodells *evtl. weitere...
  
·         Sicherstellung der Konformität der Implementierung bzgl. der Spezifikation
+
Für die Pflege der IVS-Rahmenarchitektur müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung der IVS-Rahmenarchitektur auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.
  
·         Leichtere Identifizierbarkeit von fehlerhaften Implementierungen bei Verfügbarkeit von abgestimmten Konformitätstests (+ Testfällen)
+
Die Ergebnisse des Pflegeprozesses werden in die IVS-Rahmenarchitektur eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege der IVS-Rahmenarchitektur zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.
  
·         Vermeidung von Auseinandersetzungen zwischen Herstellern durch Vorlage objektiver Testergebnisse
+
'''Anwendersupport'''
  
·         Zusätzliche Qualitätssicherung bei der Entwicklung durch Konformitätstests
+
Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung IVS-Rahmenarchitektur und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.
  
·         Bessere Marktpositionierung durch positiv geprüfte Implementierungen
+
Für eine Kollaboration von Entwicklern der IVS-Rahmenarchitektur und Firmen, die ihre Produktpalette konform zur IVS-Rahmenarchitektur entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren 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.
  
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.
+
'''Issue-Tracking'''
  
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.
+
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 der IVS-Rahmenarchitektur zu unterstützten. Im Projekt IVS-Rahmenarchitektur wurde dazu mit der Internetplattform www.......org der Grundstein gelegt. Dort finden sich alle Informationen rund um die IVS-Rahmenarchitektur. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den IVS-Rahmenarchitektur Prozess.
  
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.
+
Über das Portal sind nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses bietet eine Feedback-Möglichkeit für Nutzer der IVS-Rahmenarchitektur (Fehlerreports, Anforderungen an IVS-Rahmenarchitektur, usw.).
  
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.
+
Die folgende Abbildung zeigt das IVS-Wiki Portal:
  
Im Projekt OTS 2 wurde dazu mit der Internetplattform [http://www.opentrafficsystems.org/ 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:IVS-Wiki.jpg|500px|Das IVS-Wiki Portal]]
  
{| align="center" border="0" cellspacing="0" cellpadding="0"
+
'''Öffentlichkeitsarbeit'''
|-
 
| style="width:614px;" |
 
[[File:]]
 
  
|-
+
Zu den beschriebenen Aufgaben der Pflege der IVS-Rahmenarchitektur bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit 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.
| style="width:614px;" |
 
'''[[Los1:Abbildung|Abbildung ]]55: OTS-Internetportal'''
 
  
|}
+
Im Projekt IVS-Rahmenarchitektur wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen 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 IVS-Rahmenarchitektur Prozesses zu binden.
<div style="clear:both;"></div>
 
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&nbsp;2 wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise in die Entwicklung des OTS&nbsp;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:
+
'''Sekretariat'''
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Baulastträger und Betreiber der öffentlichen Hand<br/> Eingeladen wurden die Mitglieder der OCA (38 Stadt- und Landesverwaltungen aus Deutschland, Österreich und der Schweiz)
+
Letztendlich sollten auch Ressourcen für die Verwaltung des IVS-Rahmenarchitektur Prozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des IVS-Rahmenarchitektur 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 IVS-Rahmenarchitektur 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 Entwicklern und Anwendern der IVS-Rahmenarchitektur steigen.
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Hersteller aus dem Bereich der Verkehrstechnik
+
== Organisation des IVS-Rahmenarchitektur Prozesses ==
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Verbände und Fachgremien aus dem Bereich der Verkehrstechnik
+
=== Überblick ===
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Interessenten aus anderen Forschungsprojekten, wie SIM-TD und DISTEL
+
Um den IVS-Rahmenarchitektur 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 IVS-Rahmenarchitektur Prozesses orientiert sich dabei an bereits bestehende erfolgreiche Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Weitere Interessenten<br/> Beispiel ist die DB-Netze AG, die sich mit dem Thema Zertifizierung von Systemen in verteilten Systemlandschaften aktiv auseinandersetzt
+
[[File:IVS-RA-Prozess Organisation.jpg|500px|Organisation des IVS-Rahmenarchitektur Prozesses]]
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fachpresse
+
=== Stakeholder ===
  
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.
+
Wie zuvor beschrieben, wird empfohlen, dass der IVS-Rahmenarchitektur 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:
  
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.
+
{| style="width: 500px;" border="1" cellspacing="1" cellpadding="1"
 
 
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&nbsp;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.
 
 
 
==== [[Los1:1.1.1.3_Organisation_des_OTS-Prozesses|1.1.1.3&nbsp;&nbsp; Organisation des OTS-Prozesses]] ====
 
 
 
===== ''1.1.1.3.1''&nbsp;&nbsp;&nbsp;&nbsp; ''Ü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.
 
 
 
{| align="center" border="0" cellspacing="0" cellpadding="0"
 
 
|-
 
|-
| style="width:614px;" |
+
! style="background-color: rgb(238, 238, 238);" scope="col" | Gruppierung
 
+
! style="background-color: rgb(238, 238, 238);" scope="col" | Interessenvertretung
 
 
|-
 
| style="width:614px;" |  
 
'''Abbildung 56: Organisation des OTS-Prozesses'''
 
 
 
 
 
 
 
|}
 
<div style="clear:both;"></div>
 
===== [[Los1:''1.1.1.3.2''_''Stakeholder''|''1.1.1.3.2''&nbsp;&nbsp;&nbsp;&nbsp; ''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:
 
 
 
 
 
 
 
{| border="1" cellspacing="0" cellpadding="0"
 
|-
 
| style="width:111px;" |
 
'''Gruppierung'''
 
 
 
| style="width:504px;" |  
 
'''Interessensvertretung'''
 
 
 
 
|-
 
|-
| style="width:111px;" |
+
| Öffentliche Hand
Anwender
+
| BASt, Experten der Länder und Kommunen&nbsp;
 
 
| style="width:504px;" |  
 
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
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; den Wettbewerb zu fördern,
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; die Wirtschaftlichkeit und Qualitätssicherung bei Beschaffung und im Betrieb zu fördern,
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ausschreibungsverfahren zu vereinfachen und zu verkürzen,
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; den direkten Informationsaustausch zwischen den betroffenen Verwaltungsabteilungen auf nationaler und internationaler Ebene zu fördern,
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; die Anforderungsprofile zu bündeln, und so die Position der Baulastträger gegenüber der Industrie zu stärken.
 
 
 
 
|-
 
|-
| style="width:111px;height:70px;" rowspan="3" |
+
| Consultants
Hersteller
+
|  
 
 
| style="width:504px;height:70px;" |
 
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.
 
 
 
 
|-
 
|-
| style="width:504px;height:24px;" |
+
| Hersteller
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.
 
 
 
 
|-
 
|-
| style="width:504px;height:30px;" |  
+
| Standardisierungsorganisationen
ODG&Partner (22)
+
|  
 
 
Um die Firmen PTV AG, Schlothauer & Wauer GmbH und GEVAS software GmbH erweiterte Arbeitsgemeinschaft der Signalbaufirmen zur Standardisierung von zentralen Schnittstellen
 
 
 
 
|-
 
|-
| style="width:111px;" rowspan="2" |
+
| Verbände
Sonstige Interessenten
+
|  
 
 
| style="width:504px;" |
 
Verband der Ingenieurbüros für Verkehrstechnik (VIV e.V.) (24)
 
 
 
Der VIV verfolgt im Rahmen seiner Verbandstätigkeit folgende Ziele:
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Sicherung unabhängiger Beratung auf dem Gebiet der Straßenverkehrstechnik
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Spezifikation der Ingenieurleistungen auf dem Gebiet der Straßenverkehrstechnik
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Definition von einheitlichen Leistungsbildern und Qualitätsansprüchen in der Straßenverkehrstechnik
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Erarbeitung von einheitlichen Vertragsmustern, Haftungs- und Gewährleistungsregeln
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Erarbeitung von gemeinsamen Verfahren zur Lösung von Aufgaben im Verkehrswesen ohne Bevorzugung von Einzelinteressen
 
 
 
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Mitarbeit in einschlägigen Gremien und Organisationen
 
 
 
 
|-
 
|-
| style="width:504px;" |  
+
| Sonstige
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 IVS-Rahmenarchitektur Prozesses darstellen. Gemeinsam würden Sie die Interessensgruppe für den IVS-Rahmenarchitektur Prozess bilden.
  
 +
=== Organe des IVS-Rahmenarchitektur Prozesses und ihre Funktion ===
  
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.
+
Es gibt zwei primär beteiligte Organe im IVS-Rahmenarchitektur Prozess, die zusammen eine Arbeitsgemeinschaft bilden. Jedes Organ hat eine andere Rolle zu erfüllen, wie im Folgenden aufgeführt wird:
 
 
===== [[Los1:''1.1.1.3.3''_''Organe_des_OTS-Prozesses_und_ihre_Funktion''|''1.1.1.3.3''&nbsp;&nbsp;&nbsp;&nbsp; ''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.
+
'''Das Lenkungskomittee'''
  
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.
+
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.
  
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.
+
Das LK besteht aus Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.
  
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).
+
Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des IVS-Rahmenarchitektur Prozesses an die vertretenen Interessengruppen. 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.
  
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.
+
'''Der Arbeitsausschuss'''
  
Natürlich muss eine Einigung darüber erzielt werden, wie das Hosting der Internetseite finanziert wird.
+
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 IVS-RAhemnarchtektur zu beschäftigen. Dies schließt den Anwender-Support, das Benutzer-Feedback (Fehlermeldungen, Erweiterungen usw.) über die Internetseite und die Verwaltung derselben ein.
  
===== [[Los1:''1.1.1.3.4''_''Entscheidungsfindung''|''1.1.1.3.4''&nbsp;&nbsp;&nbsp;&nbsp; ''Entscheidungsfindung'']] =====
+
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 Arbeiten 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.
  
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.
+
=== Entscheidungsfindung ===
  
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.
+
Das Entscheidungsorgan im IVS-Rahmenarchitektur Prozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des IVS-Rahmenarchitektur Prozesses. 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.
  
Abstimmungen können auf zwei Arten geschehen:
+
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:
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; während eines Treffens des LK
+
*während eines Treffens des LK  
 
+
*per E-Mail über den LK Email-Verteiler  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; per E-Mail über den LK Email-Verteiler
 
  
 
Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:
 
Die Vorschläge sollten in einer Weise formuliert werden, dass folgende Wahloptionen möglich sind:
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Zustimmung,
+
*Zustimmung,  
 +
*Ablehnung,
 +
*Enthaltung.
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Ablehnung,
+
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 der IVS-Rahmenarchitektur 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 der IVS-Rahmenarchitektur erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.
  
·&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Enthaltung.
+
== Finanzierung des IVS-Rahmenarchitektur Prozesses ==
  
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).
+
Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege IVS-Rahmenarchitektur übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Rahmenarchitektur (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.
  
Ist eine Abstimmung unentschieden, wird eine erneute Abstimmung durchgeführt. Wenn diese zweite Abstimmung ebenfalls unentschieden ausfällt, gilt der Vorschlag als abgelehnt.
+
Es muss also 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, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.
  
Haben Erweiterungen des OTS&nbsp;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%.
+
Es wird empfohlen, dass der IVS-Rahmenarchitektur Prozess von den Interessengruppen 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.
  
Wenn die erforderliche Mehrheit bezüglich einer Erweiterung/Änderung des OTS&nbsp;2 Standards/ OTS-Testrahmenwerks erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.
+
Die Zusammenführung von IVS-Architektur Kompetenz der Entwickler 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 Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im IVS-Rahmenarchitektur Prozess (Feedback) durch die Anwender maximiert.
  
Alle Änderungen des OTS&nbsp;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.
+
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-Rahmenarchitektur Prozess (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.
  
==== 1.1.1.4&nbsp;&nbsp; Fazit ====
+
== Fazit ==
  
 
Im Folgenden werden noch einmal die wichtigsten Aspekte der Handlungsempfehlung zusammengefasst:
 
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.
+
Jeder lebendige Standard, so auch die IVS-Rahmenarchitektur, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.
 
 
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:
 
 
 
•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Bereitstellung von personellen Ressourcen
 
 
 
•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Finanzierung über den Verkauf von Produkten
 
 
 
•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Finanzierung über (geförderte) Projekte
 
 
 
•&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 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.
 
 
 
== [[Los1:'''1.2'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''OTS-Standardisierung'''|'''1.2'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''OTS-Standardisierung''']] ==
 
 
 
=== [[Los1:'''1.2.1'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''Problemstellung'''|'''1.2.1'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''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&nbsp;2&nbsp;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.
 
 
 
 
 
 
 
=== [[Los1:'''1.2.2'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''Ergebnisse'''|'''1.2.2'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''Ergebnisse''']] ===
 
 
 
Im Rahmen des AP6 – OTS-Standardisierung – hat sich die AP-Leitung im Projekt mit dem Thema Standardisierung/Normung von OTS&nbsp;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&nbsp;2 Partnern, gelangte die AP-Leitung zu der Überzeugung, dass eine OTS&nbsp;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&nbsp;2 Schnittstellenspezifikation in englischer Sprache vorliegen müssen.
 
 
 
Ergebnis des Projektes OTS&nbsp;2 wäre damit nicht nur eine OTS&nbsp;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<br/> (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<br/> 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'''
 
 
 
{| width="574" style="width:574px;" border="1" cellspacing="0" cellpadding="0"
 
|-
 
| style="width:168px;" |
 
'''Name'''
 
 
 
| style="width:406px;" |
 
'''Institution'''
 
 
 
|-
 
| style="width:168px;" |
 
Bauer, Anton
 
 
 
| style="width:406px;" |
 
Landeshauptstadt München
 
 
 
|-
 
| style="width:168px;" |
 
Engel, Christoph
 
 
 
| style="width:406px;" |
 
Institut für Automation und Kommunikation e.V. ifak
 
 
 
|-
 
| style="width:168px;height:34px;" |
 
Jahnke, Henry
 
 
 
| style="width:406px;height:34px;" |
 
Senatsverwaltung für Stadtentwicklung Berlin, Verkehrslenkung Berlin
 
 
 
|-
 
| style="width:168px;" |
 
Kaltwasser, Josef
 
 
 
| style="width:406px;" |
 
AlbrechtConsult GmbH
 
 
 
|-
 
| style="width:168px;" |
 
Kanngießer, Volker
 
 
 
| style="width:406px;" |
 
Straßenverkehrsamt Stadt Frankfurt am Main
 
 
 
|-
 
| style="width:168px;height:9px;" |
 
Krause, Jan
 
 
 
| style="width:406px;height:9px;" |
 
Institut für Automation und Kommunikation e.V. ifak
 
 
 
|-
 
| style="width:168px;" |
 
Lange, Jörg
 
 
 
(stellv. Obmann)
 
 
 
| style="width:406px;" |
 
Senatsverwaltung für Stadtentwicklung Berlin
 
 
 
Verkehrslenkung LVB
 
 
 
|-
 
| style="width:168px;" |
 
Leonhardt, Frank
 
 
 
| style="width:406px;" |
 
Stadtlicht GmbH, Berlin
 
 
 
|-
 
| style="width:168px;" |
 
Lüpges, Christian<br/> (Obmann)
 
 
 
| style="width:406px;" |
 
AlbrechtConsult GmbH
 
 
 
|-
 
| style="width:168px;" |
 
Ortgiese, Michael
 
 
 
| style="width:406px;" |
 
PTV Planung Transport Verkehr AG, Karlsruhe
 
 
 
|-
 
| style="width:168px;" |
 
Rosier, Holger
 
 
 
| style="width:406px;" |
 
ComNets Research Group, RWTH Aachen
 
 
 
|-
 
| style="width:168px;" |
 
Schön, Thilo
 
 
 
| style="width:406px;" |
 
GEVAS software GmbH
 
 
 
|-
 
| style="width:168px;" |
 
Tollmann, Markus
 
 
 
| style="width:406px;" |
 
Fachbereich Verkehrssteuerung<br/> 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.&nbsp;&nbsp;&nbsp; Erstellung des Geschäftsplans
 
 
 
2.&nbsp;&nbsp;&nbsp; Veröffentlichung des Geschäftsplans
 
 
 
3.&nbsp;&nbsp;&nbsp; Erarbeitung des Manuskripts
 
 
 
*Auswahl der Teile der vorhandenen OTS&nbsp;2 Schnittstellenspezifikation, die in die DIN SPEC überführt werden sollen
 
*Transfer der relevanten Teile der OTS&nbsp;2 Schnittstellenspezifikation unter Berücksichtigung der formalen Vorgaben des DIN SPEC (PAS)-Verfahrens
 
 
 
4.&nbsp;&nbsp;&nbsp; Veröffentlichung des Manuskripts
 
 
 
5.&nbsp;&nbsp;&nbsp; Bearbeitung der eingehenden Stellungnahmen
 
 
 
6.&nbsp;&nbsp;&nbsp; Verabschiedung der DIN SPEC (PAS) im Gremium
 
 
 
7.&nbsp;&nbsp;&nbsp; Veröffentlichung als DIN SPEC (PAS)
 
 
 
 
 
 
 
Dabei wurde der nachstehende Zeitplan zugrunde gelegt:
 
 
 
'''Tabelle 7: Zeitplan Standardisierung OTS 2'''
 
 
 
{| align="center" border="1" cellspacing="0" cellpadding="0"
 
|-
 
| style="width:215px;" |
 
Monat
 
 
 
| style="width:38px;" colspan="2" |
 
Jan
 
 
 
| style="width:38px;" colspan="2" |
 
Feb
 
 
 
| style="width:38px;" colspan="2" |
 
Mar
 
 
 
| style="width:38px;" colspan="2" |
 
Apr
 
 
 
| style="width:38px;" colspan="2" |
 
Mai
 
 
 
| style="width:38px;" colspan="2" |
 
Jun
 
 
 
| style="width:38px;" colspan="2" |
 
Jul
 
 
 
| style="width:38px;" colspan="2" |
 
Aug
 
 
 
| style="width:38px;" colspan="2" |
 
Sep
 
 
 
|-
 
| style="width:215px;" |
 
1.-15. / 16.-31.
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
| style="width:19px;" |
 
1
 
 
 
| style="width:19px;" |
 
2
 
 
 
|-
 
| style="width:215px;" |
 
'''Aktivität'''
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
1.&nbsp;&nbsp;&nbsp;&nbsp; Erstellung Geschäftsplan
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
2.&nbsp;&nbsp;&nbsp;&nbsp; Veröffentlichung Geschäftsplan
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
3.&nbsp;&nbsp;&nbsp;&nbsp; Erarbeitung Manuskript
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
4.&nbsp;&nbsp;&nbsp;&nbsp; Veröffentlichung Manuskript
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
5.&nbsp;&nbsp;&nbsp;&nbsp; Bearbeitung Stellungnahmen
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
6.&nbsp;&nbsp;&nbsp;&nbsp; Verabschiedung DIN SPEC (PAS) im Gremium
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
7.&nbsp;&nbsp;&nbsp;&nbsp; Veröffentlichung DIN SPEC (PAS)
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|-
 
| style="width:215px;" |
 
'''Sitzungen'''
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
| style="width:19px;" |
 
 
 
 
 
|}
 
<div style="clear:both;"></div>
 
 
 
 
 
 
 
 
 
Nach der Verabschiedung und der Veröffentlichung des Businessplans wurde mit der Anpassung der OTS&nbsp;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&nbsp;2 Schnittstellenspezifikation.
 
 
 
Teil 2 spezifiziert die OTS&nbsp;2-Schnittstelle zwischen zwei Kommunikationspartnern, die über ein Netzwerkprotokoll miteinander kommunizieren, und ihre Implementierung über den OTS&nbsp;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&nbsp;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&nbsp;2 Schnittstelle benötigt werden, sind auf der Internetseite [http://www.opentrafficsystems.org/ www.opentrafficsystems.org] zum Download angeboten.
 
 
 
Parallel zur OTS&nbsp;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&nbsp;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&nbsp;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.
 
 
 
== [[Los1:'''1.3'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''Veröffentlichungen'''|'''1.3'''&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; '''Veröffentlichungen''']] ==
 
  
Alle wesentlichen und für die Öffentlichkeit interessanten Ergebnisse des Projektes OTS&nbsp;2 wurden bzw. werden auf der Internetseite [http://www.opentrafficsystems.org/ www.opentrafficsystems.org] bereitgestellt.
+
Die Akzeptanz der IVS-Rahmenarchitektur 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.
  
Die Strukturierung des Downloadbereiches wurde an die Struktur des OTS-Rahmenwerks angelehnt. So werden, soweit möglich, alle wesentlichen Projektergebnisse den Säulen
+
Für die Finanzierung des Prozesses gibt es dabei viele Möglichkeiten, die zu prüfen sind:
  
*OTS-Kommunikation,
+
*Bereitstellung von personellen Ressourcen
*OTS-Instrumente,
+
*Finanzierung über den Verkauf von Produkten
*OTS-Prozess
+
*Finanzierung über (geförderte) Projekte
 +
*Finanzielle Unterstützung durch die Politik
  
sowie den entsprechenden untergeordneten Bausteinen zugeordnet.
+
Insbesondere der letzte Aspekt ist von großer Bedeutung. Wenn die im IVS-Rahmenarchitektur Prozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter 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 IVS-Rahmenarchitektur Prozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.

Aktuelle Version vom 28. Februar 2018, 10:16 Uhr

Aufgabenstellung

Die Entwicklung einer ersten Version der in diesem Projekt definierten Architekturen (IVS-Rahmenarchitektur und die in den Losen 2-4 ausgeschriebenen drei Referenzarchitekturen) ist ein wichtiger Schritt hin zu plan- und steuerbaren IVS-Diensten, die zur Verbesserung der Umweltverträglichkeit, zur Steigerung der Effizienz und zur Erhöhung der Sicherheit im Straßenverkehr beitragen können.

Aufgrund sich ständig ändernder Rahmenbedingungen (z.B. Hinzukommen neuer Stakeholder und Anwendungsfelder, Entwicklung neuer Technologien, Änderung der gesetzlichen Anforderungen) ist es notwendig, die IVS-Rahmenarchitektur in regelmäßigen Abständen auf ihre Aktualität und Gültigkeit zu überprüfen und gegebenenfalls anzupassen. Auch TOGAF sieht z.B. eine ständige Kontrolle und Weiterentwicklung vor. Wichtig ist dazu eine Institutionalisierung dieser Aufgaben der Aktualisierung, Anpassung und Pflege deren Organisation und Finanzierung. Insofern beinhaltet das Konzept für die Weiterentwicklung und Pflege der IVS-Rahmenarchitektur folgenden Aufgaben:

  • Um Wirkung und Nutzen der IVS-Rahmenarchitektur auf Dauer erhalten und vorantreiben zu können, muss ein Konzept für den Prozess der Einführung, Weiterentwicklung und Pflege der IVS-Rahmenarchitektur (IVS-Rahmenarchitektur Prozess) entwickelt werden. Dabei sollte neben der Weiterentwicklung der in diesem Projekt definierten IVS-Rahmenarchitektur und IVS-Referenzarchitekturen auch die Identifikation und Entwicklung weiterer IVS Referenzarchitekturen berücksichtigt werden.
  • Für die Einführung und Umsetzung des IVS-Rahmenarchitektur Prozess muss ein Organisations- und Finanzierungskonzept erarbeitet werden. Wichtig ist insbesondere dabei, die Zuständigkeiten für die Weiterentwicklung und Pflege festzulegen. Dabei ist eine Verankerung im IVS-Gesetz sicherlich sinnvoll.

Weiterentwicklung und Pflege der IVA-Rahmenarchitektur

Problemstellung

Das nationale Rahmenwerk für IVS-Architektur "Straße" (kurz: die IVS-Rahmenarchitektur) ist konzeptionell ein an neue Anforderungen der Anwenderseite anpassbares Meta-Modell für die Entwicklung von IVS-Referenzarchitekturen und IVS-Architekturen realer IVS-Dienste. Um Planungs- und Rechtssicherheit • in der Anwendung und Handhabung des TOGAF-basierten Vorgehensmodells zur Entwicklung von IVS-Architekturen und • der auf den fünf Ebenen der IVS-Pyramide angesiedelten, primär die Zusammenarbeit von IVS-Akteuren adressierenden Kernaspekte von IVS-Architektur zu erhalten, muss der IVS-Rahmenarchitektur quasi der Stellenwert eines Standards beigemessen werden. Dem Wesen eines Standards entsprechend, muss die Festlegung dessen, was die IVS-Rahmenarchitektur ist und wie die IVS-Rahmenarchitektur angepasst oder erweitert wird, auf einer übergeordneten, neutralen Ebene geregelt werden.

Die IVS-Rahmenarchitektur muss deshalb Betrachtungs- und Handlungsgegenstand eines offenen und transparenten IVS-Rahmenarchitektur-Prozesses sein, der einen unmittelbaren Bezug zu Einrichtungen besitzt, welche die Kompetenz einer Standardisierungseinrichtung besitzen sollen. Der Anspruch, die IVS-Rahmenarchitektur als offenen Standard verfügbar zu machen, stellt an die an diesem IVS-Rahmenarchitektur-Prozess beteiligten Personen bestimmte Anforderungen im Hinblick auf Kompetenz und Unabhängigkeit. Es muss mit der IVS-Rahmenarchitektur eine Interessenslage geweckt werden, die Personen dazu motiviert, sich am IVS-Rahmenarchitektur Prozess zum Zwecke der Pflege und Fortschreibung des Standards nebst der Festlegung der erforderlichen Konformitäts-Rahmenbedingungen zu beteiligen.

Einrichtungen und Unternehmen, die solche Personen beschäftigen, müssen Mittel bereitstellen wollen, damit sich Mitarbeiter auch wirklich an diesem IVS-Rahmenarchitektur Prozess beteiligen können. Damit die IVS-Rahmenarchitektur ein offener Standard bleibt, werden Mechanismen benötigt, die dies sicherstellen.

Eine gewisse Anlehnung an die Verfahren anderer Standardisierungseinrichtungen scheint hier angebracht. Ziel muss es sein, eine Organisationsgrundstruktur, das Qualitätsmanagement und die Anbindung an die Standardisierung zu entwickeln. Auf Grundlage dieses Modells soll der IVS-Rahmenarchitektur Prozess nach Möglichkeit unter Beteiligung aller in die Entwicklung und den Betrieb von IVS und IVS-Diensten involvierten und aller sonstigen Stakeholder im Bereich IVS (Bund, Länder, Industrie, Beratungsunternehmen, …) institutionalisiert und instanziiert werden.

Der IVS-Rahmenarchitektur Prozess

Standards müssen in einem lebendigen Prozess gepflegt und weiterentwickelt werden, sonst drohen sie zu verkümmern. So ist der aktuelle Stand der IVS-Rahmenarchitektur lediglich eine Momentaufnahme im IVS-Rahmenarchitektur Prozess, das folgende Abbildung visualisiert:

Organisation des IVS-Rahmenarchitektur Prozesses

Das IVS-Rahmenarchitektur Prozessmodell stellt sich 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 IVS-Rahmenarchitektur ist von großer Bedeutung zur Weiterentwicklung bzw. zur Fehlerbehebung und wirkt häufig als Initialzündung für die weitere Pflege des IVS-Rahmenarchitektur. Die in der Folge von IVS-Architekten entwickelten IVS-Rahmenarchitektur Versionen werden in einer neuen (Unter-)Version dem Markt zur Realisierung zur Verfügung gestellt.

Durch die Dokumentation des IVS-Rahmenarchitektur Prozesses (Ereignisverfolgung/Issue-Tracking) sowie ggfs. die Veröffentlichung von Ergebnissen von begleitenden Forschungsprojekten werden die Nutzer stets über den aktuellen Stand informiert und damit aktiv bei der Umsetzung unterstützt. Eine formelle Freigabe von Ergebnissen des IVS-Rahmenarchitektur Prozesses gibt den Anwendern zusätzlich Planungssicherheit. Mit diesen Maßnahmen soll die Akzeptanz der IVS-Rahmenarchitektur bei den Nutzern gefördert und damit die Voraussetzung für ihre Durchsetzung am Markt geschaffen werden.

Ohne ein gewisses Maß an Marktakzeptanz kann der IVS-Rahmenarchitektur Prozess nicht überleben. Durch die Anwendung ergeben sich beim Anwender weitere Bedürfnisse bzw. werden Lücken und Mängel der aktuellen Version der IVS-Rahmenarchitektur erkennbar, was wiederum durch ein entsprechendes Feedback in den IVS-Rahmenarchitektur Prozess eingebracht wird und damit die Weiterentwicklung der IVS-Rahmenarchitektur vorantreibt.

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

  • Wie passt sich die IVS-Rahmenarchitektur an neue Anforderungen an?
  • Wie reagiert die IVS-Rahmenarchitektur auf die Entdeckung von Fehlern?

Aufgaben des IVS-Rahmenarchitektur Prozesses

Die grundsätzlichen Aufgaben des IVS-Rahmenarchitektur Prozesses unterteilen sich in die Bereiche

  • Pflege der IVS-Rahmenarchitektur,
  • Anwenderunterstützung Öffentlichkeitsarbeit sowie *Selbstverwaltung des Prozesses.

Die Arbeiten zur Pflege der IVS-Rahmenarchitektur erfordern IVS-Architektur-Kompetenz und können u. U. nur von Experten (BASt, (außer)universitäre Einrichtungen, beratende Unternehmen, Hersteller und Betrieber von IVS-Diensten) übernommen werden. Sie umfassen im Wesentlichen folgende Teilbereiche:

  • Pflege und Erweiterung der Basiskonzepte Pflege und
  • Erweiterung der IVS-Architekturbausteine Pflege und
  • Erweiterung des TOGAF-basierten Vorgehensmodells *evtl. weitere...

Für die Pflege der IVS-Rahmenarchitektur müssen transparente und offene Prozedere definiert werden. Diese umfassen beispielsweise die Behebung identifizierter Fehler sowie die Weiterentwicklung der IVS-Rahmenarchitektur auf Basis eingereichter Erweiterungsanträge, die ggf. in Abhängigkeit des Schweregrades bzw. nach einer definierten Prioritätenliste von Experten (IVS-Architektur-Spezialisten) zeitnah behandelt werden.

Die Ergebnisse des Pflegeprozesses werden in die IVS-Rahmenarchitektur eingearbeitet und im IVS-Wiki veröffentlicht. Neben den vorherigen Aspekten, die mit der Pflege der IVS-Rahmenarchitektur zu assoziieren sind, haben die nachstehenden Aufgaben einen unterstützenden Charakter und sollten vom Aufwand her nicht unterschätzt werden.

Anwendersupport

Vor allem sei hier der Anwendersupport genannt. Er gliedert sich in eine Reihe von unterschiedlichen Leistungen, wie z.B. die Bereitstellung IVS-Rahmenarchitektur und von weiterführenden, unterstützenden Dokumentationen (z.B. IVS-Referenzarchitekturen). Letztere können sich aus Tutorials, Guidelines, Webinars, etc. zusammensetzen.

Für eine Kollaboration von Entwicklern der IVS-Rahmenarchitektur und Firmen, die ihre Produktpalette konform zur IVS-Rahmenarchitektur entwickeln und in ihren Systemlandschaften einsetzen, können als Werkzeuge oder Kommunikationsplattformen internetbasierte Foren 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.

Issue-Tracking

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 der IVS-Rahmenarchitektur zu unterstützten. Im Projekt IVS-Rahmenarchitektur wurde dazu mit der Internetplattform www.......org der Grundstein gelegt. Dort finden sich alle Informationen rund um die IVS-Rahmenarchitektur. Es ist aber nicht nur ein Informationszentrum, sondern auch ein Werkzeug für den IVS-Rahmenarchitektur Prozess.

Über das Portal sind nicht nur viele Informationen (Spezifikationen, Erweiterungen, IVS-Referenzimplementierung, u.v.m.) erhältlich. Es ist auch erforderlich, ein Issue-Tracker-Modul zu integrieren. Dieses bietet eine Feedback-Möglichkeit für Nutzer der IVS-Rahmenarchitektur (Fehlerreports, Anforderungen an IVS-Rahmenarchitektur, usw.).

Die folgende Abbildung zeigt das IVS-Wiki Portal:

Das IVS-Wiki Portal

Öffentlichkeitsarbeit

Zu den beschriebenen Aufgaben der Pflege der IVS-Rahmenarchitektur bedarf es zudem einer regen Öffentlichkeitsarbeit, um einerseits die Ergebnisse der Archtekturarbeit 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 IVS-Rahmenarchitektur wurde z.B. recht früh mit der Öffentlichkeitsarbeit begonnen, um die interessierten Kreise so früh, wie möglich, einzubeziehen. Zu den insgesamt zwei Veranstaltungen wurde ein breites Fachpublikum eingeladen. Auf den Veranstaltungen 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 IVS-Rahmenarchitektur Prozesses zu binden.

Sekretariat

Letztendlich sollten auch Ressourcen für die Verwaltung des IVS-Rahmenarchitektur Prozesses eingeplant werden, die die Koordinierung der Prozessabläufe, verwaltungstechnische Unterstützung der Gremien des IVS-Rahmenarchitektur 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 IVS-Rahmenarchitektur 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 Entwicklern und Anwendern der IVS-Rahmenarchitektur steigen.

Organisation des IVS-Rahmenarchitektur Prozesses

Überblick

Um den IVS-Rahmenarchitektur 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 IVS-Rahmenarchitektur Prozesses orientiert sich dabei an bereits bestehende erfolgreiche Organisationen. Die nachstehende Grafik gibt einen Überblick über die Ausgestaltung der Organisation. Sie wird im Folgenden weiter erläutert.

Organisation des IVS-Rahmenarchitektur Prozesses

Stakeholder

Wie zuvor beschrieben, wird empfohlen, dass der IVS-Rahmenarchitektur 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 Interessenvertretung
Öffentliche Hand BASt, Experten der Länder und Kommunen 
Consultants
Hersteller
Standardisierungsorganisationen
Verbände
Sonstige

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

Organe des IVS-Rahmenarchitektur Prozesses und ihre Funktion

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

Das Lenkungskomittee

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 Vertretern der vorrangigen Interessengruppen zu gleichen Teilen, ergänzt um sonstige Interessenten. Die Mitglieder werden aus den jeweiligen Interessenvertretungen heraus gewählt bzw. mandatiert und besitzen pro Teilnehmer im LK eine Stimme im Rahmen der Entscheidungsfindung. Existieren auf einer Seite mehrere Interessenvertretungen sind die Stimmen anteilig aufzuteilen. Die Mitarbeit sonstiger Interessenten im LK geschieht auf freiwilliger Basis und hat beratenden bzw. unterstützenden Charakter. Im Gegensatz zu Vertretern der vorrangigen Interessengruppen besitzen die sonstigen Interessenten kein Stimmrecht.

Im jährlichen Rhythmus liefert das LK einen Bericht über seine bisherigen Arbeiten im Rahmen des IVS-Rahmenarchitektur Prozesses an die vertretenen Interessengruppen. 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

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 IVS-RAhemnarchtektur 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 Arbeiten 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.

Entscheidungsfindung

Das Entscheidungsorgan im IVS-Rahmenarchitektur Prozess ist das Lenkungskomitee (LK). Es orientiert sich bei der Entscheidungsfindung prinzipiell am Leitbild des IVS-Rahmenarchitektur Prozesses. 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 der IVS-Rahmenarchitektur 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 der IVS-Rahmenarchitektur erzielt ist, wird der AAS die Information über die angenommenen Änderungen auf der Website einstellen.

Finanzierung des IVS-Rahmenarchitektur Prozesses

Letztendlich stellt sich nun die Frage, wer die oben dargestellten Aufgaben übernehmen soll/kann und wie dies finanziert werden kann. Würde niemand die Pflege IVS-Rahmenarchitektur übernehmen, würde sie verkümmern. Selbst wenn eine Finanzierung des Prozesses möglich wäre und auch eine ausreichende IVS-Architektur Kompetenz sichergestellt werden könnte, hätten die Anwender keine Sicherheit, ob IVS-Rahmenarchitektur (evtl. durch fehlende Akzeptanz) in Richtlinien und Produkten umgesetzt wird.

Es muss also 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, die als Anwender von diesem Prozess profitieren. Aber auch Hersteller haben ein Interesse daran, die Entwicklung voranzutreiben und den Nutzen, sich mit Vorsprung am Markt behaupten zu können.

Es wird empfohlen, dass der IVS-Rahmenarchitektur Prozess von den Interessengruppen 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 IVS-Architektur Kompetenz der Entwickler 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 Anwenderakzeptanz gegenüber dem Standardisierungsobjekt. Ist letzteres erreicht wird die Motivation und die Bereitschaft einer direkten Rückkopplung im IVS-Rahmenarchitektur Prozess (Feedback) durch die Anwender maximiert.

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-Rahmenarchitektur Prozess (nationaler Prozess) von einem Viertel dieser Kosten (75-100 T€) pro Jahr ausgehen.

Fazit

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

Jeder lebendige Standard, so auch die IVS-Rahmenarchitektur, braucht einen lebendigen Pflegeprozess. Da dieser Prozess nicht von den Standardisierungsinstitutionen CEN, DIN oder DKE betrieben wird, muss er von den Stakeholdern, wie Anwender der öffentlichen Hand, Herstellern und sonstige Interessenten, betrieben werden, die damit einen Nutzen verbinden. Dabei kann der Prozess nur für alle zufriedenstellende Ergebnisse liefern, wenn auch alle Stakeholder aktiv teilnehmen.

Die Akzeptanz der IVS-Rahmenarchitektur 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 IVS-Rahmenarchitektur Prozess gepflegten Standards einen übergeordneten Nutzen haben, sind auch die Träger übergeordneter 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 IVS-Rahmenarchitektur Prozesses zunächst schwierig zu sein, ist aber bei Prüfung aller Variablen durchführbar.