BEGRÜNDUNG
1.Politischer Hintergrund
Das steigende Straßenverkehrsaufkommen in der Europäischen Union bringt diverse Herausforderungen mit sich. Der Straßenverkehr ist für die meisten Emissionen von Treibhausgasen und Luftschadstoffen des Verkehrssektors insgesamt verantwortlich. Die Straßenverkehrssicherheit in der EU hat sich zwar in den letzten Jahrzehnten verbessert, doch hat sich dieser Trend in letzter Zeit verlangsamt, und es ist unwahrscheinlich, dass die EU ihr Ziel, die Zahl der Verkehrstoten zwischen 2010 und 2020 um 50 % zu senken, erreichen wird. Darüber hinaus entstehen durch überlastete Straßen enorme Kosten für die Wirtschaft der EU. Um diese Probleme anzugehen und zu verhindern, dass Menschen, Wirtschaft, Umwelt und Klima in Europa ernsthaft geschädigt werden, sind koordinierte Maßnahmen in mehreren Bereichen erforderlich.
Neue Technologien zur Verbesserung von Effizienz, Sicherheit und Umweltbilanz des Straßenverkehrs spielen eine wichtige Rolle im Hinblick auf das Erreichen der einschlägigen Ziele der Kommission. Ein sich neu entwickelnder Bereich ist jener der kooperativen intelligenten Verkehrssysteme (C-ITS), die die direkte Interaktion von Fahrzeugen miteinander und mit der umgebenden Straßeninfrastruktur ermöglichen. Im Straßenverkehr betrifft C-ITS in der Regel die Fahrzeug-Fahrzeug- (vehicle-to-vehicle, V2V), Fahrzeug-Infrastruktur- (vehicleto-infrastructure, V2I) und/oder Infrastruktur-Infrastruktur-Kommunikation (I2I) sowie die Kommunikation zwischen Fahrzeugen und Fußgängern oder Radfahrern (Verkehrsvernetzung („vehicle-to-everything“), V2X). Dadurch wird eine breite Palette von Informations- und Kooperationsdiensten ermöglicht.
Bei C-ITS handelt es sich um eine Kategorie von ITS-Diensten, die auf einem offenen Netz basiert, das vielseitige („many-to-many“) oder gleichberechtige („peer-to-peer“) Verbindungen zwischen den C-ITS-Stationen ermöglicht. Dies bedeutet, dass alle C-ITS-Stationen im Sinne dieser Verordnung sicher untereinander kommunizieren können und nicht auf den Austausch von Nachrichten mit einer einzigen oder mehreren vorher festgelegten Stationen beschränkt sind. ITS-Dienste, die ähnliche Informationen z. B. über digitalen Rundfunk, Mobilfunknetze oder UKW-Funk bereitstellen, ohne jedoch die Merkmale eines offenen Netzes aufzuweisen, das vielseitige oder gleichberechtige Verbindungen zwischen den C-ITS-Stationen ermöglicht, fallen nicht in den Anwendungsbereich dieser Verordnung.
Die Vorteile von C-ITS erstrecken sich auf zahlreiche Bereiche, u. a. höhere Straßenverkehrssicherheit, weniger Staus, größere Verkehrseffizienz, Mobilität und Dienstzuverlässigkeit, geringere Energienutzung, weniger negative Auswirkungen auf die Umwelt und Unterstützung der wirtschaftlichen Entwicklung. Gleichzeitig ist darauf zu achten, dass mögliche negative Auswirkungen vermieden werden, z. B. eine erhöhte Verkehrsnachfrage aufgrund dieser Verbesserungen, eine Überflutung der Fahrer mit Informationen oder durch die zusätzliche gemeinsame Datennutzung entstehende größere Risiken für die Cybersicherheit oder den Schutz der Privatsphäre.
In den letzten zehn Jahren sind bemerkenswerte neue Entwicklungen bei den Technologien zu verzeichnen, die den Einsatz von CITS erleichtern. Trotz des potenziellen Nutzens haben diese jedoch noch nicht zu einer großmaßstäblichen Einführung geführt. Im Jahr 2011 veröffentlichten EU-Fahrzeughersteller des CAR2CAR Communication Consortium eine gemeinsame Absichtserklärung, in der sie ihre Absicht zur großmaßstäblichen Einführung bis 2015 bekundeten, da die Systeme bis dahin technologisch bereit wären. Es wurde jedoch deutlich, dass dies nur möglich wäre, wenn die wichtigsten Akteure einen gemeinsamen Ansatz, sowohl in Bezug auf technische als auch auf nicht technische Aspekte, verfolgen.
Die Kommission reagierte 2014 mit der Schaffung einer Plattform für die Einführung kooperativer intelligenter Verkehrssysteme in der EU (C-ITS-Plattform), einer Expertengruppe, in der nationale Behörden, C-ITS-Beteiligte und die Kommission zusammen an einer gemeinsamen Vision und konkreten Umsetzungslösungen für die interoperable Einführung von C-ITS in der EU arbeiten konnten. Die Ergebnisse der umfangreichen Arbeiten der Plattform und ihrer Arbeitsgruppen wurden in den Abschlussberichten für Phase I (2014-2016) und Phase II (20162017) zusammengefasst.
Über die C-ROADS-Plattform, eine gemeinsame Initiative der Mitgliedstaaten und der Straßenbetreiber zur Erprobung und Einführung von C-ITS-Diensten im Lichte der grenzübergreifenden Harmonisierung und Interoperabilität, sowie dank beträchtlicher Investitionen auf nationaler und EU-Ebene (199 Mio. EUR, davon 107 Mio. EUR aus der Fazilität „Connecting Europe“) haben 16 Mitgliedstaaten gemeinsam mit der Branche daran gearbeitet, die CITS-Dienste für V2I zu harmonisieren und interoperabel zu machen, sodass beispielsweise Hinweismeldungen über Straßenbauarbeiten in unterschiedlichen geografischen Umgebungen und von Fahrzeugen unterschiedlicher Hersteller einheitlich verstanden werden können. Dies war das Ergebnis der Zusammenarbeit zwischen der CROADS-Plattform und dem CAR2CAR Communication Consortium, durch die die Konsistenz bei den V2V- und V2I-Nachrichten und -Systemen verbessert wurde.
Im Jahr 2016 schlossen sich Automobil- und Telekommunikationsunternehmen in der 5G Automotive Association für Technologie für vernetzte und automatisierte Mobilität, einschließlich der C-ITS-Dienste, zusammen. Dies hat dazu geführt, dass für die Nahbereichskommunikation zwei Technologien existieren, die unterschiedlich ausgereift sind und vermarktet werden und die auf der Ebene des Funkzugangs nicht interoperabel sind.
Die Arbeit der C-ITS-Plattform leistete einen wesentlichen Beitrag im Rahmen der europäischen CITS-Strategie‚ die darauf abzielte, die EU-weite Abstimmung von Investitionen und Rechtsrahmen zu erleichtern, damit die Einführung so rasch wie möglich beginnen und insbesondere ausgereifte sicherheitsbezogene CITS-Dienste ab 2019 eingeführt werden könnten. In der Strategie wurde auf die Notwendigkeit hingewiesen, bis 2018 einen geeigneten Rechtsrahmen auf EU-Ebene zu schaffen, möglicherweise durch delegierte Rechtsakte im Rahmen der Richtlinie 2010/40/EU (die Richtlinie über intelligente Verkehrssysteme) oder durch andere Rechtsinstrumente.
Zweck dieser delegierten Verordnung zur Ergänzung der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates ist es, die Mindestanforderungen an die Interoperabilität von C-ITS festzulegen und die großmaßstäbliche Einführung von C-ITS-Systemen und -Diensten ab 2019 zu ermöglichen. Die Richtlinie 2010/40/EU (die ITS-Richtlinie) bietet einen politischen und rechtlichen Rahmen, um die Einführung innovativer Verkehrslösungen in ganz Europa zu beschleunigen. Durch die Richtlinie, deren Schwerpunkt auf intelligenten Verkehrssystemen für den Straßenverkehr und ihrer Schnittstelle zu anderen Verkehrsträgern liegt, wird die Kommission ermächtigt, delegierte Rechtsakte in vier vorrangigen Bereichen zu erlassen. Die Festlegung von Spezifikationen für C-ITS ist Teil des vorrangigen Bereichs IV der Richtlinie.
Der Schwerpunkt dieser delegierten Verordnung liegt auf Diensten für den „Tag 1“, d. h. C-ITS-Diensten, die kurzfristig eingeführt werden und insbesondere zur Straßenverkehrssicherheit und zur Verkehrseffizienz beitragen sollen. Spezifikationen und Normen für interoperable vorrangige Dienste für den „Tag 1“ und eine gemeinsame Sicherheitslösung sind nun als Ergebnis der Zusammenarbeit zwischen einer großen Gruppe von Beteiligten aus der Industrie und den Behörden der Mitgliedstaaten verfügbar.
2.RECHTSGRUNDLAGE, SUBSIDIARITÄT UND VERHÄLTNISMÄẞIGKEIT
2.1.Rechtsgrundlage
Der vorliegende delegierte Rechtsakt ergänzt die Richtlinie 2010/40/EU gemäß deren Artikel 7. Eine Verordnung ist das am besten geeignete Rechtsinstrument, da sie keine nationalen Umsetzungsmaßnahmen erfordert und somit ein höheres Maß an Harmonisierung, einen geringeren Verwaltungsaufwand für die Mitgliedstaaten, mehr Rechtssicherheit für öffentliche und private Akteure und ein rasches Inkrafttreten sicherstellt.
2.2.Subsidiarität und Verhältnismäßigkeit
Nach dem Subsidiaritätsprinzip (Artikel 5 Absatz 3 EUVertrag) wird die Union nur tätig, sofern und soweit die angestrebten Ziele auf der Ebene der Mitgliedstaaten nicht ausreichend erreicht werden können und wegen ihres Umfangs oder ihrer Wirkungen besser auf EU-Ebene zu verwirklichen sind.
CITS-Dienste werden zwar bereits im Rahmen von Projekten in der gesamten EU erbracht und mehrere Mitgliedstaaten sowie viele Automobilhersteller haben erklärt, dass sie ihre großmaßstäbliche Einführung planen. Dennoch haben sich viele für einen Rechtsrahmen auf EU-Ebene ausgesprochen. Die Normungsarbeit der Branche im Rahmen der europäischen Normungsorganisationen trägt zur Interoperabilität bei, ist jedoch freiwillig und ermöglicht somit auch voneinander abweichende, nicht interoperable Formen der Umsetzung. Angesichts der vielen unterschiedlichen Beteiligten und starker Netzwerkeffekte kann kein Beteiligter allein eine interoperable Lösung einführen. Auch die Festlegung von Vorschriften auf nationaler Ebene würde wahrscheinlich die Erbringung kontinuierlicher C-ITS-Dienste im einheitlichen europäischen Verkehrsraum behindern.
Die Kompatibilität zwischen Infrastruktur- und Fahrzeuglösungen muss in der gesamten EU sichergestellt werden, um die Vorteile von C-ITS in vollem Umfang nutzen zu können. Darüber hinaus bedarf es eines stärker harmonisierten Ansatzes auf EU-Ebene, um durch die Einführung neuer Sicherheitstechnologien sowie einer kooperativen und automatisierten Mobilität in der EU wirksame Synergien zu gewährleisten. Ohne einen inklusiven und zukunftsfähigen EURahmen würde die Einführung wahrscheinlich fragmentiert und unkoordiniert von statten gehen, sodass die geografische Kontinuität der C-ITS-Dienste in der gesamten EU und an ihren Außengrenzen nicht gewährleistet wäre.
Die Einhaltung dieser delegierten Verordnung wäre nur dort obligatorisch, wo C-ITS-Dienste oder -Stationen eingesetzt werden. Zwar erfordern verbindliche EU-Spezifikationen, dass bestehende C-ITS-Stationen und neue technologische Lösungen an diese Spezifikationen angepasst werden, doch sind solche Spezifikationen von wesentlicher Bedeutung, um die EU-weite Interoperabilität der C-ITS-Dienste zu gewährleisten, und die geplante Überarbeitung ermöglicht Flexibilität bei der Entwicklung technologischer Lösungen. Eine Verordnung ist strenger als eine Leitlinie oder eine Empfehlung, doch fallen auch die erwarteten direkten und indirekten Vorteile proportional höher aus. In diesem Sinne ist dieser delegierte Rechtsakt verhältnismäßig.
Ein weiterer wichtiger Effekt dieser delegierten Verordnung besteht darin, dass Authentizität und Integrität der zwischen CITS-Stationen ausgetauschten Nachrichten gewährleistet werden. Dies dürfte es ermöglichen, die Vertrauenswürdigkeit solcher Informationen zu bewerten. Gleichzeitig sollten die Auswirkungen auf die Privatsphäre der Verkehrsteilnehmer so gering wie möglich gehalten werden. Dementsprechend hat die C-ITS-Plattform eine Sicherheitsarchitektur entwickelt, die durch eine Public-Key-Infrastruktur (PKI) unter Verwendung sich häufig ändernder Pseudonymzertifikate unterstützt wird. Die sich daraus ergebende gemeinsame Sicherheitsstrategie und Certificate Policy waren Gegenstand einer breit angelegten Konsultation und wurden von allen betroffenen Akteuren vereinbart.
2.3.Grundrechte
Das Recht auf den Schutz der personenbezogenen Daten wird in Artikel 8 der Charta der Grundrechte der Europäischen Union garantiert. Wenn die in dieser Verordnung vorgesehenen Maßnahmen mit der Verarbeitung personenbezogener Daten verbunden sind, müssen diese Maßnahmen in Übereinstimmung mit den EU-Rechtsvorschriften über den Schutz personenbezogener Daten, insbesondere der Datenschutz-Grundverordnung und der Datenschutzrichtlinie für elektronische Kommunikation, durchgeführt werden.
Am 10. Juli 2017 konsultierten die Dienststellen der Kommission im Rahmen ihrer Vorbereitungsarbeit die Untergruppe „Technologie“ der gemäß Artikel 29 der Datenschutzrichtlinie eingesetzten Arbeitsgruppe. In der Stellungnahme der Untergruppe (Oktober 2017) wurde auf eine Reihe von Maßnahmen hingewiesen, die erforderlich sind, um die rechtmäßige Verarbeitung personenbezogener Daten im Bereich C-ITS zu unterstützen. Ferner wurde klargestellt, dass diese Verordnung – da sie lediglich den Austausch von Nachrichten zwischen C-ITS-Stationen abdeckt – selbst keine Rechtsgrundlage für die rechtmäßige Verarbeitung von Daten schaffen kann. Folglich bleiben die Pflichten der für die Verarbeitung Verantwortlichen und der Datenverarbeiter in vollem Umfang anwendbar. In dieser Verordnung wird jedoch klargestellt, dass die erhobenen personenbezogenen Daten ohne eine angemessene und spezifische Rechtsgrundlage nicht zu kommerziellen Zwecken oder als neue Ressource für die Strafverfolgung (weiter)verwendet werden sollten. Die Verarbeitung von Informationen über eine identifizierte oder identifizierbare natürliche Person sollte zudem unter strenger Einhaltung des Grundsatzes der Datenminimierung erfolgen, ausschließlich den in dieser Verordnung genannten Zwecken dienen und die Informationen sollten nicht länger als notwendig gespeichert werden. Schließlich sollten die Endnutzer klar und umfassend über die Datenerhebung und die Zeiträume, für die sie aufbewahrt werden, informiert werden.
3.Ergebnisse der Ex-post-Bewertungen und Folgenabschätzungen
•
Ex-post-Bewertung/Eignungsprüfungen bestehender Rechtsvorschriften
Da es in diesem Bereich keine bestehenden Rechtsvorschriften gibt, muss keine Ex-post-Bewertung durchgeführt werden.
•
Einholung und Nutzung von Expertenwissen
Die Kommission stützte sich auf die Abschlussberichte für die Phasen I und II der C-ITS-Plattform. Außerdem hat die Kommission durch einen Vertrag über eine Begleitstudie für die Folgenabschätzung mit RICARDO Energy & Environment, mit Unterstützung von TRT und TEPR, die im September 2017 begonnen und im Dezember 2018 abgeschlossen wurde, externe Experten zu Rate gezogen.
•
Folgenabschätzung
Die Initiative wird durch eine Folgenabschätzung gestützt, zu der der Ausschuss für Regulierungskontrolle (RSB) am 10. Oktober 2018 eine positive Stellungnahme mit Vorbehalten abgab. Die Vorbehalte des RSB betrafen im Wesentlichen zwei Aspekte:
·Nach Ansicht des RSB wurde in dem Bericht nicht hinreichend deutlich, dass ein schrittweiser Ansatz erforderlich ist, um die Ziele der Initiative zu erreichen. Daher lässt sich die Wahl der bevorzugten Option nicht eindeutig aus der Analyse und Darstellung des Berichts ableiten.
·Der RSB kam ferner zu dem Schluss, dass in dem Bericht nicht erläutert wurde, warum die Bedenken der Interessenträger in Bezug auf die Sicherheit von verletzungsgefährdeten Verkehrsteilnehmern und die Umweltauswirkungen (noch) nicht berücksichtigt wurden.
In der abschließenden Folgenabschätzung wurden folgende Ergänzungen vorgenommen, um diesen Vorbehalten Rechnung zu tragen:
·Die Unterscheidung zwischen den verschiedenen Optionen und die zugrunde liegenden Überlegungen wurde in der gesamten Folgenabschätzung, insbesondere in den Abschnitten 5.3, 7 und 8, überprüft und präzisiert. Die Notwendigkeit einer gesonderten Folgenabschätzung für mögliche legislative Folgemaßnahmen, einschließlich eines V2V-Mandats, wird ausdrücklich erörtert.
·Die Auswirkungen von C-ITS auf verletzungsgefährdete Verkehrsteilnehmer wurden in den Abschnitten 6.1 und 6.5 weiter präzisiert. Es wurde betont, dass speziell auf verletzungsgefährdete Verkehrsteilnehmer bezogene C-ITS-Dienste noch nicht so ausgereift sind, dass sie in die Spezifikationen und damit in die Optionen, die Gegenstand dieser Folgenabschätzung sind, einbezogen werden können. Die Bedenken der Beteiligten wurden in Anhang 2 ausführlicher beschrieben.
·Im Hinblick auf die Auswirkungen wurde die Sensitivitätsanalyse in Abschnitt 6.5 auf alle Optionen ausgeweitet und im gesamten Bericht wurden Anpassungen vorgenommen, um besser zwischen den Optionen differenzieren zu können. Anhang 4 Abschnitt 2 wurde aktualisiert, um der Tatsache Rechnung zu tragen, dass der Schwerpunkt der Dienste für den „Tag 1“ deutlich auf der Sicherheit liegt, und um die Grenzen der Analyse weiter zu präzisieren.
·Abschnitt 6.4 wurde hinzugefügt, um die Auswirkungen der verschiedenen Optionen auf den Datenschutz zu erörtern. Auch Anhang 6 wurde entsprechend aktualisiert.
In der Folgenabschätzung wurden drei allgemeine Optionen untersucht:
Option 1:
Geringfügige Intervention auf der Grundlage nichtlegislativer Maßnahmen, einschließlich unverbindlicher Leitlinien für die Interoperabilität der Dienste für den „Tag 1“, sichere Kommunikation, Datenschutz und Bewertung der Einhaltung der Vorschriften;
Option 2:
Moderate Intervention auf der Grundlage der Spezifikationen der ITS-Richtlinie. Dies würde der Option 1 vergleichbare Elemente umfassen, die jedoch durch eine delegierte Verordnung rechtsverbindlich wären. Dennoch würde es den Mitgliedstaaten und der Industrie weiterhin freistehen zu entscheiden, ob sie C-ITS einführen oder nicht;
Option 3: Massive Intervention auf der Grundlage eines Mandats für Fahrzeug-Fahrzeug-Dienste (V2V) und Einrichtung von Steuerungsgremien. Diese Option baut schrittweise auf den rechtlich verbindlichen Spezifikationen auf, indem sichergestellt wird, dass alle Neufahrzeuge mit C-ITS-Stationen ausgerüstet sind, wodurch die Einführungsquote drastisch erhöht und somit der Schwellenwert für eine effektive Dienstleistungserbringung (in Zusammenhang mit dem Netzeffekt) wesentlich schneller erreicht wird. Option 3 schließt zusätzliche Maßnahmen ein, die die Einführung von C-ITS unterstützen, und kann nicht allein durch einen delegierten Rechtsakt eingeführt werden:
·eine legislative Maßnahme kann eine Rechtsgrundlage für die rechtmäßige Verarbeitung personenbezogener Daten im Zusammenhang mit C-ITS bilden. Dies würde die Rechtssicherheit erhöhen und wahrscheinlich zur Bereitstellung von mehr C-ITS-Diensten führen; und
·durch die Zuweisung von Leitungsaufgaben an juristische Personen werden die Koordinierung und Überwachung der C-ITS-Einführung weiterhin gewährleistet und so sichergestellt, dass die Hindernisse für die Verbreitung von C-ITS so gering wie möglich gehalten werden.
Der bevorzugte Ansatz ist Option 3 – ein in der ITS-Richtlinie vorgesehener schrittweiser Ansatz – bei dem nach der Annahme der Spezifikationen eine gesonderte Initiative für die Einführung in Betracht gezogen wird, wobei Effizienz und Verhältnismäßigkeit eines Mandats auf der Grundlage der weiteren Entwicklung des C-ITS-Sektors weiter untersucht werden. Diese Option wird als sehr kohärent und wirksam angesehen, da sie den stärksten Rückgang von Unfällen, Staus und CO2-Emissionen bewirkt.
Folgende Auswirkungen werden erwartet:
·Die wichtigsten Vorteile sind die Verringerung der Zahl der Unfälle und der Kraftstoffkosten sowie die Verkürzung der Reisezeiten. Hinzu kommt eine leichte Verringerung der externen Kosten von CO2-Emissionen und Luftschadstoffen. Der geldwerte Nutzen beläuft sich für den Zeitraum 2020-2035 auf insgesamt 78,9 Mrd. EUR. Diese Zahl würde mit der Einführung eines V2V-Mandats auf 128,9 Mrd. EUR steigen.
·Die Hauptkosten betreffen die C-ITS-Ausrüstung in Fahrzeugen und straßenseitiger Infrastruktur. Die sonstigen Einhaltungs- und Verwaltungskosten werden bewertet, aber als geringfügig im Vergleich zu den Gesamtkosten betrachtet. Die bezifferten Kosten belaufen sich insgesamt auf 19,1 Mrd. EUR für den Zeitraum 2020-2035 bzw. 32,3 Mrd. EUR bei Einführung eines V2V-Mandats. Der erwartete Nutzen übersteigt somit die erwarteten Kosten erheblich.
·Zwar beziehen sich 90 % der Kosten auf die Ausrüstung der Fahrzeugflotten, doch werden die Kosten für die Ausrüstung der Infrastruktur weitgehend vom öffentlichen Sektor getragen. Dennoch würde es den Mitgliedstaaten und der Industrie weiterhin freistehen zu entscheiden, ob sie C-ITS einführen oder nicht.
4.ERGEBNISSE DER KONSULTATIONEN
4.1.Treffen mit den von den Mitgliedstaaten benannten Experten
Die Ausarbeitung von Vorschriften und Anforderungen auf EU-Ebene zur Unterstützung der Einführung von C-ITS-Systemen und -Diensten, insbesondere der Interoperabilität und Kontinuität EUweiter V2V- und V2I-Dienste, erfordert eine enge Zusammenarbeit zwischen den Interessenträgern (Hersteller, Diensteanbieter und zuständige Behörden). Die EU-Mitgliedstaaten und die EFTA-Länder wurden aufgefordert, Experten für die Teilnahme an 13 Sitzungen mit den Kommissionsdienststellen zwischen dem 23. Mai 2017 und dem 3. Oktober 2018 in Brüssel zu benennen, um am Verordnungsentwurf mitzuarbeiten. Außerdem wurden Experten des Europäischen Parlaments zur Teilnahme eingeladen, und die Kommission hielt eine Reihe bilateraler Treffen mit den Mitgliedstaaten ab.
4.2.Konsultation der Interessenträger
Im Rahmen der öffentlichen Konsultation, die vom 10. Oktober 2017 bis zum 12. Januar 2018 (13 Wochen) auf der Website der Kommission stattfand, gingen 139 Beiträge ein. Die öffentliche Konsultation basierte auf einem Fragebogen, in dem die Meinungen der Interessenträger zu den wichtigsten Bestandteilen der Folgenabschätzung untersucht wurden: das Hauptproblem, seine Ursachen, mögliche Maßnahmen und deren wahrscheinliche Auswirkungen sowie die Relevanz der Maßnahmen auf EUEbene.
Im Rahmen einer Begleitstudie wurden mehrere Fallstudien durchgeführt:
·neun zu C-ITS-Einführungsprojekten in der EU und
·drei für die C-ITS-Einführung in anderen Ländern (USA, Australien und Japan); dabei wurden zwischen Oktober 2017 und Februar 2018 auch Gespräche mit hochrangigen Vertretern geführt.
Alle Fallstudien konzentrierten sich auf die folgenden Aspekte der C-ITS-Einführung: Ziele, Fortschritt, Hindernisse, Datenerhebung und Kosten in dem betreffenden Bereich. In den EU-Fallstudien wurden auch Rückmeldungen zu der Problemstellung, den Maßnahmen und Optionen sowie zur Überwachung und Bewertung dieser politischen Initiative erbeten.
Am 9. Februar 2018 fand ein Workshop mit Interessenträgern statt, um spezifische Informationen/Daten, Meinungen von Experten und Interessenträgern einzuholen und Vorschläge zu machen. Der Workshop war mit 140 Teilnehmern gut besucht.
Am 6. September 2018 und am 29. Januar 2019 stellte die Kommission den Mitgliedern des Ausschusses für Verkehr und Fremdenverkehr die Ziele und den Anwendungsbereich der Verordnung vor.
Vom 11. Januar 2019 bis zum 8. Februar 2019 wurde über das Portal „Bessere Rechtsetzung“ eine öffentliche Konsultation zu dem Verordnungsentwurf durchgeführt, in deren Rahmen 100 Beiträge eingingen.
4.3.C-ITS-Kommunikationtechnologien
Ein besonders wichtiges Thema für C-ITS sind die Kommunikationstechnologien, die für den Austausch von Nachrichten zwischen den C-ITS-Stationen genutzt werden können. Dies hängt unmittelbar mit der Notwendigkeit zusammen, sicherzustellen, dass jeder in der Lage ist, mit allen zu sprechen (Interoperabilität), und dass jeder weiterhin in der Lage sein wird, mit allen zu sprechen (Kompatibilität).
Die Vorteile lassen sich maximieren, indem die sich aus verschiedenen, einander ergänzenden Technologien ergebenden Vorteile kombiniert werden. Beim Konzept der „hybriden Kommunikation“ werden zwei Arten von Technologien miteinander kombiniert:
·Technologien für die Nahbereichskommunikation, die in einem reservierten 5,9-GHz-Frequenzband arbeiten und für zeitkritische Dienste am relevantesten sind. ITS-G5 wurde eigens zu diesem Zweck entwickelt und ist nun ausgereift, getestet und wurde bereits eingeführt; und
·Technologien für die Fernbereichskommunikation, die die Abdeckung bestehender Netze ermöglichen und große Gebiete verbinden, wenn auch für weniger zeitkritische V2I-Dienste. Bei 3G/4G-Mobilfunk handelt es sich um ausgereifte Technologien, die in weiten Teilen der EU bereits eine gute Abdeckung bieten.
Die praktische Umsetzung des hybriden Kommunikationsansatzes in Verbindung mit der Notwendigkeit, die Interoperabilität und Kontinuität der Dienste sicherzustellen, macht bestimmte technologische Entscheidungen zwingend. So muss ein Mindestmaß an funktionalen und technischen Anforderungen für den interoperablen Austausch von Nachrichten zwischen C-ITS-Stationen erfüllt werden. Da dadurch weitere Innovationen nicht behindert werden sollten, stellt diese Verordnung sicher, dass künftige Technologien in das Konzept der „hybriden Kommunikation“ integriert werden können.
Eine Überprüfungsklausel wird die Integration mehrerer bereits vorhandener Technologien wie LTEV2X (eine mobilfunkbasierte Nahbereichskommunikationstechnologie) und 5G (eine Reihe von Technologien für Mobilfunknetze der nächsten Generation) erleichtern. Die Kommission wird mögliche Änderungen dieser delegierten Verordnung mit einer Expertengruppe auf offene und transparente Weise erörtern und sie regelmäßig über die Fortschritte und die möglichen nächsten Schritte unterrichten. Beteiligte, die bereits C-ITS-Stationen in Betrieb genommen haben, sollten in diesem Prozess nach Treu und Glauben im Einklang mit dem Wettbewerbsrecht der Union und dem nationalen Wettbewerbsrecht zusammenarbeiten, um gleiche Wettbewerbsbedingungen für die verschiedenen Technologien zu gewährleisten, ohne die Entwicklung neuer Technologien zu behindern. Im Interesse künftiger Weiterentwicklungen in diesem Bereich sollten diese Beteiligten ihre Produkte auch auf die Integration zukünftiger Technologien vorbereiten.
5.AUSWIRKUNGEN AUF DEN HAUSHALT
Diese Verordnung hat Auswirkungen auf den EU-Haushalt.
Um sicherzustellen, dass das C-ITS-Netz reibungslos funktioniert, müssen bestimmte Aufgaben von zentralen Teilnehmern wahrgenommen werden, bevor der gesamte Steuerungsrahmen festgelegt werden kann. Bis zur Einrichtung dieser Teilnehmer wird die Kommission einige der Aufgaben übernehmen, vor allem diejenigen, die das System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU (EU C-ITS security credential management system), den CITS-Rahmen der EU für die Bereitstellung vertrauenswürdiger und sicherer Kommunikation auf der Grundlage einer PKI, betreffen.
Es muss unbedingt sichergestellt werden, dass C-ITS-Stationen im System für das Management von Sicherheitsberechtigungsnachweisen angemeldet werden, bevor sie in Betrieb genommen werden. Zu diesem Zweck wird die Kommission als gemeinsame Aufgabe der JRC und der GD MOVE die Aufgaben der zentralen Kontaktstelle, des Trust List Managers (Manager der Liste vertrauenswürdiger Zertifikate) und der für die C-ITS Certificate Policy zuständigen Stelle übernehmen.
Dies hat keine Auswirkungen auf die Humanressourcen, da die JRC und die GD MOVE Personal bei Bedarf einsetzen oder umschichten werden. Außerdem profitiert die JRC von der Unterstützungmaßnahme „Sicherheitsarchitektur für vernetzte Infrastruktur und Fahrzeuge in Europa“ im Rahmen des Durchführungsbeschlusses C(2016) 1966 der Kommission‚ durch die 4 Mio. EUR für die Durchführung von Phase I des System für das Management von Sicherheitsberechtigungsnachweisen (2018–2021) zugewiesen werden. Sollten weitere Unterstützungsmaßnahmen erforderlich sein, könnten sie im Rahmen der Fazilität „Connecting Europe“ finanziert werden.
DELEGIERTE VERORDNUNG (EU) .../... DER KOMMISSION
vom 13.3.2019
zur Ergänzung der Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates im Hinblick auf die Einführung und den Betrieb kooperativer intelligenter Verkehrssysteme
(Text von Bedeutung für den EWR)
DIE EUROPÄISCHE KOMMISSION —
gestützt auf den Vertrag über die Arbeitsweise der Europäischen Union,
gestützt auf die Richtlinie 2010/40/EU des Europäischen Parlaments und des Rates vom 7. Juli 2010 zum Rahmen für die Einführung intelligenter Verkehrssysteme im Straßenverkehr und für deren Schnittstellen zu anderen Verkehrsträgern, insbesondere auf Artikel 6 Absatz 3 in Verbindung mit Artikel 7,
in Erwägung nachstehender Gründe:
(1)In Artikel 2 Absatz 1 der Richtlinie 2010/40/EU wird die Verbindung zwischen Fahrzeug und Verkehrsinfrastruktur als vorrangiger Bereich IV für die Ausarbeitung und Anwendung von Spezifikationen und Normen genannt. Dies betrifft unter anderem die Entwicklung und Implementierung kooperativer Systeme (Fahrzeug-Fahrzeug, Fahrzeug-Infrastruktur (wobei Nachrichten sowohl aus dem Fahrzeug als auch der Infrastruktur gesendet werden können) und Infrastruktur-Infrastruktur), wobei Folgendes zugrunde gelegt wird: die Erleichterung des Daten- oder Informationsaustauschs zwischen Fahrzeugen, zwischen Infrastrukturen sowie zwischen Fahrzeugen und Infrastruktur; die Verwendung eines standardisierten Nachrichtenformats für den Daten- oder Informationsaustausch zwischen Fahrzeugen und Infrastruktur und die Festlegung einer Kommunikationsinfrastruktur für jede Art des Daten- oder Informationsaustauschs zwischen Fahrzeugen, zwischen Infrastrukturen und zwischen Fahrzeugen und Infrastruktur.
(2)Kooperative intelligente Verkehrssysteme (C-ITS) nutzen Technologien, die es Straßenfahrzeugen ermöglichen, untereinander und mit straßenseitiger Infrastruktur einschließlich Lichtsignalanlagen zu kommunizieren. Bei C-ITS-Diensten handelt es sich um eine Kategorie von ITS-Diensten, die auf einem offenen Netz basieren, das vielseitige („many-to-many“) oder gleichberechtige („peer-to-peer“) Verbindungen zwischen den C-ITS-Stationen ermöglicht. Dies bedeutet, dass alle C-ITS-Stationen im Sinne dieser Verordnung sicher untereinander kommunizieren können und nicht auf den Austausch von Nachrichten mit einer oder mehreren vorher festgelegten Stationen beschränkt sind. Die C-ITS-Stationen benötigen keine zusätzlichen Anforderungen, wie z. B.: Verwendung derselben Software, ein Konto oder ein Vertragsverhältnis mit demselben Teilnehmer (z. B. mit demselben Fahrzeughersteller oder Diensteanbieter oder derselben Straßenverkehrsbehörde).
(3)In der europäischen CITS-Strategie wurde festgestellt, dass die Gefahr einer Fragmentierung des Binnenmarkts auf dem Gebiet von C-ITS besteht und Mindestanforderungen für die C-ITS-Dienste festgelegt werden müssen, um deren koordinierte und kohärente Einführung zu gewährleisten. In diesem Zusammenhang kündigte die Kommission ihre Absicht an, gegebenenfalls von ihrem Mandat gemäß der Richtlinie 2010/40/EU Gebrauch zu machen, um bis 2018 einen oder mehrere delegierte Rechtsakte zu erlassen, damit die Kompatibilität, Interoperabilität und Kontinuität der C-ITS-Dienste bei Einführung und Betrieb von unionsweiten CITS-Diensten auf der Grundlage vertrauenswürdiger und sicherer Kommunikation gewährleistet sind.
(4)Um alle Vorteile der C-ITS-Dienste für die Straßenverkehrssicherheit und die Verkehrseffizienz zu fördern und zu maximieren, sollten die Spezifikationen dieser Verordnung für das gesamte Straßenverkehrsnetz gelten. Dazu zählen auch die Schnittstellen zu anderen Verkehrsträgern, die für die Straßenverkehrssicherheit oder Verkehrseffizienz relevant sind, wie Bahnübergänge, Hafengebiete usw.
(5)Die in dieser Verordnung festgelegten Spezifikationen sollten für alle CITS-Dienste gelten, unbeschadet besonderer, in anderen Rechtsakten gemäß der Richtlinie 2010/40/EU, insbesondere den Delegierten Verordnungen (EU) Nr. 886/2013 und (EU) Nr. 962/2015 der Kommission, festgelegter Spezifikationen.
(6)In der Richtlinie (EU) 2016/1148 des Europäischen Parlaments und des Rates vom 6. Juli 2016 über Maßnahmen zur Gewährleistung eines hohen gemeinsamen Sicherheitsniveaus von Netz- und Informationssystemen in der Union (die „NIS-Richtlinie“) werden Anforderungen an die nationalen Fähigkeiten im Bereich der Cybersicherheit festgelegt und Mechanismen zur Stärkung der strategischen und operativen Zusammenarbeit zwischen den Mitgliedstaaten sowie Verpflichtungen in Bezug auf Sicherheitsmaßnahmen und Meldung von Sicherheitsvorfällen in allen Sektoren eingeführt. Da in der NIS-Richtlinie die Betreiber intelligenter Verkehrssysteme gemäß Artikel 4 Absatz 1 der Richtlinie 2010/40/EU als potenzielle Betreiber wesentlicher Dienste aufgeführt sind, kann die Anwendung der NIS-Richtlinie und der Anforderungen, die sich aus der vorliegenden Verordnung ergeben, in bestimmten Fällen komplementär sein.
(7)Durch die Entscheidung 2008/671/EG der Kommission werden die Bedingungen für die Verfügbarkeit und effiziente Nutzung des Frequenzbands 58755905 MHz für sicherheitsbezogene ITS-Anwendungen in der Union harmonisiert.
(8)Aufgrund des Normungsauftrags M/453 haben die europäischen Normungsorganisationen – das Europäische Institut für Telekommunikationsnormen (ETSI) und das Europäische Komitee für Normung (CEN) – gemeinsame Normen für die Einführung von C-ITS-Diensten ausgearbeitet, auf die in dieser Verordnung Bezug genommen wird. Diese Normen bilden die Grundlage für die wirksame Erbringung vorrangiger C-ITS-Dienste, die es den Verkehrsleitstellen ermöglichen, geeignete Maßnahmen zu ergreifen, und die Voraussetzungen für eine sicherere Automatisierung auf den Straßen der EU bereiten. Die Normungsarbeiten werden – unter anderem zur Integration anderer Technologien und zur weiteren Stärkung von C-ITS – fortgesetzt. Die einschlägigen Normungsgremien und alle Beteiligten sollten daher die Arbeiten im Rahmen des Normungsauftrags M/453 fortsetzen und gemeinsam Lösungen entwickeln, die die Interoperabilität fördern und ermöglichen, dass alle Technologien ihren Beitrag leisten.
(9)Um die Interoperabilität zu gewährleisten, ist für jede C-ITS-Station eine spezifische Konfiguration von Normen („Systemprofil“) erforderlich, die die Umsetzung verschiedener fakultativer Normen bestimmt. Das Systemprofil beschreibt, welche externen Schnittstellen, für die Kommunikation zwischen den CITS-Stationen benötigt werden. Alle C-ITS-Stationen müssen den Anforderungen der Richtlinie 2014/53/EU des Europäischen Parlaments und des Rates genügen. Die Zusammenarbeit zwischen der Industrie und den Behörden der Mitgliedstaaten hat zur Entwicklung harmonisierter Systemprofile für die Kommunikation fahrzeugseitiger und straßenseitiger C-ITS-Stationen im 58555925-MHz-Frequenzband geführt. Wenn alle C-ITS-Dienste unionsweit nahtlos empfangen werden sollen, ist ein Konzept der „hybriden Kommunikation“ erforderlich, d. h. ein Konzept, bei dem einander ergänzende Kommunikationstechnologien kombiniert werden. Angesichts des Tempos des technologischen Fortschritts werden die Industrie und die Mitgliedstaaten dazu angehalten, zusätzliche ergänzende und kompatible Systemprofile für andere Arten von C-ITS-Stationen und Technologien zu entwickeln und unionsweit zu harmonisieren. Bevor sie solche neuen Profile oder Technologien nutzen, sollten sie die Kommission davon unterrichten, damit unverzüglich eine Aktualisierung dieser Verordnung in Betracht gezogen werden kann. Solche Aktualisierungen sollten in enger Zusammenarbeit mit den Mitgliedstaaten vorbereitet werden.
(10)Aufgrund des kooperativen Charakters von C-ITS muss jede C-ITS-Station Informationen an das C-ITS-Netz weitergeben. Die C-ITS-Stationen sollten weder die Erbringung der vorrangigen C-ITS-Dienste, die europäischen elektronischen Mautdienste oder den intelligenten Fahrtenschreiber noch das Funktionieren anderer C-ITS-Stationen beeinträchtigen.
(11)Es ist wichtig, dass Industrie und Mitgliedstaaten gemeinsame technische Lösungen für die Erbringung der C-ITS-Dienste einführen. Diese sollten insbesondere über die europäischen Normungsorganisationen entwickelt werden, um die Einführung von C-ITS-Diensten zu erleichtern, die Interoperabilität und Kontinuität der Dienste in der gesamten Union zu gewährleisten und die Implementierungskosten zu senken. Um die Kompatibilität, Interoperabilität und Kontinuität der unionsweiten C-ITS-Dienste zu gewährleisten, sollten die in dieser Verordnung genannten Normen und Systemprofile gegebenenfalls als Bezugspunkt für die Entwicklung künftiger C-ITS-Technologien und -Dienste verwendet werden.
(12)Die Einführung von C-ITS-Diensten, die zur Straßenverkehrssicherheit und Verkehrseffizienz beitragen, sollte Vorrang haben. Dienste, die ein Mindestniveau allgemeiner für die Straßenverkehrssicherheit relevanter Verkehrsinformationen gemäß der Definition in der Delegierten Verordnung (EU) Nr. 886/2013 bieten, sollten möglichst unentgeltlich als Universaldienst für die Endnutzer am Ort der Nutzung gemäß der genannten Verordnung bereitgestellt werden.
(13)Zur Gewährleistung der Interoperabilität erfordert jeder C-ITS-Dienst eine spezifische Konfiguration von Normen, die als Dienstprofil bezeichnet wird und die Implementierung der verschiedenen Normungsoptionen regelt. Die C-ITS-Dienste sollten die Erbringung der vorrangigen C-ITS-Dienste nicht beeinträchtigen. Die derzeitigen Fahrzeug-Fahrzeug-Dienstprofile wurden in erster Linie für Personenkraftwagen entwickelt. Um die Bereitstellung dieser oder ähnlicher Dienste für andere Fahrzeugkategorien zu ermöglichen, könnte die Entwicklung zusätzlicher Dienstprofile oder eine Aktualisierung der Dienstprofile in dieser Verordnung erforderlich sein.
(14)Im Beschluss Nr. 768/2008/EG des Europäischen Parlaments und des Rates werden gemeinsame Grundsätze und Musterbestimmungen, die in allen sektorspezifischen Rechtsvorschriften angewendet werden sollen, festgelegt. Er bildet somit einen allgemeinen horizontalen Rahmen für alle neuen Rechtsvorschriften zur Harmonisierung der Bedingungen für die Vermarktung von Produkten. Seine Musterbestimmungen enthalten Begriffsbestimmungen und allgemeine Verpflichtungen für die Wirtschaftsakteure und ein breites Spektrum von Konformitätsbewertungsverfahren, aus denen der Gesetzgeber das am besten geeignete auswählen kann. Um die Sicherheit des Marktes zu gewährleisten, enthält er auch Vorschriften für die CE-Kennzeichnung und Musterbestimmungen für Verfahren, die im Fall gefährlicher Produkte zu befolgen sind. Da diese Verordnung das Inverkehrbringen von C-ITS-Stationen regelt, ist es angebracht, auf die in Anhang I des Beschlusses genannten Musterbestimmungen zurückzugreifen, nach denen der Hersteller unter anderem dafür verantwortlich ist, dass alle geltenden Rechtsvorschriften eingehalten werden; dass eine EU-Konformitätserklärung ausgestellt wird; dass die Konformitätskennzeichnung angebracht ist und dass geeignete technische Unterlagen erstellt werden. Die Aufgaben und Zuständigkeiten anderer Teilnehmer wie des Bevollmächtigten, des Einführers und des Händlers sollten ebenfalls geregelt werden.
(15)In dieser Verordnung gelten in Fahrzeuge eingebaute, tragbare oder entlang der Straßeninfrastruktur angebrachte CITS-Stationen als Produkte, die als eigenständige Baugruppen oder als Teile größerer Baugruppen in Verkehr gebracht werden können. Inwieweit die in Fahrzeuge einzubauenden C-ITS-Stationen den geltenden Anforderungen entsprechen, kann vor oder nach dem Einbau geprüft werden. Bei straßenseitigen C-ITS-Stationen kann dies vor der Installation geprüft werden, sodass sie als eigenständige Produkte in Verkehr gebracht werden können. Bei zentralen C-ITS-Stationen kann die Lage anders sein, da sie häufig in Verkehrsleitstellen integriert werden, die nicht standardisiert sind. Da diese Verkehrsleitstellen nach und nach entsprechend der Entwicklung der von ihnen verwalteten Verkehrsgebiete eingerichtet werden, kann es sein, dass die C-ITS-Stationen nicht vollständig geprüft werden können, bevor sie in Verkehr gebracht werden. In jedem Fall sollte für alle, auch die zentralen C-ITS-Stationen, dasselbe Sicherheits- und Vertrauensniveau gelten.
(16)Bevor eine C-ITS-Station in Betrieb genommen wird, muss festgelegt werden, welcher Teilnehmer überprüft, ob ihr eine EU-Konformitätserklärung beigefügt und gegebenenfalls die Konformitätskennzeichnung angebracht ist. Dieser Teilnehmer sollte die Station im System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU registrieren und sicherstellen, dass sie während der gesamten Nutzungsdauer weiterhin die technischen Anforderungen erfüllt. Bei dem Teilnehmer wird es sich um den Betreiber der C-ITS-Station handeln und er wird für die Beziehungen zum Nutzer verantwortlich sein.
(17)Für viele C-ITS-Dienste ist es von wesentlicher Bedeutung, dass Authentizität und Integrität der C-ITS-Nachrichten, die Informationen wie Position, Geschwindigkeit und Richtung enthalten, sichergestellt sind. Aus diesem Grund sollte, unabhängig von der verwendeten Kommunikationstechnik, für alle C-ITS-Stationen (alle mobilen C-ITS-Stationen, wobei für fahrzeugseitige und persönliche C-ITS-Stationen dieselben Anforderungen gelten, und alle ortsfesten C-ITS-Stationen, wobei für zentrale und straßenseitige C-ITS-Stationen dieselben Anforderungen gelten), ein gemeinsames europäisches C-ITS Trust Model (Vertrauensmodell) geschaffen werden. Die Regeln und Anforderungen dieses Trust Models sind in der Certificate Policy und Sicherheitsstrategie festgelegt. Die höchste Ebene der Public Key Infrastructure (PKI) ist die European Certificate Trust List (europäische Liste vertrauenswürdiger Zertifikate), die Einträge aller vertrauenswürdigen Root Certification Authorities (Wurzelzertifizierungsstellen) in Europa enthält.
(18)In der Vergangenheit wurden einige Anstrengungen unternommen, um eine gegenseitige Anerkennung von Sicherheitszertifikaten für Produkte in Europa zu erreichen. Das wichtigste Beispiel hierfür ist die in der Gruppe hoher Beamter für die Sicherheit der Informationssysteme (SOG-IS) getroffene Vereinbarung über die gegenseitige Anerkennung (MRA). Obwohl die SOG-IS das wichtigste Modell für die Zusammenarbeit und gegenseitige Anerkennung im Bereich der Sicherheitszertifizierung ist, gehört ihr nur ein Teil der Mitgliedstaaten der Union an. Da die Sicherheitszertifizierung der C-ITS-Stationen ein wichtiger Bestandteil der Certificate Policy und Sicherheitsstrategie für C-ITS ist, wird die Vereinbarung über die gegenseitige Anerkennung (SOG-IS MRA) in Ermangelung anderer gleichwertiger europäischer Systeme für die Cybersicherheitszertifizierung im Rahmen des einschlägigen europäischen Rahmens für die Cybersicherheit angewandt.
(19)Bestimmte C-ITS-Stationen, die vor dem Datum der Anwendung dieser Verordnung in Verkehr gebracht wurden, erfüllen unter Umständen nicht in vollem Umfang die Anforderungen dieser Verordnung in Bezug auf die C-ITS-Sicherheit, da Entscheidungen über die Einführung der Technik möglicherweise bereits zu einem früheren Zeitpunkt getroffen wurden. Damit solche C-ITS-Stationen nach Beginn der Anwendung dieser Verordnung Teil des C-ITS-Netzes werden können, sollte ein Verfahren vorgesehen werden, mit dem geprüft wird, ob solche C-ITS-Stationen in das C-ITS Trust Model aufgenommen werden können.
(20)Gemäß Artikel 6 Absatz 6 der Richtlinie 2010/40/EU muss die Kommission Spezifikationen erlassen, die einer Reihe von Grundsätzen entsprechen, darunter die Nutzung satellitengestützter Infrastrukturen oder sonstiger Technologien, die einen vergleichbaren Präzisionsgrad für ITS-Anwendungen und -Dienste, die eine umfassende, kontinuierliche, genaue und garantierte Zeitgebung und Ortung erfordern. Daher ist es angezeigt, die Kompatibilität der C-ITS-Stationen mit den Mehrwertdiensten, die im Rahmen der Programme Galileo und EGNOS (Europäische Erweiterung des geostationären Navigationssystems) gemäß der Verordnung (EU) Nr. 1285/2013 des Europäischen Parlaments und des Rates erbracht werden, zu gewährleisten, um die Zuverlässigkeit der C-ITS-Stationen zu verbessern.
(21)Die Plattform für die Einführung von C-ITS in der Union (C-ITS-Plattform), die im November 2014 eingerichtet wurde und in der die Kommissionsdienststellen den Vorsitz führen, hat eine gemeinsame Sicherheitsstrategie und Certificate Policy entwickelt, die von allen Beteiligten gebilligt wurde. Da die gemeinsame Sicherheitsstrategie und Certificate Policy im Einklang mit dem technischen Fortschritt und der Weiterentwicklung des Steuerungsrahmens aktualisiert werden sollte, sollte die Kommission diese Verordnung laufend überarbeiten, um Kohärenz und Konsistenz zu wahren.
(22)Um sicherzustellen, dass das C-ITS-Netz reibungslos funktioniert, müssen bestimmte Aufgaben von zentralen Teilnehmern erfüllt werden, bevor der gesamte Steuerungsrahmen festgelegt werden kann. Bis zur Einrichtung der zentralen Teilnehmer sollte die Kommission für diese Aufgaben zuständig sein, einschließlich derjenigen, die von der für die C-ITS Certificate Policy zuständigen Stelle, vom Trust List Manager und von der C-ITS-Kontaktstelle wahrzunehmen sind.
(23)Wenn die in dieser Verordnung vorgesehenen Maßnahmen mit der Verarbeitung personenbezogener Daten verbunden sind, sollten diese Maßnahmen in Übereinstimmung mit den Rechtsvorschriften der Union über den Schutz personenbezogener Daten, insbesondere der Verordnung (EU) 2016/679 und gegebenenfalls der Richtlinie 2002/58/EG erfolgen. Diese Verarbeitung sollte eine geeignete Rechtsgrundlage nach Artikel 6 der Verordnung (EU) 2016/679 haben, was in der vorliegenden delegierten Verordnung nicht vorgesehen ist.
(24)Ohne eine geeignete Rechtsgrundlage sollten die erhobenen personenbezogenen Daten nicht für andere Zwecke, z. B. für gewerbliche Zwecke oder die Strafverfolgung, wiederverwendet werden, es sei denn auf der Grundlage eines Gesetzes.
(25)Die Verarbeitung von Informationen über eine identifizierte oder identifizierbare natürliche Person sollte unter strenger Einhaltung des Grundsatzes der Datenminimierung erfolgen, ausschließlich den in dieser Verordnung genannten Zwecken dienen und die Informationen sollten nicht länger als notwendig gespeichert werden. Die in dieser Verordnung vorgesehenen Sicherheitsanforderungen für die Pseudonymisierung tragen dazu bei, das Risiko des Datenmissbrauchs zu verringern.
(26)Die Endnutzer sollten klar und umfassend über alle einschlägigen Informationen über die Verarbeitung ihrer personenbezogenen Daten gemäß der Verordnung (EU) 2016/679 unterrichtet werden.
(27)Wie in der im Rahmen der C-ITS-Plattform entwickelten gemeinsamen Sicherheitsstrategie und Certificate Policy festgelegt, sind für die Steuerung Gremien in Form gemeinsamer Lenkungsausschüsse der Beteiligten, einschließlich der Kommission, der Mitgliedstaaten, der Infrastrukturbetreiber sowie der Hersteller und Betreiber von C-ITS-Stationen, erforderlich. Bis zur Einrichtung solcher Gremien sollte die Kommission mit Unterstützung einer Expertengruppe, in der alle relevanten Beteiligten vertreten sind, für die einschlägigen Aufgaben, einschließlich der Aufgaben im Zusammenhang mit der Leitung, der Aufsicht und der Stelle für die C-ITS Certificate Policy, zuständig sein. Dieser Expertengruppe sollten insbesondere Vertreter der Hersteller und Betreiber von C-ITS-Stationen im C-ITS-Netz sowie andere betroffene Akteure und die zuständigen Behörden der Mitgliedstaaten angehören.
(28)Der breit angelegte und inklusive Konsultationsprozess, der zur Entwicklung des Rahmens für die Sicherheitsstrategie und Steuerung sowie der Certificate Policy (mit Unterstützung aller relevanten öffentlichen und privaten Beteiligten) führte, sollte auch für die Aktualisierung dieser Verordnung im Einklang mit dem technischen Fortschritt und gegebenenfalls der Weiterentwicklung des Steuerungsrahmens gelten.
(29)Die Mitgliedstaaten und die Wurzelzertifizierungsstellen sollten der Kommission regelmäßig Informationen übermitteln, die sie in die Lage versetzen, die Durchführung dieser Verordnung zu überwachen.
(30)Wie bereits im aktualisierten Arbeitsprogramm der ITS-Richtlinie angekündigt, wird davon ausgegangen, dass diese Verordnung vor der Überprüfung ihrer Durchführung, die drei Jahre nach ihrem Inkrafttreten erfolgen sollte, geändert wird, um der raschen Entwicklung neuer Märkte, Technologien und Dienste Rechnung zu tragen.
Für eine solche Änderung kommt vor allem die Einbeziehung der bestehenden 3G/4G-Netze zur Erbringung der vorrangigen C-ITS-Dienste in Betracht. Darüber hinaus wurden Spezifikationen für LTE-V2X-Technologien im Rahmen des Partnerschaftsprojekts zur 3. Generation (3GPP) fertiggestellt, und die Prototyp-Implementierung wird derzeit validiert. Diese Technologien werden derzeit in europäische Normen und technische Spezifikationen sowohl für die vorrangigen C-ITS-Dienste als auch für neu entwickelte Dienste integriert. Auch die sich rasch weiterentwickelnden neuen Technologien wie 5G könnten die C-ITS-Dienste unterstützen.
Einige dieser Entwicklungen könnten zu einer oder mehreren Änderungen dieser Verordnung führen, sobald der Kommission ein Dossier mit technisch ausgereiften Spezifikationen übermittelt wird. Solche Änderungen sollten ein offenes und zukunftssicheres Konzept in Bezug auf Normen und Rechtsvorschriften gewährleisten. Die Kommission sollte sich mit einer Expertengruppe zu möglichen Änderungen dieser Verordnung auf offene und transparente Weise beraten und sie regelmäßig über die Fortschritte und die möglichen nächsten Schritte unterrichten. Um die Kontinuität der vorrangigen C-ITS-Dienste zu gewährleisten, sollten sie außerdem die Kompatibilität und Interoperabilität mit bestehenden C-ITS-Stationen, die bereits im Einklang mit dieser Verordnung in Betrieb genommen wurden, gewährleisten oder einen geeigneten Migrationspfad festlegen, wobei auch der Entwicklung des Marktes und der Technologien Rechnung zu tragen ist.
Die Kommission sollte das Dossier analysieren und es unverzüglich im Hinblick auf eine mögliche Änderung dieser Verordnung in der Expertengruppe erörtern, um zu prüfen, ob eine Änderung der bestehenden Anforderungen erforderlich ist. Beteiligte, die bereits C-ITS-Stationen in Betrieb genommen haben, sollten in diesem Prozess nach Treu und Glauben im Einklang mit dem Wettbewerbsrecht der Union und des nationalen Wettbewerbsrechts zusammenarbeiten, um gleiche Wettbewerbsbedingungen für die verschiedenen Technologien zu gewährleisten, ohne die Entwicklung neuer Technologien zu behindern. Im Interesse künftiger Weiterentwicklungen in diesem Bereich sollten diese Beteiligten ihre Produkte auch auf die Integration zukünftiger Technologien vorbereiten.
(31)Der Europäische Datenschutzbeauftragte wurde gemäß Artikel 28 Absatz 2 der Verordnung (EG) Nr. 45/2001 des Europäischen Parlaments und des Rates konsultiert und gab am … eine Stellungnahme ab ––
HAT FOLGENDE VERORDNUNG ERLASSEN:
Kapitel I
Allgemeine Bestimmungen
Artikel 1
Gegenstand und Geltungsbereich
1.In dieser Verordnung werden Spezifikationen festgelegt, die erforderlich sind, um die Kompatibilität, Interoperabilität und Kontinuität bei der Einführung und praktischen Anwendung unionsweiter CITS-Dienste auf der Grundlage einer vertrauenswürdigen und sicheren Kommunikation zu gewährleisten.
Es wird festgelegt, wie die Fahrzeug-Fahrzeug-, Fahrzeug-Infrastruktur- und InfrastrukturInfrastruktur-Kommunikation über C-ITS-Stationen erfolgen soll, und wie die C-ITS-Stationen in Verkehr gebracht und in Betrieb genommen werden, um die C-ITS-Dienste für die ITS-Nutzer bereitzustellen.
2.Diese Verordnung gilt für alle C-ITS-Stationen im Bereich des Straßenverkehrs und für ihre Schnittstellen zu anderen Verkehrsträgern.
3.Die Einführung von C-ITS-Stationen erfolgt gemäß Artikel 5 der Richtlinie 2010/40/EU. Die Mitgliedstaaten legen fest, welcher Teil ihrer Verkehrsinfrastruktur mit C-ITS-Stationen ausgerüstet wird.
Artikel 2
Begriffsbestimmungen
Für die Zwecke dieser Verordnung bezeichnet der Ausdruck:
(1)„kooperative intelligente Verkehrssysteme“ (cooperative intelligent transport systems) oder „C-ITS“ intelligente Verkehrssysteme, die es den ITS-Nutzern ermöglichen, durch den Austausch von gesicherten und vertrauenswürdigen Nachrichten unter Nutzung des System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU zusammenzuarbeiten;
(2)„C-ITS-Dienst“ (C-ITS service) einen ITS-Dienst, der durch CITS erbracht wird;
(3)„C-ITS-Station“ (C-ITS station) die Hardware- und Softwarekomponenten, die erforderlich sind, um gesicherte und vertrauenswürdige Nachrichten zu sammeln, zu speichern, zu verarbeiten, zu empfangen und zu übertragen, um die Bereitstellung eines C-ITS-Dienstes zu ermöglichen. Dies umfasst die in EN 302 665 v 1.1.1 definierten persönlichen, zentralen, fahrzeug- und straßenseitigen ITS-Stationen;
(4)„mobile C-ITS-Station“ (mobile C-ITS station) eine C-ITSStation, die in einem Fahrzeug eingebaut ist oder bei der es sich um ein persönliches tragbares Gerät handelt;
(5)„ortsfeste C-ITS-Station“ (fixed C-ITS station) eine in einem zentralen System oder in einer straßenseitigen Infrastruktur eingebaute C-ITS-Station;
(6)„zentrale C-ITS-Station“ (central C-ITS station) einen zentralen Server mit integrierten C-ITS-Stationsfähigkeiten wie z. B. in einem Verkehrsmanagementzentrum;
(7)„Bereitstellung auf dem Markt“ (making available on the market) die entgeltliche oder unentgeltliche Abgabe einer C-ITS-Station zum Vertrieb oder zur Verwendung auf dem Unionsmarkt im Rahmen einer gewerblichen Tätigkeit;
(8)„Inverkehrbringen“ (placing on the market) die erstmalige Bereitstellung einer C-ITS-Station auf dem Unionsmarkt;
(9)„Inbetriebnahme“ (putting in service) einer C-ITS-Station die erstmalige bestimmungsgemäße Verwendung in der Union;
(10)„Nahbereichskommunikation“ (shortrange communication) die Kommunikation im Frequenzband 58555925 MHz;
(11)„vorrangiger C-ITS-Dienst“ (C-ITS priority service) einen C-ITS-Dienst, der zur Straßenverkehrssicherheit oder Verkehrseffizienz beiträgt und in Anhang I aufgeführt ist;
(12)„Systemprofil“ (system profile) ein Mindestmaß an funktionalen und technischen Anforderungen für den interoperablen Austausch von Nachrichten zwischen C-ITS-Stationen;
(13)„Dienstprofil“ (service profile) eine Reihe funktionaler Spezifikationen für interoperable Nachrichten, die die Bereitstellung eines C-ITS-Dienstes ermöglichen;
(14)„globales Satellitennavigationssystem“ (Global Navigation Satellite System, GNSS) eine Infrastruktur, die aus einer Satellitenkonstellation und einem Netz von Bodenstationen besteht, die Nutzer, die über einen geeigneten Empfänger verfügen, mit genauen zeitlichen und Geolokalisierungsdaten versorgt;
(15)„Hersteller“ (manufacturer) jede natürliche oder juristische Person, die eine C-ITS-Station entwickelt und herstellt bzw. entwickeln oder herstellen lässt und die C-ITS-Station unter ihrem Namen oder ihrer Marke vermarktet;
(16)„Betreiber einer C-ITS-Station“ (C-ITS station operator) jede natürliche oder juristische Person, die für die Inbetriebnahme und den Betrieb von C-ITS-Stationen gemäß dieser Verordnung verantwortlich ist;
(17)„Bevollmächtigter“ (authorised representative) jede in der Union ansässige natürliche oder juristische Person, die von einem Hersteller schriftlich beauftragt wurde, in ihrem Namen bestimmte Aufgaben wahrzunehmen;
(18)„Einführer“ (importer) jede in der Union ansässige natürliche oder juristische Person, die eine C-ITS-Station aus einem Drittland auf dem Unionsmarkt in Verkehr bringt;
(19)„Händler“ (distributor) jede natürliche oder juristische Person in der Lieferkette, die eine C-ITS-Station auf dem Markt bereitstellt, mit Ausnahme des Herstellers oder des Einführers;
(20)„Wirtschaftsakteur“ (economic operator) einen Hersteller, einen Bevollmächtigten, einen Einführer oder einen Händler;
(21)„Rückruf“ (recall) jede Maßnahme, die auf Erwirkung der Rückgabe einer dem Endnutzer bereits bereitgestellten CITS-Station abzielt;
(22)„Rücknahme“ (withdrawal) jede Maßnahme, mit der verhindert werden soll, dass eine in der Lieferkette befindliche C-ITS-Station auf dem Markt bereitgestellt wird;
(23)„CE-Kennzeichnung“ (CE marking) eine Kennzeichnung, durch die der Hersteller erklärt, dass das Produkt den geltenden Anforderungen genügt, die in den Rechtsvorschriften der Union über ihre Anbringung festgelegt sind;
(24)„Endnutzer“ (end-user) eine natürliche oder juristische Person, die letztendlich eine C-ITS-Station nutzt oder nutzen soll;
(25)„Marktüberwachungsbehörde“ (market surveillance authority) eine Behörde eines Mitgliedstaats, die für die Durchführung der Marktüberwachung in dessen Hoheitsgebiet zuständig ist;
(26)„zuständige nationale Behörde“ (competent national authority) jede Behörde, die befugt ist, die Konformität einer C-ITS-Station mit den geltenden Rechtsvorschriften zu überprüfen;
(27)„System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU“ (EU C-ITS security credential management system) den C-ITS-Rahmen der Europäischen Union für die Bereitstellung vertrauenswürdiger und sicherer Kommunikation mittels einer Public-Key-Infrastruktur (PKI);
(28)„Enrollmentstelle“ (enrolment authority) den juristischen und/oder operativen Teilnehmer, der eine C-ITS-Station authentifiziert und ihr den Zugang zu C-ITS ermöglicht;
(29)„C-ITS-Netz“ (C-ITS network) alle C-ITS-Stationen, die in der Union in Betrieb sind.
Artikel 3
Bereitstellung auf dem Markt und/oder Inbetriebnahme
Eine C-ITS-Station darf nur auf dem Markt bereitgestellt und/oder in Betrieb genommen werden, wenn sie bei ordnungsgemäßer Wartung und bestimmungsgemäßer Verwendung mit dieser Verordnung konform ist.
Artikel 4
Freier Verkehr
Die Mitgliedstaaten dürfen die Bereitstellung auf dem Markt oder die Inbetriebnahme von C-ITS-Stationen, die dieser Verordnung entsprechen, in ihrem Hoheitsgebiet aus den von dieser Verordnung erfassten Gründen nicht untersagen, beschränken oder behindern.
Kapitel II
Technische Anforderungen
Artikel 5
Anforderungen an die C-ITS-Stationen
1.Die für die Nahbereichskommunikation konzipierten fahrzeugseitigen C-ITS-Stationen müssen die Anforderungen des Systemprofils gemäß Anhang II Abschnitt 2 erfüllen.
2.Die für die Nahbereichskommunikation konzipierten straßenseitigen C-ITS-Stationen müssen die Anforderungen des Systemprofils gemäß Anhang II Abschnitt 3 erfüllen.
3.Die C-ITS-Stationen übermitteln Nachrichten, die die Bereitstellung von mindestens einem der in Anhang I aufgeführten vorrangigen C-ITS-Dienste ermöglichen.
4.C-ITS-Stationen müssen kompatibel mit C-ITS-Stationen sein, die Nachrichten für die in Anhang I aufgeführten vorrangigen C-ITS-Dienste senden.
5.C-ITS-Stationen dürfen den Betrieb des europäischen elektronischen Mautdienstes gemäß der Richtlinie 2004/52/EG des Europäischen Parlaments und des Rates und der Entscheidung 2009/750/EG der Kommission sowie den Betrieb des intelligenten Fahrtenschreibers gemäß der Verordnung (EU) Nr. 165/2014 des Europäischen Parlaments und des Rates nicht beeinträchtigen.
6.C-ITS-Stationen müssen mit C-ITS-Stationen kompatibel sein, die den in Anhang II festgelegten C-ITS-Systemprofilen genügen.
7.Wenn die C-ITS-Dienste GNSS-gestützt arbeiten, müssen sie mit den durch die Systeme Galileo und EGNOS bereitgestellten Ortungs- und Zeitgebungsdiensten kompatibel sein. Darüber hinaus können C-ITS-Stationen mit anderen Satellitennavigationssystemen kompatibel sein.
Artikel 6
Anforderungen an die C-ITS-Dienste
1.Die in Anhang I aufgeführten vorrangigen C-ITS-Dienste müssen den Anforderungen des entsprechenden C-ITS-Dienstprofils genügen.
2.Jeder C-ITS-Dienst muss ohne Änderungen mit allen in Anhang I festgelegten Dienstprofilen arbeiten.
Kapitel III
Inverkehrbringen von C-ITS-Stationen
Artikel 7
Pflichten der Hersteller von C-ITS-Stationen
1.Die Hersteller gewährleisten, wenn sie C-ITS-Stationen in Verkehr bringen, dass diese gemäß den Anforderungen nach Artikel 5 entwickelt und hergestellt wurden.
2.Die Hersteller erstellen die technischen Unterlagen nach Anhang V Teil A und führen das Konformitätsbewertungsverfahren nach Anhang V Teil A durch oder lassen es durchführen.
3.Wurde durch das in Anhang V Teil A genannte Konformitätsbewertungsverfahren nachgewiesen, dass eine C-ITS-Station den geltenden Anforderungen genügt, stellen die Hersteller eine EU-Konformitätserklärung aus und bringen die CE-Kennzeichnung an.
4.Die Hersteller bewahren die in Anhang V Teil A genannten technischen Unterlagen und die EU-Konformitätserklärung zehn Jahre ab dem Inverkehrbringen der C-ITS-Station auf.
5.Die Hersteller gewährleisten durch geeignete Verfahren, dass bei Serienfertigung stets Konformität mit dieser Verordnung sichergestellt ist.
6.Zum Schutz der Gesundheit und Sicherheit der Verbraucher müssen die Hersteller, sofern dies angesichts der von den C-ITS-Stationen ausgehenden Risiken als angemessen erachtet wird,
(a)Stichproben der in Verkehr gebrachten C-ITS-Stationen nehmen;
(b)Prüfungen vornehmen und erforderlichenfalls ein Verzeichnis der Beschwerden, der nicht konformen C-ITS-Stationen und der Rückrufe von CITS-Stationen führen;
(c)die Händler über diese Überwachung auf dem Laufenden halten.
7.Die Hersteller gewährleisten, dass C-ITS-Stationen, die sie in Verkehr gebracht haben, eine Typen-, Chargen- oder Seriennummer oder ein anderes Kennzeichen zu ihrer Identifikation tragen.
8.Auf der C-ITS-Station oder, wenn dies nicht möglich ist, auf der Verpackung oder in einem Begleitdokument zur C-ITS-Station geben die Hersteller Folgendes an:
(a)ihren Namen;
(b)eingetragener Handelsname oder eingetragene Marke;
(c)Postanschrift einer zentralen Kontaktstelle, unter der sie erreichbar sind.
Die Kontaktdaten werden in einer für die Endnutzer und die Marktüberwachungsbehörden leicht verständlichen Sprache zur Verfügung gestellt.
9.Die Hersteller gewährleisten, dass der C-ITS-Station die Betriebsanleitung und die Sicherheitsinformationen beigefügt sind; sie werden gemäß der Entscheidung des betreffenden Mitgliedstaats in einer für Endnutzer leicht verständlichen Sprache zur Verfügung gestellt. Diese Betriebsanleitung und Sicherheitsinformationen sowie alle Kennzeichnungen müssen klar, verständlich und deutlich sein.
10.Hersteller, die der Auffassung sind, dass eine C-ITS-Station, die sie in Verkehr gebracht haben, nicht mit dieser Verordnung konform ist, ergreifen unverzüglich die erforderlichen Korrekturmaßnahmen, um die Konformität herzustellen oder sie gegebenenfalls vom Markt zu nehmen oder zurückzurufen. Ist mit der C-ITS-Station ein Risiko verbunden, so unterrichten die Hersteller unverzüglich die Marktüberwachungsbehörden der Mitgliedstaaten, in denen sie sie auf dem Markt bereitgestellt haben, und machen dabei ausführliche Angaben, insbesondere zur Nichtkonformität und zu den ergriffenen Korrekturmaßnahmen.
11.Die Hersteller stellen der zuständigen nationalen Behörde auf deren begründetes Verlangen alle Informationen und Unterlagen, die für den Nachweis der Konformität der C-ITS-Station erforderlich sind, in Papierform oder auf elektronischem Wege in einer für diese Behörde leicht verständlichen Sprache zur Verfügung. Sie kooperieren mit dieser Behörde auf deren Verlangen bei allen Maßnahmen zur Abwendung von Risiken, die mit C-ITS-Stationen verbunden sind, welche sie in Verkehr gebracht haben.
Artikel 8
Bevollmächtigte
1.Ein Hersteller kann schriftlich einen Bevollmächtigten benennen.
2.Bevollmächtigte nehmen die Aufgaben wahr, die in dem vom Hersteller erteilten Auftrag festgelegt sind. Der Auftrag gestattet dem Bevollmächtigten, mindestens folgende Aufgaben wahrzunehmen:
(a)Bereithalten der EU-Konformitätserklärung und der technischen Unterlagen für die nationalen Marktüberwachungsbehörden über einen Zeitraum von zehn Jahren nach Inverkehrbringen der C-ITS-Station;
(b)auf begründetes Verlangen einer zuständigen nationalen Behörde Aushändigung aller erforderlichen Informationen und Unterlagen für den Nachweis der Konformität der CITS-Station;
(c)auf deren Verlangen Kooperation mit den zuständigen nationalen Behörden bei allen Maßnahmen zur Abwendung der Risiken, die mit C-ITS-Stationen verbunden sind, die Gegenstand des dem Bevollmächtigten erteilten Auftrags sind.
Die Pflichten gemäß Artikel 7 Absatz 1 und die Pflicht zur Erstellung der technischen Unterlagen gemäß Artikel 7 Absatz 2 sind nicht Teil des Auftrags eines Bevollmächtigten.
Artikel 9
Pflichten der Einführer
1.Einführer bringen nur konforme C-ITS-Stationen in der Union in Verkehr.
2.Bevor sie eine C-ITS-Station in Verkehr bringen, gewährleisten die Einführer, dass
(a)der Hersteller das Konformitätsbewertungsverfahren nach Artikel 7 Absatz 2 durchgeführt hat;
(b)der Hersteller die technischen Unterlagen ausgearbeitet hat;
(c)die C-ITS-Station mit der CE-Kennzeichnung versehen ist;
(d)der Hersteller die Anforderungen nach Artikel 7 Absätze 7 und 8 erfüllt hat.
3.Ist ein Einführer der Auffassung, dass eine C-ITS-Station nicht den Anforderungen nach Artikel 5 genügt, darf er das Produkt nicht in Verkehr bringen, bevor dessen Konformität hergestellt ist. Ist mit der C-ITS-Station eine Gefahr verbunden, unterrichtet der Einführer den Hersteller und die Marktüberwachungsbehörden hiervon.
4.Auf der C-ITS-Station oder, wenn dies nicht möglich ist, auf der Verpackung oder in einem Begleitdokument zur C-ITS-Station geben die Einführer Folgendes an:
(a)ihren Namen;
(b)eingetragener Handelsname oder eingetragene Marke;
(c)die Anschrift, unter der sie erreichbar sind.
Die Kontaktdaten werden in einer für die Endnutzer und die zuständigen nationalen Behörden leicht verständlichen Sprache zur Verfügung gestellt.
5.Die Einführer gewährleisten, dass der C-ITS-Station die Betriebsanleitung und die Sicherheitsinformationen beigefügt sind; diese werden gemäß der Entscheidung des betreffenden Mitgliedstaats in einer für die Endnutzer leicht verständlichen Sprache zur Verfügung gestellt.
6.Die Einführer gewährleisten, dass die Lagerungs- oder Transportbedingungen der C-ITS-Station, solange diese sich in ihrer Verantwortung befindet, ihre Konformität mit den Anforderungen nach Artikel 5 nicht beeinträchtigen.
7.Zum Schutz der Gesundheit und Sicherheit der Verbraucher müssen die Einführer, sofern dies angesichts der von einer C-ITS-Station ausgehenden Risiken als angemessen erachtet wird,
(a)Stichprobenprüfungen der in Verkehr gebrachten C-ITS-Station durchführen;
(b)Beschwerden über nicht konforme C-ITS-Stationen und CITS-Rückrufe untersuchen und erforderlichenfalls ein Verzeichnis der Beschwerden führen;
(c)die Händler über diese Überwachung auf dem Laufenden halten.
8.Einführer, die der Auffassung sind, dass eine C-ITS-Station, die sie in Verkehr gebracht haben, nicht mit dieser Verordnung konform ist, ergreifen unverzüglich die erforderlichen Korrekturmaßnahmen, um die Konformität dieser C-ITS-Station herzustellen oder sie gegebenenfalls vom Markt zu nehmen oder zurückzurufen. Ist mit der C-ITS-Station ein Risiko verbunden, so unterrichten die Einführer unverzüglich die zuständigen nationalen Behörden der Mitgliedstaaten, in denen sie sie auf dem Markt bereitgestellt haben, und machen dabei ausführliche Angaben, insbesondere zur Nichtkonformität und zu den ergriffenen Korrekturmaßnahmen.
9.Die Einführer halten ab dem Inverkehrbringen der C-ITS-Station zehn Jahre lang ein Exemplar der EU-Konformitätserklärung für die Marktüberwachungsbehörden bereit und sorgen dafür, dass sie ihnen die technischen Unterlagen auf Verlangen vorlegen können.
10.Die Einführer stellen der zuständigen nationalen Behörde auf deren begründetes Verlangen alle Informationen und Unterlagen, die für den Nachweis der Konformität der C-ITS-Station erforderlich sind, in Papierform oder auf elektronischem Wege in einer für diese Behörde leicht verständlichen Sprache zur Verfügung. Sie kooperieren mit dieser Behörde auf deren Verlangen bei allen Maßnahmen zur Abwendung von Risiken, die mit C-ITS-Stationen verbunden sind, welche sie in Verkehr gebracht haben.
Artikel 10
Pflichten der Händler
1.Die Händler berücksichtigen die Anforderungen dieser Verordnung mit der gebührenden Sorgfalt, wenn sie eine C-ITS-Station auf dem Markt bereitstellen.
2.Bevor sie eine C-ITS-Station auf dem Markt bereitstellen, überprüfen die Händler, ob
(a)sie mit der CE-Kennzeichnung versehen ist;
(b)die Betriebsanleitung und Sicherheitsinformationen nach Artikel 7 Absatz 9 in einer für die Endnutzer in dem Mitgliedstaat, in dem sie auf dem Markt bereitgestellt werden soll, leicht verständlichen Sprache beigefügt sind;
(c)der Hersteller und der Einführer die Anforderungen nach Artikel 7 Absätze 7 und 8 sowie Artikel 9 Absatz 4 erfüllt haben.
3.Ist ein Händler der Auffassung, dass eine C-ITS-Station nicht mit Artikel 5 konform ist, darf er sie nicht auf dem Markt bereitstellen, bevor ihre Konformität hergestellt ist. Ist mit der C-ITS-Station eine Gefahr verbunden, unterrichtet der Händler den Hersteller oder den Einführer und die Marktüberwachungsbehörden hiervon.
4.Die Händler gewährleisten, dass die Lagerungs- oder Transportbedingungen der C-ITS-Station, solange diese sich eine in ihrer Verantwortung befindet, ihre Konformität mit den Anforderungen nach Artikel 5 nicht beeinträchtigen.
5.Händler, die der Auffassung sind, dass eine C-ITS-Station, die sie auf dem Markt bereitgestellt haben, nicht mit dieser Verordnung oder sonstigen einschlägigen Unionsvorschriften konform ist, ergreifen unverzüglich die erforderlichen Korrekturmaßnahmen, um die Konformität herzustellen oder sie gegebenenfalls vom Markt zu nehmen oder zurückzurufen. Ist mit der C-ITS-Station ein Risiko verbunden, so unterrichten die Händler unverzüglich die Marktüberwachungsbehörden der Mitgliedstaaten, in denen sie sie auf dem Markt bereitgestellt haben, und machen dabei ausführliche Angaben, insbesondere zur Nichtkonformität und zu den ergriffenen Korrekturmaßnahmen.
6.Auf begründetes Verlangen einer zuständigen nationalen Behörde stellen die Händler alle erforderlichen Informationen und Unterlagen für den Nachweis der Konformität der C-ITS-Station zur Verfügung. Sie kooperieren mit dieser Behörde auf deren Verlangen bei allen Maßnahmen zur Abwendung von Risiken, die mit C-ITS-Stationen verbunden sind, welche sie auf dem Markt bereitgestellt haben.
Artikel 11
Fälle, in denen die Pflichten des Herstellers auch für Einführer und Händler gelten
Wenn ein Einführer oder Händler eine C-ITS-Station unter seinem eigenen Namen oder seiner eigenen Marke in Verkehr bringt oder eine bereits in Verkehr gebrachte C-ITS-Station so verändert, dass die Konformität mit dieser Verordnung beeinträchtigt werden kann, so gilt er für die Zwecke dieser Verordnung als Hersteller und unterliegt den Pflichten des Herstellers nach Artikel 7.
Artikel 12
Identifizierung der Wirtschaftsakteure
Die Wirtschaftsakteure nennen den Marktüberwachungsbehörden auf Verlangen
(a)die Wirtschaftsakteure, von denen sie eine C-ITS-Station bezogen haben;
(b)die Wirtschaftsakteure, an die sie eine C-ITS-Station abgegeben haben.
Die Wirtschaftsakteure müssen die Informationen nach Absatz 1 über einen Zeitraum von 15 Jahren nach dem Bezug bzw. 15 Jahren nach der Abgabe der C-ITS-Station vorlegen können.
Artikel 13
EU-Konformitätserklärung
1.Die EU-Konformitätserklärung besagt, dass die Erfüllung der Anforderungen nach Artikel 5 nachgewiesen wurde.
2.Die EU-Konformitätserklärung ist nach dem Muster in Anhang V Teil B strukturiert, enthält die in Anhang V Teil A aufgeführten Elemente und wird auf dem neuesten Stand gehalten. Sie ist in die Sprache(n) zu übersetzen, die von dem Mitgliedstaat vorgeschrieben wird/werden, in dem die CITS-Station in Verkehr gebracht oder auf dem Markt bereitgestellt wird.
3.Mit der Ausstellung der EU-Konformitätserklärung übernimmt der Hersteller die Verantwortung dafür, dass die C-ITS-Station den Anforderungen dieser Verordnung genügt.
4.Unterliegt eine C-ITS-Station mehreren Rechtsvorschriften der Union, in denen jeweils eine EU-Konformitätserklärung vorgeschrieben ist, so wird eine einzige EU-Konformitätserklärung für sämtliche Unionsvorschriften ausgestellt. In dieser Erklärung werden die betreffenden Rechtsakte einschließlich ihrer Fundstelle im Amtsblatt angegeben.
Artikel 14
Allgemeine Grundsätze der CE-Kennzeichnung
Für die CE-Kennzeichnung gelten die allgemeinen Grundsätze nach Artikel 30 der Verordnung (EG) Nr. 765/2008 des Europäischen Parlaments und des Rates.
Artikel 15
Vorschriften und Bedingungen für die Anbringung der CE-Kennzeichnung
1.Die CE-Kennzeichnung wird gut sichtbar, leserlich und dauerhaft auf der C-ITS-Station oder ihrer Datenplakette angebracht.
2.Die CE-Kennzeichnung wird vor dem Inverkehrbringen der C-ITS-Station angebracht. Ihr kann ein Piktogramm oder ein anderes Zeichen folgen, das ein(e) besondere(s) Risiko oder Verwendung angibt.
Artikel 16
Überwachung des Unionsmarktes und Kontrolle der auf den Unionsmarkt gelangenden C-ITS-Stationen
Artikel 15 Absatz 3 sowie die Artikel 16 bis 29 der Verordnung (EG) Nr. 765/2008 gelten für C-ITS-Stationen.
Artikel 17
Verfahren zur Behandlung von C-ITS-Stationen, mit denen ein Risiko verbunden ist, auf nationaler Ebene
1.Sind die Marktüberwachungsbehörden eines Mitgliedstaats gemäß Artikel 20 der Verordnung (EG) Nr. 765/2008 tätig geworden oder haben sie Grund zu der Annahme, dass eine C-ITS-Station ein Risiko für die Gesundheit oder Sicherheit von Menschen oder die Straßenverkehrssicherheit und die Verkehrseffizienz darstellt, so beurteilen sie, ob die betreffende C-ITS-Station alle einschlägigen Anforderungen dieser Verordnung erfüllt. Die betreffenden Wirtschaftsakteure arbeiten bei Bedarf mit ihnen zusammen.
Gelangen die Marktüberwachungsbehörden im Verlauf dieser Beurteilung zu dem Ergebnis, dass die C-ITS-Station den Anforderungen dieser Verordnung nicht genügt, so fordern sie den betroffenen Wirtschaftsakteur unverzüglich auf, innerhalb einer der Art des Risikos angemessenen Frist entweder alle geeigneten Korrekturmaßnahmen zu treffen, um die Konformität der C-ITS-Station mit diesen Anforderungen herzustellen, oder sie vom Markt zu nehmen oder zurückzurufen.
Artikel 21 der Verordnung (EG) Nr. 765/2008 gilt für die in Unterabsatz 2 genannten Maßnahmen.
2.Sind die Marktüberwachungsbehörden der Auffassung, dass sich die Nichtkonformität nicht auf ihr Hoheitsgebiet beschränkt, so unterrichten sie unverzüglich die Kommission und die übrigen Mitgliedstaaten über die Ergebnisse der Beurteilung und die Maßnahmen, zu deren Ergreifen sie den Wirtschaftsakteur aufgefordert haben.
3.Der Wirtschaftsakteur gewährleistet, dass in der gesamten Union alle geeigneten Korrekturmaßnahmen in Bezug auf alle betroffenen C-ITS-Stationen getroffen werden, die er auf dem Unionsmarkt bereitgestellt hat.
4.Trifft der Wirtschaftsakteur innerhalb der in Absatz 1 Unterabsatz 2 genannten Frist keine angemessenen Korrekturmaßnahmen, so treffen die Marktüberwachungsbehörden alle geeigneten vorläufigen Maßnahmen, um die Bereitstellung der C-ITS-Station auf ihrem nationalen Markt zu untersagen oder einzuschränken oder um sie vom Markt zu nehmen oder zurückzurufen.
5.Die Marktüberwachungsbehörden unterrichten die Kommission und die übrigen Mitgliedstaaten unverzüglich über die vorläufigen Maßnahmen nach Absatz 4. Diese Informationen umfassen alle verfügbaren Angaben, unter anderem
(a)die zur Identifizierung der nichtkonformen C-ITS-Station erforderlichen Daten;
(b)den Ursprung der C-ITS-Station;
(c)das Risiko und die Art der mutmaßlichen Nichtkonformität der CITS-Station mit den Anforderungen dieser Verordnung;
(d)die Art und Dauer der vorläufigen Maßnahmen;
(e)die Argumente des Wirtschaftsteilnehmers.
6.Die Mitgliedstaaten außer jenem, der das Verfahren eingeleitet hat, unterrichten die Kommission und die übrigen Mitgliedstaaten unverzüglich über
(a)alle von ihnen getroffenen Maßnahmen;
(b)jede weitere ihnen vorliegende Information über die Nichtkonformität der betreffenden C-ITS-Station;
(c)ihre etwaigen Einwände gegen die vorläufigen Maßnahmen des Mitgliedstaats, der das Verfahren eingeleitet hat.
7.Haben die anderen Mitgliedstaaten oder die Kommission innerhalb von drei Monaten nach Erhalt der in Absatz 5 genannten Informationen keine Einwände gegen eine vorläufige Maßnahme eines Mitgliedstaats erhoben, gilt diese Maßnahme als gerechtfertigt. Wird die vorläufige Maßnahme als gerechtfertigt erachtet, so stellen die Mitgliedstaaten sicher, dass unverzüglich geeignete restriktive Maßnahmen hinsichtlich der betreffenden C-ITS-Station getroffen werden, wie etwa ihre Rücknahme vom Markt.
Artikel 18
Schutzklauselverfahren der Union
1.Wurden nach Abschluss des Verfahrens gemäß Artikel 17 Absätze 3 und 4 Einwände gegen eine Maßnahme eines Mitgliedstaats erhoben oder ist die Kommission der Auffassung, dass eine vorläufige Maßnahme nicht mit dem Unionsrecht vereinbar ist, so konsultiert die Kommission unverzüglich die Mitgliedstaaten und den/die betreffenden Wirtschaftsakteure und nimmt eine Beurteilung der vorläufigen Maßnahme vor. Anhand der Ergebnisse dieser Beurteilung entscheidet die Kommission, ob die vorläufige Maßnahme gerechtfertigt ist oder nicht.
Die Kommission richtet ihre Beschlüsse an alle Mitgliedstaaten und teilt sie dem betroffenen Wirtschaftsteilnehmer unverzüglich mit.
2.Wird die vorläufige Maßnahme durch Kommissionsbeschluss als gerechtfertigt erachtet, so ergreifen alle Mitgliedstaaten die erforderlichen Maßnahmen, um zu gewährleisten, dass die nicht konforme C-ITS-Station von ihrem Markt genommen wird, und unterrichten die Kommission darüber. Wird die vorläufige Maßnahme nicht als gerechtfertigt erachtet, muss der betreffende Mitgliedstaat sie zurücknehmen.
Artikel 19
Konforme C-ITS-Stationen, die ein Risiko für die Gesundheit und Sicherheit auf nationaler Ebene darstellen
1.Gelangen die Marktüberwachungsbehörden eines Mitgliedstaats nach einer Beurteilung nach Artikel 17 Absatz 1 zu dem Ergebnis, dass eine C-ITS-Station, obgleich sie mit dieser Verordnung konform ist, die Gesundheit oder Sicherheit von Menschen oder andere im öffentlichen Interesse schützenswerte Aspekte gefährdet, so fordern diese Behörden den betreffenden Wirtschaftsakteur auf, eine oder mehrere der folgenden, der Art des Risikos entsprechenden Korrekturmaßnahmen zu ergreifen:
(a)Ergreifen aller geeigneten Maßnahmen, um sicherzustellen, dass beim Inverkehrbringen der CITS-Station dieses Risiko nicht mehr besteht;
(b)Vommarktnahme der C-ITS-Station;
(c)Rückruf der C-ITS-Station.
Die Marktüberwachungsbehörden setzen eine angemessene, der Art des Risikos angemessene Frist, innerhalb deren der Wirtschaftsakteur die Maßnahmen nach Unterabsatz 1 ergreifen muss.
2.Der Wirtschaftsakteur gewährleistet, dass unionsweit die Korrekturmaßnahmen in Bezug auf alle betroffenen C-ITS-Stationen ergriffen werden, die er auf dem Unionsmarkt bereitgestellt hat.
3.Die Marktüberwachungsbehörden unterrichten die Kommission und die übrigen Mitgliedstaaten unverzüglich über die von ihnen angeordneten Korrekturmaßnahmen nach Absatz 1 sowie über alle verfügbaren Einzelheiten, einschließlich
(a)der zur Identifizierung der betreffenden C-ITS-Station erforderlichen Daten;
(b)des Ursprungs und der Lieferkette der C-ITS-Station;
(c)der Art des Risikos;
(d)der Art und Dauer der Korrekturmaßnahmen.
4.Die Kommission konsultiert unverzüglich die Mitgliedstaaten und die betreffenden Wirtschaftsakteure und beurteilt die von den Marktüberwachungsbehörden angeordneten Korrekturmaßnahmen. Anhand der Ergebnisse dieser Beurteilung beschließt die Kommission, ob die Maßnahmen gerechtfertigt sind oder nicht, und schlägt, falls erforderlich, geeignete Maßnahmen vor.
5.Die Kommission richtet ihre Beschlüsse an alle Mitgliedstaaten und teilt sie dem betroffenen Wirtschaftsteilnehmer unverzüglich mit.
Artikel 20
Formale Nichtkonformität
1.Unbeschadet des Artikels 17 fordert ein Mitgliedstaat den betreffenden Wirtschaftsakteur auf, die Nichtkonformität zu beenden‚ wenn er einen der folgenden Fälle feststellt:
(a)die CE-Kennzeichnung wurde unter Verstoß gegen Artikel 14 oder Artikel 15 angebracht;
(b)die CE-Kennzeichnung wurde nicht angebracht;
(c)die EU-Konformitätserklärung wurde nicht ausgestellt;
(d)die EU-Konformitätserklärung wurde nicht ordnungsgemäß ausgestellt;
(e)die technischen Unterlagen sind entweder nicht verfügbar oder nicht vollständig;
(f)die in Artikel 5 Absatz 6 oder Artikel 7 Absatz 3 genannten Angaben fehlen, sind falsch oder unvollständig;
(g)eine andere Verwaltungsanforderung nach Artikel 5 oder Artikel 7 ist nicht erfüllt.
2.Besteht die Nichtkonformität gemäß Absatz 1 weiter, so trifft der betroffene Mitgliedstaat alle geeigneten Maßnahmen, um die Bereitstellung der C-ITS-Station auf dem Markt zu beschränken oder zu untersagen oder um dafür zu sorgen, dass sie zurückgerufen oder vom Markt genommen wird.
Kapitel IV
Inbetriebnahme und Betrieb von C-ITS-Stationen
Artikel 21
Inbetriebnahme von zentralen C-ITS-Stationen
1.Vor der Inbetriebnahme zentraler C-ITS-Stationen gewährleistet der Betreiber der C-ITS-Station, dass diese gemäß den Anforderungen nach Artikel 5 entwickelt und hergestellt wurden. Zu diesem Zweck ergreift er eine der folgenden Maßnahmen:
(a)Kauf einer zentralen C-ITS-Station, die gemäß Kapitel III in Verkehr gebracht wurde. In diesem Fall finden die Absätze 2 und 3 keine Anwendung;
(b)Integration der Leistungsmerkmale der C-ITS-Station in eine Verkehrsleitstelle oder einen zentralen Server. In diesem Fall gelten die Absätze 2 und 3, während die Artikel 7 bis 20 keine Anwendung auf die zentrale C-ITS-Sation finden.
2.Die Betreiber von C-ITS-Stationen erstellen die erforderlichen technischen Unterlagen gemäß Anhang V Teil C und führen das in Anhang V Teil C genannte Konformitätsbewertungsverfahren durch. Wenn die Konformität einer zentralen C-ITS-Station mit den Anforderungen nach Artikel 5 durch dieses Verfahren nachgewiesen wurde, stellen die Betreiber von C-ITS-Stationen eine EU-Konformitätserklärung gemäß Anhang V Teil D aus.
3.Die Betreiber von C-ITS-Stationen bewahren die technischen Unterlagen und die EU-Konformitätserklärung so lange auf, wie die zentrale C-ITS-Station in Betrieb ist.
Artikel 22
Pflichten der Betreiber von C-ITS-Stationen
1.Die Betreiber von C-ITS-Stationen stellen sicher, dass alle C-ITS-Stationen gemäß dieser Verordnung in Betrieb genommen und betrieben werden.
2.Vor der Inbetriebnahme einer C-ITS-Station überprüft der Betreiber der C-ITS-Station, ob
(a)sie mit der CE-Kennzeichnung versehen ist;
(b)die technischen Unterlagen nach Artikel 7 verfügbar sind;
(c)die C-ITS-Station gemäß den Anforderungen in Anhang IV Abschnitt 1.6.2 zertifiziert ist.
Die Pflichten nach Unterabsatz 1 Buchstaben a und b gelten nicht für zentrale C-ITS-Stationen, die nach Artikel 21 Absatz 1 Buchstabe b in Betrieb genommen werden.
Des Weiteren muss der Betreiber einer C-ITS-Station die C-ITS-Station vor ihrer Inbetriebnahme nach Artikel 23 Absatz 3 im System für das Management von Sicherheitsberechtigungsnachweisen von CITS-Diensten in der EU anmelden.
3.Vor der Inbetriebnahme einer C-ITS-Station vereinbart der Betreiber der Station mit ihrem Eigentümer die Rechte und Pflichten in Bezug auf den Betrieb, die Wartung und die Aktualisierung der C-ITS-Station, auch in Bezug darauf, wie der Endnutzer informiert wird.
4.Ist eine C-ITS-Station im System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU angemeldet, wird sie zusammen mit der Identifizierung ihres Betreibers im Register der C-ITS-Stationen ihrer Enrollmentstelle registriert. Die C-ITS-Kontaktstelle führt ein Verzeichnis der Register der C-ITS-Stationen.
5.Der Betreiber der C-ITS-Station stellt sicher, dass die C-ITS-Station während ihrer Nutzung weiterhin den Anforderungen des Artikels 5 genügt, die zum Zeitpunkt der Inbetriebnahme gelten.
6.Soll eine C-ITS-Station entweder auf Initiative ihres Betreibers oder gemäß einer Änderung dieser Verordnung nachgerüstet werden, gewährleistet der Betreiber, dass die C-ITS-Station der neuesten Fassung der einschlägigen Spezifikationen nach Artikel 5 genügt.
7.Soll eine C-ITS-Station auf Initiative ihres Betreibers oder seines Bevollmächtigten nachgerüstet werden, gewährleisten der Hersteller oder sein Bevollmächtigter und der Betreiber der C-ITS-Station, dass die C-ITS-Station der neuesten Fassung der einschlägigen Spezifikationen nach Artikel 5 genügt.
Kapitel V
Sicherheit
Artikel 23
Anmeldung von C-ITS-Stationen im System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU
1.Für die vertrauenswürdige und sichere Kommunikation zwischen den C-ITS-Stationen wird das System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU eingerichtet.
2.Die Funktionsweise des System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU muss den Anforderungen genügen, die niedergelegt sind in
(a)Anhang III (Certificate Policy), in dem die Anforderungen an die Verwaltung von Public-Key-Zertifikaten für C-ITS-Dienste durch die ausstellenden Teilnehmer und deren Nutzung durch die Endteilnehmer festgelegt sind;
(b)Anhang IV (Sicherheitsvorschriften), in dem die Anforderungen an das Management der Informationssicherheit im Rahmen von C-ITS festgelegt sind.
3.Alle C-ITS-Stationen werden im System für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU angemeldet und müssen den Vorschriften dieses Systems genügen, im Einklang mit den in den Anhängen III und IV festgelegten Spezifikationen.
Artikel 24
Für die C-ITS Certificate Policy zuständige Stelle
1.Die Stelle für die C-ITS Certificate Policy ist für die Verwaltung der Certificate Policy und der PKI-Autorisierung gemäß der in Anhang III festgelegten Certificate Policy zuständig.
2.Die Kommission fungiert als für die C-ITS Certificate Policy zuständige Stelle, bis ein gesonderter dafür zuständiger Teilnehmer eingerichtet ist.
Artikel 25
Trust List Manager
1.Der Trust List Manager ist für die Erstellung und Aktualisierung der European Certificate Trust List (ECTL) im Einklang mit der Certificate Policy nach Anhang III sowie für den regelmäßigen Tätigkeitsbericht an die für die C-ITS Certificate Policy zuständige Stelle hinsichtlich der insgesamt sicheren Funktionsweise des C-ITS Trust Models verantwortlich.
2.Die Kommission fungiert als Trust List Manager, bis ein gesonderter dafür zuständiger Teilnehmer eingerichtet ist.
Artikel 26
C-ITS-Kontaktstelle
1.Die C-ITS-Kontaktstelle ist zuständig für die gesamte Kommunikation mit den Managern der Root Certification Authority und für die Veröffentlichung der Public-Key-Zertifikate des Trust List Managers und der ECTL im Einklang mit der Certificate Policy nach Anhang III.
2.Die Kommission fungiert als C-ITS-Kontaktstelle, bis ein gesonderter dafür zuständiger Teilnehmer eingerichtet ist.
Artikel 27
Informationssicherheitsmanagementsystem
Jeder Betreiber einer C-ITS-Station betreibt ein Informationssicherheitsmanagementsystem gemäß ISO/IEC 27001 und den zusätzlichen Anforderungen in Anhang IV Abschnitt 1.3.1.
Artikel 28
Einhaltung der Sicherheitsvorschriften
Die Betreiber von C-ITS-Stationen müssen regelmäßig eine Zertifizierung gemäß den Anforderungen in Anhang IV Abschnitt 1.7 anfordern und erhalten.
Kapitel VI
Umsetzung
Artikel 29
Aufbau des C-ITS-Netzes
1.Die Kommission hat im Zusammenhang mit der Errichtung des C-ITS-Netzes folgende Aufgaben:
(a)Governance-Aufgaben:
(1)Vorbereitung von Aktualisierungen des C-ITS-Steuerungsrahmens;
(2)Unterstützung der Entwicklung gemeinsamer Grundsätze für die rechtmäßige Verarbeitung personenbezogener Daten durch für die Verarbeitung Verantwortliche und Auftragsverarbeiter im Rahmen des C-ITS-Netzes;
(3)Kontaktstelle im Zusammenhang mit der Errichtung des C-ITS-Netzes für die Betreiber und Hersteller von C-ITS-Stationen, ITS-Nutzergruppen und Interessenträger aus Drittländern;
(4)Überprüfung des Folgenden:
(a)Kriterien für die C-ITS-Bewertung, die von Prüflaboren und anderen Bewertungsorganisationen bei der Konformitätsbewertung anzuwenden sind;
(b)C-ITS-Referenzspezifikationen, einschließlich Grund- und Prüfnormen, die während der verschiedenen Phasen des Bewertungsverfahrens zu verwenden sind;
(b)Aufsichtsaufgaben: Überwachung des Managements großmaßstäblicher und schwerer Sicherheitsvorfälle, die sich auf das gesamte CITSNetz auswirken (einschließlich Wiederherstellungssituationen, wenn der kryptographische Algorithmus ungewollt weitergegeben wurde);
(c)Aufgaben der für die C-ITS-Certificate Policy zuständigen Stelle:
(1)Verwaltung der Certificate Policy;
(2)PKI-Autorisierungsmanagement.
2.Bei der Wahrnehmung der Aufgaben nach Absatz 1 wird die Kommission von einer Expertengruppe unterstützt, die sich aus Vertretern öffentlicher und privater Akteure des C-ITS-Netzes, insbesondere Herstellern und Betreibern von C-ITS-Stationen, zusammensetzt.
Kapitel VII
Schlussbestimmungen
Artikel 30
Einstweilige Maßnahmen
Im Falle einer Krisensituation, die das ordnungsgemäße Funktionieren des C-ITS-Netzes gefährdet und schwerwiegende unmittelbare Auswirkungen auf die Straßenverkehrssicherheit, die Cybersicherheit oder die Verfügbarkeit und Integrität der C-ITS-Dienste hat, kann die Kommission einen Beschluss zur Einführung einstweiliger Maßnahmen erlassen, um Abhilfe zu schaffen. Dieser Beschluss ist strikt auf die Beseitigung der Ursachen und Folgen dieser Situation beschränkt. Er gilt, bis diese Verordnung geändert wurde, um Abhilfe zu schaffen.
Artikel 31
Berichterstattung
1.Die Mitgliedstaaten überwachen die Durchführung dieser Verordnung in ihrem Hoheitsgebiet und berichten über die Fortschritte bei der Durchführung dieser Verordnung im Rahmen der regelmäßigen Berichterstattung nach Artikel 17 Absatz 3 der Richtlinie 2010/40/EU. Die Berichterstattung erstreckt sich insbesondere auf Folgendes:
(a)eine Beschreibung der einschlägigen öffentlichen und öffentlich-privaten Initiativen für die C-ITS-Einführung, einschließlich ihrer Ziele, des Zeitplans, der Etappenziele, der Ressourcen, des/der federführenden Interessenträger(s) und des aktuellen Stands;
(b)die Abdeckung des Straßennetzes nach Straßenkategorien für jeden in Anhang I aufgeführten vorrangigen C-ITS-Dienst für die Fahrzeug-Infrastruktur-Kommunikation;
(c)die Zahl der auf ihrem Hoheitsgebiet betriebenen straßenseitigen und zentralen C-ITS-Stationen.
Die Mitgliedstaaten erstatten erstmals bis zum 27. August 2020 Bericht.
2.Die in der European Certificate Trust List nach Anhang III aufgeführten Wurzelzertifizierungsstellen teilen der Kommission bis zum 31. Dezember 2020 und danach jedes Jahr bis zum 31. Dezember die Zahl der angemeldeten und operativen mobilen und ortsfesten CITS-Stationen unter ihrer Zuständigkeit mit.
Artikel 32
Vor dem 31. Dezember 2019 in Verkehr gebrachte C-ITS-Stationen
1.Die Anmeldung von C-ITS-Stationen, die spätestens am 31. Dezember 2019 in Verkehr gebracht werden und den Anforderungen dieser Verordnung in Bezug auf die C-ITS-Sicherheit nicht vollständig genügen, und von C-ITS-Stationen desselben Typs/Modells, die spätestens am 30. Juni 2021 in Verkehr gebracht werden, im C-ITS Trust Model kann von der für die C-ITS Certificate Policy zuständigen Stelle auf Einzelfallbasis gestattet werden, sofern die in Absatz 2 genannten Bedingungen erfüllt sind. Die Anmeldung von C-ITS-Stationen desselben Typs/Modells, die in Satz 1 genannte defekte C-ITS-Stationen ersetzen, kann ebenfalls unter denselben Bedingungen gestattet werden.
2.Die für die C-ITS Certificate Policy zuständige Stelle kann die C-ITS-Stationen nach Absatz 1 im C-ITS Trust Model unter folgenden Bedingungen anmelden:
(a)es gilt das gleiche Sicherheits- und Vertrauensniveau wie in dieser Verordnung vorgeschrieben;
(b)es wird nachgewiesen, dass die jeweiligen C-ITS-Stationen und das geplante Anmeldungsverfahren keine zusätzlichen Risiken für das C-ITS-Netz darstellen.
3.Die für die C-ITS Certificate Policy zuständige Stelle fasst ihren Beschluss auf der Grundlage des Berichts eines zugelassenen PKI-Prüfers und einer Bewertung der Sicherheitsdefizite durch eine Konformitätsbewertungsstelle.
Artikel 33
Überprüfung
1.Bis zum [OP: Datum einfügen: drei Jahre nach Inkrafttreten dieser Verordnung] überprüft die Kommission die Durchführung dieser Verordnung und nimmt gegebenenfalls im Rahmen dieser Verordnung neue gemeinsame Spezifikationen an.
2.Beabsichtigen die Beteiligten, eine(n) neue(n) oder aktualisierte(n) Kommunikationsmethode oder -dienst oder andere innovative Lösungen, darunter Technologien, für die derzeit Prototypen getestet werden, im C-ITS-Netz einzuführen, so übermitteln sie der Kommission zunächst ein Dossier mit den technischen Spezifikationen und Angaben zum Grad der Ausgereiftheit und der Kompatibilität der innovativen Lösung mit dieser Verordnung. Diese technischen Spezifikationen werden im Einklang mit den Grundsätzen der Offenheit, des Konsenses und der Transparenz gemäß Anhang II der Verordnung (EU) Nr. 1025/2012 ausgearbeitet.
Die Kommission prüft dann das Dossier unverzüglich und beginnt innerhalb von zwei Monaten, das Dossier mit der Expertengruppe nach Artikel 29 Absatz 2 mit Blick auf eine mögliche Änderung dieser Verordnung zu erörtern. Die Expertengruppe bewertet die Notwendigkeit gemeinsamer Spezifikationen für die Integration der neuen Lösungen in das C-ITS-Netz und gibt spätestens sechs Monate nach Eingang des Dossiers eine Stellungnahme ab. Gegebenenfalls unterstützt die Gemeinsame Forschungsstelle der Kommission die einschlägigen Diskussionen mit einer unabhängigen technischen Bewertung.
Die Einreichung innovativer Lösungen bei der Kommission und gegebenenfalls die anschließende Änderung dieser Verordnung können jederzeit nach Inkrafttreten dieser Verordnung erfolgen.
3.Um die Kontinuität der vorrangigen C-ITS-Dienste nach Anhang I zu gewährleisten, müssen künftige Änderungen die Kompatibilität und Interoperabilität mit bestehenden C-ITS-Stationen, die im Einklang mit dieser Verordnung in Betrieb genommen werden, gewährleisten oder einen geeigneten Migrationspfad festlegen.
Artikel 34
Inkrafttreten
Diese Verordnung tritt am zwanzigsten Tag nach ihrer Veröffentlichung im Amtsblatt der Europäischen Union in Kraft.
Sie gilt ab dem 31. Dezember 2019.
Diese Verordnung ist in allen ihren Teilen verbindlich und gilt unmittelbar in jedem Mitgliedstaat.
Brüssel, den 13.3.2019
Für die Kommission
Der Präsident
Jean-Claude JUNCKER
ANHANG I
1.Einleitung
Dieser Anhang enthält die Dienstprofile für die C-ITS-Prioritätsdienste. Ein Dienstprofil ist eine besondere Konfiguration von Normen, mit der die Durchführung verschiedener Normenoptionen festgelegt wird.
1.1.Referenzdokumente
In diesem Anhang werden folgende Referenzdokumente herangezogen:
TS 102 894-2
ETSI TS 102 894-2, Intelligent Transport Systems (ITS); Users and applications requirements; Teil 2: Applications and facilities layer common data dictionary, V1.3.1 (2018-08)
EN 302 637-2
ETSI EN 302 637-2, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Teil 2: Specification of Cooperative Awareness Basic Service, V1.4.0 (2018-08); dieses Referenzdokument gilt als Verweis auf Version 1.4.1 ab dem Zeitpunkt der Veröffentlichung dieser Version.
EN 302 637-3
ETSI EN 302 637-3, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Teil 3: Specifications of Decentralized Environmental Notification Basic Service, v1.3.0 (201808) dieses Referenzdokument gilt als Verweis auf Version 1.3.1 ab dem Zeitpunkt der Veröffentlichung dieser Version.
ECE 13
Regelung Nr. 13 der Wirtschaftskommission der Vereinten Nationen für Europa (UN/ECE), Einheitliche Bedingungen für die Genehmigung von Fahrzeugen der Klassen M, N und O hinsichtlich der Bremsen [2016/194]
ECE 13H
Regelung Nr. 13H der Wirtschaftskommission für Europa der Vereinten Nationen (UN/ECE) — Einheitliche Bedingungen für die Genehmigung von Personenkraftwagen hinsichtlich der Bremsen [2015/2364]
ECE 48
Regelung Nr. 48 der Wirtschaftskommission der Vereinten Nationen für Europa (UN/ECE) — Einheitliche Bedingungen für die Genehmigung der Fahrzeuge hinsichtlich des Anbaus der Beleuchtungs- und Lichtsignaleinrichtungen [2016/1723]
ECE 121
Regelung Nr. 121 der Wirtschaftskommission der Vereinten Nationen für Europa (UN/ECE) — Einheitliche Bedingungen für die Genehmigung von Fahrzeugen hinsichtlich der Anordnung und Kennzeichnung der Handbetätigungseinrichtungen, Kontrollleuchten und Anzeiger [2016/18]
ISO/TS 19321
Intelligente Transportsysteme - Kooperative ITS - Verzeichnis von Datenstrukturen fahrzeuginterner Informationen (IVI) (15. April 2015)
ISO 639-1
Kennungen für Namen von Sprachen — Teil 1: Alpha-2-Code
ISO/TS 14823
ISO/TS 14823:2017. Intelligente Verkehrssysteme - Graphisches Verzeichnis
1.2.Notationen und Abkürzungen
In diesem Anhang werden folgende Notationen und Abkürzungen verwendet:
ABS
Antiblockiersystem
ASR
Antriebs-Schlupf-Regelung
AT
Authorization Ticket [Berechtigungsticket]
CAM
Cooperative Awareness Message [kooperative Sensibilisierungsbenachrichtigung]
C-ITS
Kooperatives Intelligentes Verkehrssystem
DCC
Decentralized Congestion Control [dezentrale Stausteuerung]
DEN
Decentralized Environmental Notification [dezentrale Umfeldmeldung]
DENM
Decentralized Environmental Notification Message [dezentrale Umfeldbenachrichtigung]
GNSS
Global Navigation Satellite System [globales Satellitennavigationssystem]
I2V
infrastructure-to-vehicle [Infrastruktur-Fahrzeug]
IRC
Impact Reduction Container [Aufprallreduzierungscontainer]
IVI
Infrastructure to Vehicle Information [Information Infrastruktur - Fahrzeug]
MAP
Topology information for the intersection [topologische Information für Kreuzung]
SPAT
Signal Phase and Timing [Ampelphase und Timing]
SREM
Signal Request Extended Message [erweiterte Meldung (Ampel)-Signalanforderung]
SSEM
Signal Request Status Extended Message [erweiterte Meldung, Status, (Ampel-)Signalanforderung]
TC
Traffic Class [Verkehrsklasse]
TMS
Traffic Management system [Verkehrsmanagementsystem]
TOC
traffic operations centre [Verkehrseinsatzzentrale]
TRCO
Triggering condition [Auslösebedingung]
TTC
Time to Collision [Zeit bis zur Kollision]
V2V
vehicle-to-vehicle [Fahrzeug zu Fahrzeug]
1.3.Begriffsbestimmungen
In diesem Anhang werden folgende Begriffsbestimmungen verwendet:
(a)„Stehendes Fahrzeug“ bezeichnet ein Fahrzeug mit einer absoluten Geschwindigkeit von <= 8 cm pro Sekunde. Dieser Zustand wird von fahrzeuginternen Sensoren bestimmt;
(b)„Einsatzfahrzeug“ bezeichnet ein Fahrzeug, das für die Reaktion auf Notfälle ausgewiesen und berechtigt ist. Einsatzfahrzeugen ist es häufig gesetzlich gestattet, gegen herkömmliche Verkehrsregeln zu verstoßen, damit sie ihr Ziel schnellstmöglich erreichen können, beispielsweise das Durchfahren einer Kreuzung bei roten Ampeln oder das Überschreiten der Geschwindigkeitsbegrenzung.
2.Verzeichnis der vorrangigen Dienste
|
Dienstkategorie
|
Dienst
|
Dienstprofil
|
|
Fahrzeug-zu-Fahrzeug-Dienste
|
|
Verkehrsstau
|
Gefährliches Stauende
|
Abschnitt 3
|
|
Verkehrsstau
|
Verkehrsstau voraus
|
Abschnitt 4
|
|
Warnung vor stehendem Fahrzeug
|
Stillstehendes Fahrzeug
|
Abschnitt 5
|
|
Warnung vor stehendem Fahrzeug
|
Liegengebliebenes Fahrzeug
|
Abschnitt 6
|
|
Warnung vor stehendem Fahrzeug
|
Nach Zusammenstoß
|
Abschnitt 7
|
|
Warnung vor Sonderfahrzeug
|
Einsatzfahrzeug im Einsatz
|
Abschnitt 8
|
|
Warnung vor Sonderfahrzeug
|
Stehendes, sicherndes Einsatzfahrzeug
|
Abschnitt 9
|
|
Warnung vor Sonderfahrzeug
|
Warnung vor stehendem Bergungsdienst
|
Abschnitt 10
|
|
Austausch von IRC
|
Anforderung von IRC
|
Abschnitt 11
|
|
Austausch von IRC
|
Antwort IRC
|
Abschnitt 12
|
|
Gefährliche Situation
|
Elektronisches Gefahrenbremslicht
|
Abschnitt 13
|
|
Gefährliche Situation
|
Automatische Bremsung
|
Abschnitt 14
|
|
Gefährliche Situation
|
Auslösung des reversiblen Insassenrückhaltesystems
|
Abschnitt 15
|
|
Widrige Witterungsbedingungen
|
Nebel
|
Abschnitt 16
|
|
Widrige Witterungsbedingungen
|
Niederschlag
|
Abschnitt 17
|
|
Widrige Witterungsbedingungen
|
Traktionsverlust
|
Abschnitt 18
|
|
Infrastruktur-zu-Fahrzeug-Dienste
|
|
Anzeige von Verkehrszeichen im Fahrzeug
|
Dynamische Information über Geschwindigkeitsbegrenzungen
|
Abschnitt 19
|
|
Anzeige von Verkehrszeichen im Fahrzeug
|
Eingebettetes Sprachspeichersystem (VMS) „Freitext“
|
Abschnitt 20
|
|
Anzeige von Verkehrszeichen im Fahrzeug
|
Sonstige Informationen über Verkehrszeichen
|
Abschnitt 21
|
|
Warnungen vor gefährlichen Situationen
|
Unfallbereich
|
Abschnitt 22
|
|
Warnungen vor gefährlichen Situationen
|
Verkehrsstau voraus
|
Abschnitt 23
|
|
Warnungen vor gefährlichen Situationen
|
Stehendes Fahrzeug
|
Abschnitt 24
|
|
Warnungen vor gefährlichen Situationen
|
Warnung vor Witterungsbedingungen
|
Abschnitt 25
|
|
Warnungen vor gefährlichen Situationen
|
Vorübergehend rutschige Fahrbahn
|
Abschnitt 26
|
|
Warnungen vor gefährlichen Situationen
|
Tier oder Person auf der Fahrbahn
|
Abschnitt 27
|
|
Warnungen vor gefährlichen Situationen
|
Hindernis auf der Fahrbahn
|
Abschnitt 28
|
|
Warnung vor Straßenarbeiten
|
Fahrstreifensperrung (und andere Einschränkungen)
|
Abschnitt 29
|
|
Warnung vor Straßenarbeiten
|
Straßensperrung
|
Abschnitt 30
|
|
Warnung vor Straßenarbeiten
|
Straßenbauarbeiten — mobil
|
Abschnitt 31
|
|
Beampelte Kreuzung
|
Geschwindigkeitsempfehlungen bezüglich grüner Welle
|
Abschnitt 32
|
|
Beampelte Kreuzung
|
Vorrang für öffentlichen Personennahverkehr
|
Abschnitt 33
|
3.Verkehrsstau — gefährliches Stauende
3.1.Beschreibung des Dienstes kooperativer intelligenter Verkehrssysteme (C-ITS)
Dieser C-ITS-Dienst übermittelt Fahrzeug-zu-Fahrzeug-Informationen (V2V) über eine Situation, in der ein Ego-Fahrzeug (das eigene Fahrzeug) das Ende eines Verkehrsstaus erkennt („gefährliches Stauende“). Eine solche Situation liegt vor, wenn die Fahrspur des Ego-Fahrzeugs blockiert ist und das Fahrzeug auf dieser Fahrspur nicht weiterfahren kann. Bei diesem Dienst wird das städtische Umfeld nicht berücksichtigt.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·‚gefährliche Situationen — elektronisches Gefahrenbremslicht“.
3.2.Auslösebedingungen
3.2.1.Voraussetzungen
(1)Bevor dieser C-ITS-Dienst ausgelöst wird, müssen jedes Mal die folgenden Voraussetzungen erfüllt sein:
(a)das Ego-Fahrzeug befindet sich in einem nichtstädtischen Umfeld, was auf mindestens eine der folgenden Arten bestimmt wird:
·die Geschwindigkeit ist über einen Zeitblock von mindestens 30 s in den 60 s vor jeder Situationserkennung höher als 80 km/h und der absolute Wert des Lenkradwinkels beträgt über einen Zeitblock von mindestens 30 s in den 60 s vor jeder Situationserkennung weniger als 90 ° (die Situation „gefährliches Stauende“ sollte in einem Umfeld außerhalb von Autobahnen nicht erkannt werden);
·der Sensor einer Bordkamera zeigt ein nichtstädtisches Umfeld an;
·eine an Bord verfügbare, digitale Landkarte zeigt ein nichtstädtisches Umfeld an.
(2)Die Geschwindigkeit und die Geschwindigkeitsverringerung des Fahrzeuges werden durch das Bussignal des Fahrzeugs festgestellt, nicht durch ein globales Satellitennavigationssystem (GNSS). Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und Geschwindigkeitsverringerung des Fahrzeugs erfolgt.
(3)Die Geschwindigkeits- und Winkelwerte werden fortlaufend gemessen. Die Bedingungen müssen für die gesamte Messdauer erfüllt werden. Der Prozess beginnt erneut, wenn die Bedingungen innerhalb der Messdauer nicht erfüllt werden.
3.2.2.Dienstspezifische Bedingungen
(4)Werden die unter Nummer 1 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
·TRCO_0 UND (TRCO _2 ODER TRCO _3 ODER TRCO _4 ODER TRCO _5 ODER TRCO _6)
·TRCO_1 UND TRCO_2.
Tabelle 1: Dienstspezifische Bedingungen für „Verkehrsstau — gefährliches Stauende“
|
Zählimpuls
|
Auslösebedingung (TRCO)
|
Status
|
|
TRCO_0
|
Das Ego-Fahrzeug fährt mit einer Anfangsgeschwindigkeit von mehr als 80 km/h und die anfängliche Geschwindigkeitsreduzierung ist gleich oder weniger als 0,1 m/s². Der Fahrzeugführer reagiert mittels Geschwindigkeitsverringerung von der Anfangs- auf die Zielgeschwindigkeit von 30 km/h oder weniger auf das gefährliche Stauende. Die Zeitspanne zwischen Anfangs- und Zielgeschwindigkeit soll 10 s oder weniger betragen. Eine sofortige Geschwindigkeitsverringerung zwischen Anfangs- und Zielgeschwindigkeit von mehr als 3,5 m/s² wird erkannt.
|
Fahrerreaktion
|
|
TRCO_1
|
Insassen des Ego-Fahrzeugs reagieren mittels Einschalten der Warnblinklichter für mindestens 3 s auf den Verkehrsstau.
|
Fahrerreaktion
|
|
TRCO_2
|
Mindestens drei andere Fahrzeuge mit einer Geschwindigkeit von mindestens 7 km/h haben mindestens 3 s lang die Warnblinklichter eingeschaltet; dies wird angezeigt durch:
·einen Bordkamera-Sensor; oder
·CAM.
|
Umfeld- oder Bordsensoren
|
|
TRCO_3
|
Es ist mindestens eine DENM empfangen worden, die dem C-ITS-Dienst „Verkehrsstau – Gefährliches Stauende“ entspricht.
|
Umfeld
|
|
TRCO_4
|
Vom vorausfahrenden Verkehr sind mindestens fünf verschiedene DENM (d. h. DENM mit unterschiedlichen actionIDs) [MaßnahmenID] empfangen worden, die dem C-ITS-Dienst „Verkehrsstau – Verkehrsstau voraus“ entsprechen.
|
Umfeld
|
|
TRCO_5
|
Es ist mindestens eine DENM empfangen worden, die dem C-ITS-Dienst „Warnung vor Sonderfahrzeug – Stehendes, sicherndes Einsatzfahrzeug“ entspricht, wobei der linkedCause gleich Verkehrslage oder Gefährliches Stauende ist.
|
Umfeld
|
|
TRCO_6
|
Bordsensoren des Ego-Fahrzeuges erkennen, dass das Fahrzeug mit einem gefährlichen Stauende konfrontiert ist.
|
Bordsensoren
|
(5)Innerhalb der Detection Blocking Time [ErkennungsSperrzeit] wird keine neue DENM angefordert. Die Detection Blocking Time [ErkennungsSperrzeit] beginnt zu laufen, sobald das Ereignis erkannt und eine diesbezügliche DENM angefordert worden ist. Auf diese Weise wird verhindert, dass ein einziges Ereignis den Übertragungskanal überflutet. Die Detection Blocking Time [ErkennungsSperrzeit] beträgt 60 s, unabhängig davon, wie das Ereignis erkannt worden ist. Die Erkennungszeit zwischen zwei erkannten Ereignissen ist mindestens gleich der Detection Blocking Time [ErkennungsSperrzeit]. Der Erkennungsalgorithmus kann während der Detection Blocking Time [ErkennungsSperrzeit] laufen.
Anmerkung: Es wird kein Zeitraum für das Bremsmanöver dargestellt, weil für die Anfangsgeschwindigkeit des Ego-Fahrzeuges keine obere Einschränkung besteht.
(6)Eine Bedingung gilt, solange sie aktiv ist und darüber hinaus weitere 5 s (dieser zusätzliche Zeitraum erhöht den Determinismus des Erkennungsalgorithmus). Die Gültigkeitsdauer sinkt ab dem Augenblick, an dem die Bedingung nicht mehr erfüllt wird, so dass die Kombination verschiedener Auslösebedingungen erleichtert wird.
(7)CAM und DENM von Fremdfahrzeugen, die zur Auswertung dienstspezifischer Bedingungen gemäß der vorstehenden Beschreibung verwendet werden, sind für das Ego-Fahrzeug relevant. Die Relevanz wird auf eine der folgenden Methoden bestimmt:
(a)eine digitale Landkarte zeigt, dass zwischen dem Ereignis und dem Ego-Fahrzeug ein Abstand von weniger als 500 m liegt und dass sie sich in der gleichen Fahrtrichtung bewegen;
(b)eine Übereinstimmung der Streckenhistorie zeigt, dass zwischen dem Ereignis und dem Ego-Fahrzeug ein Abstand von weniger als 500 m liegt und dass sie sich in der gleichen Fahrtrichtung bewegen;
(c)der euklidische Abstand zwischen dem Ereignis und dem Ego-Fahrzeug beträgt weniger als 500 m und der absolute Wert der Kursdifferenz beträgt weniger als 10 °. Die Referenzpositionen des Verkehrsstaus laut der DENM befinden sich in einem Bereich zwischen -45 ° und +45 ° von der Längsachse des Ego-Fahrzeuges aus gesehen.
Anmerkung: Bei der Zählung von Fahrzeugen oder Ereignissen sind Wechsel des Authorization Ticket [Berechtigungstickets] (AT) so zu berücksichtigen, dass Fahrzeuge oder Ereignisse nicht mehrfach gezählt werden.
3.2.3.Qualität der Informationen
(8)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie die Situation erkannt wird. Auslösebedingungen (TRCO) (siehe Nummer 4) werden in folgende Gruppen untergliedert: Fahrerreaktion, Fahrzeugdynamik, Umfeld- und Bordsensoren. Der Wert informationQuality [InformationsQualität] wird nach der folgenden Tabelle festgesetzt. Dabei wird der höchstmögliche Wert verwendet.
Tabelle 2: Qualität der Information „Verkehrsstau — gefährliches Stauende“
|
Ereigniserkennung
|
Wert von InformationQuality
[InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Mindestens eine TRCO aus den Gruppen Fahrerreaktion UND Umfeld ist erfüllt.
|
1
|
|
Mindestens eine TRCO aus den Gruppen Fahrerreaktion UND Bordsensoren ist erfüllt.
|
2
|
|
Mindestens eine TRCO aus den Gruppen Fahrerreaktion UND Umfeld UND Bordsensoren ist erfüllt.
|
3
|
3.3.Beendigungsbedingungen
(9)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
3.3.1.Löschung
(10)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
3.3.2.Verneinung
(11)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
3.4.Aktualisierung
(12)Für diesen C-ITS-Dienst wird keine Aktualisierungs-DENM verwendet.
3.5.Wiederholungsdauer und Wiederholungsintervall
(13)Neue DENM werden über eine repetitionDuration [WiederholungsDauer] von 20 s in einem repetitionInterval [WiederholungsIntervall] von 0,5 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen CITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
3.6.Verkehrsklasse
(14)Neue DENM werden auf traffic class [Verkehrsklasse] 1 gesetzt.
3.7.Benachrichtigungsparameter
3.7.1.DENM
(15)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 3: DENM-Datenelemente von „Verkehrsstau — gefährliches Stauende"
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts - Zeitstempel, bei dem eine neue DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan1000 m(4) [wenigerAls1000m(4)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsRichtung]
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
validityDuration [GültigkeitsDauer]
|
20 s (es wird davon ausgegangen, dass die Fahrzeuge 20 s nach der Erkennung einer anderen Verkehrssituation ausgesetzt sein werden).
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 8.
|
|
causeCode [UrsachenKennung]
|
dangerousEndOfQueue(27) [gefährlichesStauende(27)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
eventPositionHeading [KursDerEreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennung zuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
3.7.2.Cooperative Awareness Message (CAM) [kooperative Sensibilisierungsbenachrichtigung]
(16)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
3.8.Netz- und Beförderungsebene
(17)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
3.9.Sicherheitsebene
(18)Sind die Auslösebedingungen gemäß Beschreibung unter Nummer 4 erfüllt, wird ein AT-Wechsel für neue DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende neue DENM werden mit dem gleichen Berechtigungsticket (AT) gesendet.
4.Verkehrsstau — Verkehrsstau voraus
4.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über Situationen, in denen ein Ego-Fahrzeug einen Verkehrsstau erkennt. Eine solche Situation liegt vor, wenn das Ego-Fahrzeug von stehendem Verkehr oder hohem Verkehrsaufkommen umgeben ist. Dieser Dienst gilt nicht für städtische Umfelder.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
•
„Warnung vor stehendem Fahrzeug — stillstehendes Fahrzeug“;
•
„Warnung vor stehendem Fahrzeug — liegengebliebenes Fahrzeug“,
•
„Warnung vor stehendem Fahrzeug —nach Zusammenstoß“;
•
„Warnung vor Sonderfahrzeug – Warnung vor stehendem Bergungsdienst“.
4.2.Auslösebedingungen
4.2.1.Voraussetzungen
(19)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst eingeleitet wird:
(a)es ist kein Dienst „Warnung vor stehendem Fahrzeug“ (siehe Abschnitte 4 bis 6) erkannt worden;
(b)es ist kein Dienst „Warnung vor Sonderfahrzeug“ (siehe Abschnitte 7 bis 9) erkannt worden;
(c)das Ego-Fahrzeug befindet sich in einem nichtstädtischen Umfeld. Der Standort wird auf mindestens eine der folgenden Weisen bestimmt:
(a)die Geschwindigkeit ist über einen Zeitblock von mindestens 30 s in den 180 s vor jeder Situationserkennung höher als 80 km/h und der absolute Wert des Lenkradwinkels beträgt über einen Zeitblock von mindestens 30 s in den 60 s vor jeder Situationserkennung weniger als 90 ° (Verkehrsstaus sollten auf Autobahnen nicht erkannt werden);
(b)der Sensor einer Bordkamera zeigt ein nichtstädtisches Umfeld an;
(c)eine an Bord verfügbare, digitale Landkarte zeigt ein nichtstädtisches Umfeld an.
(20)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und des Fahrzeugs erfolgt.
(21)Die Geschwindigkeits- und Winkelwerte werden fortlaufend gemessen. Die Bedingungen müssen für die gesamte Messdauer erfüllt werden. Der Prozess beginnt erneut, wenn die Bedingungen innerhalb der Messdauer nicht erfüllt werden.
4.2.2.Dienstspezifische Bedingungen
(22)Werden die unter Nummer 19 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
·TRCO_0;
·TRCO _1 UND (TRCO _2 ODER TRCO _3 ODER TRCO _4 ODER TRCO _5)
Tabelle 4: Dienstspezifische Bedingungen für „Verkehrsstau — Verkehrsstau voraus“
|
Zählimpuls
|
Auslösebedingung
|
Status
|
|
TRCO_0
|
Das Ego-Fahrzeug bewegt sich mit einer Durchschnittsgeschwindigkeit von 30 km/h oder weniger und mehr als 0 km/h (dieser Schwellenwert wird zur Vermeidung von Überschneidungen und zur Unterscheidung zwischen TRCO_0 und TRCO_1 eingeführt). Die Durchschnittsgeschwindigkeit wird über einen Zeitraum von 120 s berechnet (mit der Bedingung der Dauer wird die Auslösung durch häufig wechselnde Verkehrszustände ausgeschlossen).
Anmerkung: Diese TRCO erfasst das Szenario, in dem das Ego-Fahrzeug von StopandGo-Verkehr umgeben ist.
|
Fahrzeugdynamik
|
|
TRCO_1
|
Die Geschwindigkeit des Ego-Fahrzeugs ist mindestens 30 s lang gleich 0 km/h.
Anmerkung: Diese TRCO erfasst das Szenario, in dem das Ego-Fahrzeug steht und von anderen Straßennutzern umgeben ist.
|
Fahrzeugdynamik
|
|
TRCO_2
|
Es ist mindestens eine DENM in der gleichen Fahrtrichtung, die dem C-ITS-Dienst „Verkehrsstau – Verkehrsstau voraus“ entspricht, empfangen worden.
|
Umfeld
|
|
TRCO_3
|
Es ist mindestens eine Staubenachrichtigung in der gleichen Fahrtrichtung mittels Mobilfunk empfangen worden.
|
Umfeld
|
|
TRCO_4
|
CAM zeigen für mindestens fünf andere Fahrzeuge innerhalb von 100 m in der gleichen Fahrtrichtung eine Geschwindigkeit von 30 km/h oder weniger an.
|
Umfeld
|
|
TRCO_5
|
Bordsensoren zeigen für mindestens fünf andere Fahrzeuge innerhalb von 100 m in der gleichen Fahrtrichtung eine Geschwindigkeit von 30 km/h oder weniger an.
|
Bordsensor
|
(23)Innerhalb der Detection Blocking Time [ErkennungsSperrzeit] wird keine neue DENM angefordert. Die Detection Blocking Time [ErkennungsSperrzeit] beginnt zu laufen, sobald das Ereignis erkannt und eine diesbezügliche DENM angefordert worden ist. Auf diese Weise wird verhindert, dass ein einziges Ereignis den Übertragungskanal überflutet. Die Detection Blocking Time [ErkennungsSperrzeit] beträgt 180 s, unabhängig davon, wie das Ereignis erkannt worden ist. Die Erkennungszeit zwischen zwei erkannten Ereignissen ist mindestens gleich der Detection Blocking Time [ErkennungsSperrzeit]. Der Erkennungsalgorithmus kann während der Detection Blocking Time [ErkennungsSperrzeit] laufen.
(24)Eine Bedingung gilt, solange sie aktiv ist und darüber hinaus weitere 5 s (dieser zusätzliche Zeitraum erhöht den Determinismus des Erkennungsalgorithmus). Die Gültigkeitsdauer sinkt ab dem Augenblick, an dem die Bedingung nicht mehr erfüllt wird, so dass die Kombination verschiedener Auslösebedingungen erleichtert wird.
(25)CAM und DENM von Fremdfahrzeugen, die zur Auswertung dienstspezifischer Bedingungen gemäß der vorstehenden Beschreibung verwendet werden, sind für das Ego-Fahrzeug relevant. Die Relevanz wird auf eine der folgenden Methoden bestimmt:
(a)eine digitale Landkarte zeigt, dass zwischen dem Ereignis und dem Ego-Fahrzeug ein Abstand von weniger als 500 m liegt und dass sie sich in der gleichen Fahrtrichtung bewegen;
(b)eine Übereinstimmung der Streckenhistorie zeigt, dass zwischen dem Ereignis und dem Ego-Fahrzeug ein Abstand von weniger als 500 m liegt und dass sie sich in der gleichen Fahrtrichtung bewegen;
(c)der euklidische Abstand zwischen dem Ereignis und dem Ego-Fahrzeug beträgt weniger als 500 m und der absolute Wert der Kursdifferenz beträgt weniger als 10 °. Die Referenzpositionen des Verkehrsstaus laut der DENM befinden sich in einem Bereich zwischen -45 ° und +45 ° von der Längsachse des Ego-Fahrzeuges aus gesehen.
Anmerkung: Bei der Zählung von Fahrzeugen oder Ereignissen sind Wechsel des Berechtigungstickets (AT) so zu berücksichtigen, dass Fahrzeuge oder Ereignisse nicht mehrfach gezählt werden.
4.2.3.Qualität der Informationen
(26)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie die Situation erkannt wird. Auslösebedingungen (TRCO) (siehe Nummer 22) werden in folgende Gruppen untergliedert: Fahrerreaktion, Fahrzeugdynamik, Umfeld- und Bordsensoren. Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt. Dabei wird der höchstmögliche Wert verwendet.
Tabelle 5: Qualität der Information „Verkehrsstau — Verkehrsstau voraus“
|
Ereigniserkennung
|
Wert von InformationQuality
[InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Mindestens eine Bedingung aus der Fahrzeugdynamik-Gruppe ist erfüllt, d. h. die Bedingung TRCO_0 ist erfüllt.
|
1
|
|
Mindestens eine Bedingung aus der Fahrzeugdynamik-Gruppe UND der Umfeld-Gruppe ist erfüllt.
|
2
|
|
Mindestens eine Bedingung aus der Fahrzeugdynamik-Gruppe UND der Bordsensor-Gruppe ist erfüllt.
|
3
|
|
Mindestens eine Bedingung aus der Fahrzeugdynamik-Gruppe UND der Umfeld-Gruppe UND der Bordsensor-Gruppe ist erfüllt.
|
4
|
4.3.Beendigungsbedingungen
(27)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
4.3.1.Löschung
(28)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
4.3.2.Verneinung
(29)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
4.4.Aktualisierung
(30)Für diesen C-ITS-Dienst wird keine Aktualisierungs-DENM verwendet.
4.5.Wiederholungsdauer und Wiederholungsintervall
(31)Neue DENM werden über eine repetitionDuration [WiederholungsDauer] von 60 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
4.6.Verkehrsklasse
(32)Neue DENM werden auf traffic class [Verkehrsklasse] 1 gesetzt.
4.7.Benachrichtigungsparameter
4.7.1.DENM
(33)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 6: DENM-Datenelemente von „Verkehrsstau — Verkehrsstau voraus“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts - Zeitstempel, bei dem eine neue DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan1000 m(4) [wenigerAls1000m(4)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
validityDuration [GültigkeitsDauer]
|
60 s (es wird davon ausgegangen, dass eine Verkehrsstausituation mindestens 60 s dauert)
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 26.
|
|
causeCode [UrsachenKennung]
|
trafficCondition(1) [VerkehrsBedingung(1)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
eventPositionHeading [KursDerEreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
4.7.2.CAM
(34)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
4.8.Netz- und Beförderungsebene
(35)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
4.9.Sicherheitsebene
(36)Sind die Auslösebedingungen gemäß Beschreibung unter Nummer 22 erfüllt, wird ein AT-Wechsel für neue DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende neue DENM werden mit dem gleichen Berechtigungsticket (AT) gesendet.
5.„Warnung vor stehendem Fahrzeug — stillstehendes Fahrzeug“
5.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über Situationen, in denen ein Fahrzeug angehalten hat, ohne besondere Angaben zu dem Grund.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Warnung vor Sonderfahrzeug – Warnung vor stehendem Bergungsdienst“;
·„Warnung vor stehendem Fahrzeug — liegengebliebenes Fahrzeug“,
·„Warnung vor stehendem Fahrzeug —nach Zusammenstoß“.
(37)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als erfüllt bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu-, Aktualisierungs- oder Lösch-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
5.2.Auslösebedingungen
5.2.1.Voraussetzungen
(38)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
(a)auf dem Instrumenten-Cluster wird keine Pannenwarnmeldung angezeigt, die den Fahrzeugführer am Weiterfahren hindert (z. B. rote Warnsymbole nach [ECE 121]).
Anmerkung: Dieser Dienst ist zur Kontrolle des Status von Zündterminal 15 für die Auslösung nicht erforderlich (kann ein- oder ausgeschaltet sein). Ist das Zündterminal 15 ausgeschaltet, ist der Betrieb des Dienstes optional.
(39)Eine Aktivierung parallel mit den anderen verwandten C-ITS-Diensten wird vermieden. Werden die C-ITS-Dienste „liegengebliebenes Fahrzeug“ und/oder „nach Zusammenstoß“ gleichzeitig ausgelöst, erhalten die C-ITS-Dienste folgende Priorität:
(a)„nach Zusammenstoß“ (höchste Priorität);
(b)„liegengebliebenes Fahrzeug“;
(c)„stillstehendes Fahrzeug“ (geringste Priorität).
5.2.2.Dienstspezifische Bedingungen
(40)Werden die unter Nummer 38 genannten Voraussetzungen und alle folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)das Ego-Fahrzeug hat Warnblinklichter eingeschaltet;
(b)das Fahrzeug steht;
(c)der Auslösetimer ist abgelaufen.
(41)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und des Fahrzeugs erfolgt.
(42)Hat das Fahrzeug die Warnblinklichter eingeschaltet und steht es, wird der Auslösetimer auf 30 s gestellt und gestartet. Der Auslösetimer wird kürzer eingestellt, wenn die folgenden Situation auftreten:
(a)der Timer wird 10 s kürzer eingestellt, wenn das Automatikgetriebe (AUT) mindestens 3 s lang auf „Parken“ gestellt wird;
(b)der Timer wird 10 s kürzer eingestellt, wenn das Getriebe mindestens 3 s lang in den Leerlauf geschaltet wird;
(c)der Timer wird 10 s kürzer eingestellt, wenn die Parkbremse mindestens 3 s lang aktiviert wird;
(d)der Timer wird 10 s kürzer eingestellt, wenn eine beliebige Anzahl von Sitzgurtschnallen mindestens 3 s lang von „angeschlossen“ in „getrennt“ wechselt;
(e)der Timer wird auf 0 gestellt, wenn eine beliebige Zahl von Türen mindestens 3 s lang offen ist;
(f)der Timer wird auf 0 gestellt, wenn das Zündterminal mindestens 3 s lang von „ein“ auf „aus“ geschaltet wird;
(g)der Timer wird auf 0 gestellt, wenn der Kofferraum mindestens 3 s lang offen ist;
(h)der Timer wird auf 0 gestellt, wenn der Motorraum mindestens 3 s lang offen ist.
(43)Sämtliche vorstehend aufgeführten Verfahren für eine Verkürzung der Timerzeit werden während der anfänglichen Erkennung nur einmal angewendet. Hat der Auslösetimer auf 0 heruntergezählt, ist im laufenden Erkennungszyklus keine weitere Verkürzung erforderlich.
(44)Während der Laufzeit des Auslösetimers sind die Warnblinklichter eingeschaltet und das Fahrzeug steht. In allen anderen Fällen wird die Erkennung gelöscht.
5.2.3.Qualität der Informationen
(45)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 42). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 7: Qualität der Information „stehendes Fahrzeug — stillstehendes Fahrzeug“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Keine der Bedingungen a) — h) wird erfüllt.
|
1
|
|
Mindestens eine Bedingung von a) — d) wird erfüllt.
|
2
|
|
Mindestens eine Bedingung von e) — h) wird erfüllt.
|
3
|
(46)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert. Während der Aktualisierungsphase werden nur die Bedingungen, die zu einer Verkürzung der Timerzeit führen würden, ausgewertet, nicht der Timer selbst.
5.3.Beendigungsbedingungen
(47)Dieser C-ITS-Dienst wird durch eine Löschung der C-ITS-Station, die ihn erzeugte, beendet. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
5.3.1.Löschung
(48)Wird mindestens eine der folgenden Bedingungen erfüllt, bevor die im Datenelement validityDuration [GültigkeitsDauer] festgesetzte Zeit abgelaufen ist, wird die Erzeugung einer Löschungs-DENM ausgelöst:
(a)das Fahrzeug steht für die Dauer von 5 s nicht mehr;
(b)die Warnblinklichter sind ausgeschaltet;
(c)die Position des Fahrzeugs hat sich um mehr als 500 m verändert (z. B. weil das Fahrzeug abgeschleppt worden ist).
Anmerkung: Die Löschbedingung impliziert nicht, dass die C-ITS-Station während dieser Löschungsbedingung dauernd in Betrieb sein oder ihren Betrieb ausdehnen muss.
5.3.2.Verneinung
(49)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
5.4.Aktualisierung
(50)Wurde die zuvor ausgelöste DENM über ein erkanntes Stillstehendes Fahrzeug nicht gelöscht, wird alle 15 s die Erzeugung einer Aktualisierungs-DENM ausgelöst.
(51)In der Aktualisierungsphase werden nur die Auslösebedingungen kontrolliert (eine weitere Auswertung von Timern wird nicht durchgeführt).
(52)Den Datenfeldern oder Elementen in der DENM werden dem veränderten Ereignis entsprechend neue Werte zugeordnet (z. B. detectionTime [Erkennungszeit] oder informationQuality [InformationsQualität].
Anmerkung: Die Aktualisierungsbedingung impliziert nicht, dass die C-ITS-Station während dieser Aktualisierungsbedingung dauernd in Betrieb sein oder ihren Betrieb ausdehnen muss.
5.5.Wiederholungsdauer und Wiederholungsintervall
(53)DENM, die neu sind, aktualisiert wurden oder gelöscht wurden, werden über eine repetitionDuration [WiederholungsDauer] von 15 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird auf 30 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
5.6.Verkehrsklasse
(54)Neu-, Aktualisierungs- und Löschungs-DENM werden auf Verkehrsklasse 1 gesetzt.
5.7.Benachrichtigungsparameter
5.7.1.DENM
(55)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 8: DENM-Datenelemente von „Warnung vor stehendem Fahrzeug — stillstehendes Fahrzeug“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts – Zeitstempel, bei dem eine Neu-, Aktualisierungs- oder Löschungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird im Fall einer Neu- oder Aktualisierungs-DENM nicht festgesetzt. Wird im Fall einer Löschungs-DENM auf isCancellation(0) [istLöschung(0)] gesetzt.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan1000 m(4) [wenigerAls1000m(4)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsRichtung]
|
Ist der Straßentyp bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
30 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 45. Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
causeCode [UrsachenKennung]
|
stationaryVehicle(94) [stehendesFahrzeug(94)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
Alacarte-Container: StationaryVehicleContainer [ContainerStehendesFahrzeug]
|
|
stationarySince [stehendSeit]
|
Wird entsprechend der Dauer in Minuten, für die die erkennende C-ITS-Station steht, festgesetzt. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
5.7.2.CAM
(56)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
5.8.Netz- und Beförderungsebene
(57)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
5.9.Sicherheitsebene
(58)Treffen die unter Nummer 40 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu-, Aktualisierungs- und Lösch-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu-, Aktualisierungs- und Lösch-DENM werden mit dem gleichen Berechtigungsticket gesendet.
6.Warnung vor stehendem Fahrzeug — liegengebliebenes Fahrzeug
6.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über ein liegengebliebenes Fahrzeug. Fahrzeugpannen können zwar aus verschiedenen Gründen auftreten, beispielsweise geplatzten Reifen, Kraftstoffmangel oder Motorausfall, aber in diesem Abschnitt stehen die im Instrumentencluster angezeigten Pannenwarnmeldung im Mittelpunkt.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Warnung vor Sonderfahrzeug – Warnung vor stehendem Bergungsdienst“;
·„Warnung vor stehendem Fahrzeug — stillstehendes Fahrzeug“;
·„Warnung vor stehendem Fahrzeug —nach Zusammenstoß“.
(59)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu-, Aktualisierungs- oder Lösch-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
6.2.Auslösebedingungen
6.2.1.Voraussetzungen
(60)Die folgende Voraussetzung muss erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
(a)auf dem Instrumenten-Cluster wird eine Pannenwarnmeldung angezeigt, die den Fahrzeugführer am Weiterfahren hindert (z. B. rote Warnsymbole nach [ECE 121]).
Anmerkung: Dieser Dienst ist zur Kontrolle des Status von Zündterminal 15 für die Auslösung nicht erforderlich (kann ein- oder ausgeschaltet sein). Ist das Zündterminal 15 ausgeschaltet, ist der Betrieb des Dienstes optional.
(61)Eine Aktivierung parallel mit den anderen verwandten C-ITS-Diensten wird vermieden. Werden die C-ITS-Dienste „stillstehendes Fahrzeug“ und/oder „nach Zusammenstoß“ gleichzeitig ausgelöst, erhalten die C-ITS-Dienste folgende Priorität:
(a)„nach Zusammenstoß“ (höchste Priorität);
(b)„liegengebliebenes Fahrzeug“;
(c)„stillstehendes Fahrzeug“ (geringste Priorität).
6.2.2.Dienstspezifische Bedingungen
(62)Werden die unter Nummer 60 genannten Voraussetzungen und alle folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)das Ego-Fahrzeug hat Warnblinklichter eingeschaltet;
(b)das Fahrzeug steht;
(c)der Auslösetimer ist abgelaufen.
(63)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und des Fahrzeugs erfolgt.
(64)Hat das Fahrzeug die Warnblinklichter eingeschaltet und steht es, wird der Auslösetimer auf 30 s gestellt und gestartet. Der Auslösetimer wird kürzer eingestellt, wenn die folgenden Situation auftreten:
(a)der Timer wird 10 s kürzer eingestellt, wenn das Automatikgetriebe (AUT) mindestens 3 s lang auf „Parken“ gestellt wird;
(b)der Timer wird 10 s kürzer eingestellt, wenn das Getriebe mindestens 3 s lang in den Leerlauf geschaltet wird;
(c)der Timer wird 10 s kürzer eingestellt, wenn die Parkbremse mindestens 3 s lang eingeschaltet wird;
(d)der Timer wird 10 s kürzer eingestellt, wenn eine beliebige Anzahl von Sitzgurtschnallen mindestens 3 s lang von „angeschlossen“ in „getrennt“ wechselt;
(e)der Timer wird auf 0 gestellt, wenn eine beliebige Zahl von Türen mindestens 3 s lang offen ist;
(f)der Timer wird auf 0 gestellt, wenn das Zündterminal mindestens 3 s lang von „ein“ auf „aus“ geschaltet wird;
(g)der Timer wird auf 0 gestellt, wenn der Kofferraum mindestens 3 s lang offen ist;
(h)der Timer wird auf 0 gestellt, wenn der Motorraum mindestens 3 s lang offen ist.
(65)Sämtliche vorstehend aufgeführten Verfahren für eine Verkürzung der Timerzeit werden während der anfänglichen Erkennung nur einmal angewendet. Hat der Auslösetimer auf 0 heruntergezählt, ist im laufenden Erkennungszyklus keine weitere Verkürzung erforderlich.
(66)Während der Laufzeit des Auslösetimers sind die Warnblinklichter eingeschaltet und das Fahrzeug steht die gesamte Zeit über. In allen anderen Fällen wird die Erkennung gelöscht.
6.2.3.Qualität der Informationen
(67)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 64). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 9: Qualität der Information „stehendes Fahrzeug — liegengebliebenes Fahrzeug“
|
Ereigniserkennung
|
Wert der InformationsQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Keine der Bedingungen a) — h) wird erfüllt.
|
1
|
|
Mindestens eine Bedingung von a) — d) wird erfüllt.
|
2
|
|
Mindestens eine Bedingung von e) — h) wird erfüllt.
|
3
|
(68)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert. Während der Aktualisierungsphase werden nur die Bedingungen, die zu einer Verkürzung der Timerzeit führen würden, ausgewertet, nicht der Timer selbst.
6.3.Beendigungsbedingungen
(69)Dieser C-ITS-Dienst wird durch eine Löschung der C-ITS-Station, die ihn erzeugte, beendet. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
6.3.1.Löschung
(70)Wird mindestens eine der folgenden Bedingungen erfüllt, bevor die im Datenelement validityDuration [GültigkeitsDauer] festgesetzte Zeit abgelaufen ist, wird die Erzeugung einer Löschungs-DENM ausgelöst:
(a)das Fahrzeug steht für die Dauer von 5 s nicht mehr;
(b)die Warnblinklichter sind ausgeschaltet;
(c)die Position des Fahrzeugs hat sich um mehr als 500 m verändert (z. B. weil das Fahrzeug abgeschleppt worden ist).
Anmerkung: Die Löschbedingung impliziert nicht, dass die C-ITS-Station während dieser Löschungsbedingung dauernd in Betrieb sein oder ihren Betrieb ausdehnen muss.
6.3.2.Verneinung
(71)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
6.4.Aktualisierung
(72)Wurde die zuvor ausgelöste DENM über ein erkanntes Liegengebliebenes Fahrzeug nicht gelöscht, wird alle 15 s die Erzeugung einer Aktualisierungs-DENM ausgelöst.
(73)Während der Aktualisierungsphase werden nur die Auslösebedingungen überprüft (Timer werden nicht weiter ausgewertet).
(74)Wird das Zündterminal 15 von „ein“ auf „aus“ geschaltet, wird sofort eine Aktualisierungs-DENM ausgelöst.
(75)Den Datenfeldern oder Elementen in der DENM werden dem veränderten Ereignis entsprechend neue Werte zugeordnet (z. B. detectionTime [Erkennungszeit] oder informationQuality [InformationsQualität].
Anmerkung: Die Aktualisierungsbedingung impliziert nicht, dass die C-ITS-Station während dieser Aktualisierungsbedingung dauernd in Betrieb sein oder ihren Betrieb ausdehnen muss.
6.5.Wiederholungsdauer und Wiederholungsintervall
(76)DENM, die neu sind, aktualisiert wurden oder gelöscht wurden, werden über eine repetitionDuration [WiederholungsDauer] von 15 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
(77)Ist das Zündterminal 15 eingeschaltet, wird die validityDuration [GültigkeitsDauer] auf 30 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird bei ausgeschaltetem Zündterminal 15 auf einen höheren Wert gesetzt als dies der Fall ist, wenn Zündterminal 15 eingeschaltet ist. Dies ist darauf zurückzuführen, dass eine Aktualisierungs-DENM nicht ausgelöst und nicht mehr gesendet werden kann. Daher wird die letzte DENM länger aktiv gehalten.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
6.6.Verkehrsklasse
(78)Neu-, Aktualisierungs- und Löschungs-DENM werden auf Verkehrsklasse 1 gesetzt.
6.7.Benachrichtigungsparameter
6.7.1.DENM
(79)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 10: DENM-Datenelemente „Warnung vor stehendem Fahrzeug — liegengebliebenes Fahrzeug"
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts – Zeitstempel, bei dem eine Neu-, Aktualisierungs- oder Löschungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird im Fall einer Neu- oder Aktualisierungs-DENM nicht festgesetzt. Wird im Fall einer Löschungs-DENM auf isCancellation(0) [istLöschung(0)] gesetzt.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan1000 m(4) [wenigerAls1000m(4)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
·Zündterminal 15 enabled [eingeschaltet]: 30 s
·Zündterminal 15 disabled [ausgeschaltet]: 900 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [Informationsqualität]
|
Siehe Nummer 67. Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
causeCode
|
stationaryVehicle(94) [stehendesFahrzeug(94)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
FahrzeugPanne(2)
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
Alacarte-Container: StationaryVehicleContainer [ContainerStehendesFahrzeug]
|
|
stationarySince [stehendSeit]
|
Wird entsprechend der Dauer in Minuten, für die die erkennende C-ITS-Station stillsteht, festgesetzt. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
6.7.2.CAM
(80)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
6.8.Netz- und Beförderungsebene
(81)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
6.9.Sicherheitsebene
(82)Treffen die unter Nummer 62 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu-, Aktualisierungs- und Lösch-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu-, Aktualisierungs- und Lösch-DENM werden mit dem gleichen Berechtigungsticket gesendet.
7.Warnung vor stehendem Fahrzeug —nach Zusammenstoß
7.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über ein Fahrzeug, das infolge eines Verkehrsunfalls steht.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
•
„Warnung vor stehendem Fahrzeug — stillstehendes Fahrzeug“;
•
„Warnung vor stehendem Fahrzeug — liegengebliebenes Fahrzeug“.
(83)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu-, Aktualisierungs- oder Lösch-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
7.2.Auslösebedingungen
7.2.1.Voraussetzungen
(84)Für diesen C-ITS-Dienst gelten keine besonderen Voraussetzungen.
(85)Eine Aktivierung parallel mit den anderen verwandten C-ITS-Diensten wird vermieden. Werden die C-ITS-Dienste „stillstehendes Fahrzeug“ und/ oder „liegengebliebenes Fahrzeug“ gleichzeitig ausgelöst, erhalten die C-ITS-Dienste folgende Priorität:
(a)„nach Zusammenstoß“ (höchste Priorität);
(b)„liegengebliebenes Fahrzeug“;
(c)„stillstehendes Fahrzeug“ (geringste Priorität).
7.2.2.Dienstspezifische Bedingungen
(86)Werden die unter Nummer 84 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)ein e-Call ist von einem Insassen des Fahrzeugs manuell über den eCall-Knopf ausgelöst worden und das Fahrzeug hält innerhalb von 15 s an. Steht das Fahrzeug bereits, ist die Bedingung sofort erfüllt.
(b)es wird ein Zusammenstoß geringer Schwere ohne Aktivierung des irreversiblen Insassenrückhaltesystems (z. B. Trennung der Hochspannungsbatterie, Türentriegelung) erkannt und das Fahrzeug hält innerhalb von 15 s an. Steht das Fahrzeug bereits, ist die Bedingung sofort erfüllt.
(c)es wird ein Zusammenstoß mit einem Fußgänger mit Aktivierung von mindestens einem irreversiblen Fußgängerschutzsystem (z. B. Anheben der Motorhaube, Außen-Airbag) erkannt und das Fahrzeug hält innerhalb von 15 s an. Steht das Fahrzeug bereits, ist die Bedingung sofort erfüllt.
(d)es wird ein Zusammenstoß hohen Schweregrades mit Aktivierung von mindestens einem irreversiblen Insassenrückhaltesystems (z. B. pyrotechnischer Gurtstraffer, Airbag) erkannt.
(87)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und des Fahrzeugs erfolgt.
Anmerkung: Die Bedingungen müssen nur dann überprüft werden, wenn die erforderliche Stromversorgung vorhanden ist. Das bedeutet, dass eine zusammenstoßsichere Umsetzung des Systems nicht erforderlich ist.
7.2.3.Qualität der Informationen
(88)Der Wert des Datenelements informationQuality in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 86). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 11: Qualität der Information „stehendes Fahrzeug — nach Zusammenstoß“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (a) ist erfüllt.
|
1
|
|
Bedingung (b) oder (c) ist erfüllt.
|
2
|
|
Bedingung (d) ist erfüllt.
|
3
|
(89)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
7.3.Beendigungsbedingungen
(90)Dieser C-ITS-Dienst wird durch eine Löschung der C-ITS-Station, die ihn erzeugte, beendet. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
7.3.1.Löschung
(91)Sobald mindestens eine der folgenden Bedingungen erfüllt ist, bevor die im Datenelement validityDuration [GültigkeitsDauer] festgesetzte Zeit abgelaufen ist, wird die Erzeugung einer Löschungs-DENM ausgelöst:
(a)das Ego-Fahrzeug steht für die Dauer von 15 s nicht still;
(b)die Position des Fahrzeugs hat sich um mehr als 500 m verändert (z. B. weil das Fahrzeug abgeschleppt worden ist).
Anmerkung: Die Löschbedingung impliziert nicht, dass die C-ITS-Station während dieser Löschungsbedingung dauernd in Betrieb sein oder ihren Betrieb ausdehnen muss.
7.3.2.Verneinung
(92)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
7.4.Aktualisierung
(93)Es wird alle 60 s eine Aktualisierungs-DENM ausgelöst, wenn der C-ITS-Dienst nicht gelöscht worden ist.
(94)Wird das Zündterminal 15 von „ein“ auf „aus“ geschaltet, wird sofort eine Aktualisierungs-DENM ausgelöst.
(95)Den Datenfeldern oder Elementen in der DENM werden dem veränderten Ereignis entsprechend neue Werte zugeordnet (z. B. detectionTime [Erkennungszeit] oder informationQuality [InformationsQualität].
Anmerkung: Die Aktualisierungsbedingung impliziert nicht, dass die C-ITS-Station während dieser Aktualisierungsbedingung dauernd in Betrieb sein oder ihren Betrieb ausdehnen muss.
7.5.Wiederholungsdauer und Wiederholungsintervall
(96)DENM, die neu sind, aktualisiert wurden oder gelöscht wurden, werden über eine repetitionDuration [WiederholungsDauer] von 60 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
(97)Ist das Zündterminal 15 enabled [eingeschaltet], wird die validityDuration [GültigkeitsDauer] auf 180 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird bei ausgeschaltetem Zündterminal 15 auf einen höheren Wert gesetzt als dies der Fall ist, wenn Zündterminal 15 eingeschaltet ist. Dies ist darauf zurückzuführen, dass eine Aktualisierungs-DENM nicht ausgelöst und nicht mehr gesendet werden kann. Daher wird die letzte DENM länger aktiv gehalten.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
7.6.Verkehrsklasse
(98)Neu-, Aktualisierungs- und Löschungs-DENM werden auf Verkehrsklasse 1 gesetzt.
7.7.Benachrichtigungsparameter
7.7.1.DENM
(99)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 12: DENM-Datenelemente von Warnung vor stehendem Fahrzeug —nach Zusammenstoß
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts – Zeitstempel, bei dem eine Neu-, Aktualisierungs- oder Löschungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird im Fall einer Neu- oder Aktualisierungs-DENM nicht festgesetzt. Wird im Fall einer Löschungs-DENM auf isCancellation(0) [istLöschung(0)] gesetzt.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan5km(5) [wenigerAls5km(5)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
·Zündterminal 15 enabled [eingeschaltet]: 180 s
·Zündterminal 15 disabled [ausgeschaltet]: 1 800 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 88. Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
causeCode [UrsachenKennung]
|
stationaryVehicle(94) [stehendesFahrzeug(94)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
postCrash(3) [nachZusammenstoß(3)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
Alacarte-Container: StationaryVehicleContainer [ContainerStehendesFahrzeug]
|
|
stationarySince [stehendSeit]
|
Wird entsprechend der Dauer in Minuten, für die die erkennende C-ITS-Station stillsteht, festgesetzt. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
7.7.2.CAM
(100)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
7.8.Netz- und Beförderungsebene
(101)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
7.9.Sicherheitsebene
(102)Treffen die unter Nummer 86 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu-, Aktualisierungs- und Lösch-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu-, Aktualisierungs- und Lösch-DENM werden mit dem gleichen Berechtigungsticket gesendet.
8.Warnung vor Sonderfahrzeug — Einsatzfahrzeug im Einsatz
8.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über ein Einsatzfahrzeug, das sich zu einem Einsatzort bewegt, was durch den Leuchtbalken signalisiert wird.
(103)Sobald der C-ITS-Dienst ausgelöst worden ist, übermittelt die C-ITS-Station des Einsatzfahrzeugs eine DENM und Teile der CAM-Datenfelder werden wie in Abschnitt 8.7.2 dargelegt eingestellt.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Warnung vor Sonderfahrzeug – stehendes, sicherndes Einsatzfahrzeug“;
·„Warnung vor Sonderfahrzeug – Warnung vor stehendem Bergungsdienst“.
(104)Der voreingestellte C-ITS-Dienst für die C-ITS-Station von Einsatzfahrzeugen ist „Einsatzfahrzeug im Einsatz“. Ein Wechsel zum C-ITS-Dienst „stehendes, sicherndes Einsatzfahrzeug“ wird nur unter den in Abschnitt 9 dargelegten Bedingungen ausgelöst.
8.2.Auslösebedingungen
8.2.1.Voraussetzungen
(105)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
(a)der stationType [StationsTyp] wird als Sonderfahrzeug bestätigt (stationType von CAM ist auf specialVehicles(10) [Sonderfahrzeuge] gesetzt); der C-ITS-Dienst ist auf Einsatzfahrzeuge beschränkt;
(b)die Auslösebedingungen bezüglich „stehendes, sicherndes Einsatzfahrzeug“ sind nicht erfüllt (siehe Abschnitt 9.2).
8.2.2.Dienstspezifische Bedingungen
(106)Werden die unter Nummer 105 genannten Voraussetzungen und die folgenden Bedingungen erfüllt, wird die Erzeugung einer DENM ausgelöst:
(a)der Leuchtbalken ist in Betrieb.
(107)Das Niveau der Informationsqualität kann durch die folgenden Bedingungen erhöht werden:
(b)die Sirene ist in Betrieb;
(c)das Fahrzeug steht nicht.
(108)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet.
8.2.3.Qualität der Informationen
(109)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummern 106 und 107). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 13: Qualität der Information „Einsatzfahrzeug im Einsatz“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (a) ist erfüllt
|
1
|
|
Die Bedingungen (a) und (b) sind erfüllt
|
2
|
|
Die Bedingungen (a) und (c) sind erfüllt
|
3
|
|
Die Bedingungen (a), (b) und (c) sind erfüllt
|
4
|
(110)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
8.3.Beendigungsbedingungen
(111)Der C-ITS-Dienst wird beendet, wenn der Leuchtbalken nicht mehr in Betrieb ist. Mit der Beendigung des C-ITS-Dienstes wird auch die Aktualisierung der DENM beendet. Die vehicleRole [FahrzeugFunktion] wird auf default(0) [Grundwert(0)] gesetzt, wenn der Leuchtbalken nicht mehr in Betrieb ist.
8.3.1.Löschung
(112)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
8.3.2.Verneinung
(113)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
8.4.Aktualisierung
(114)Die erzeugte DENM wird alle 250 ms aktualisiert, wenn die Auslösebedingungen immer noch erfüllt werden. Den Datenfeldern werden entsprechend der Definition in der folgenden Tabelle 14 neue Werte zugeordnet.
8.5.Wiederholungsdauer und Wiederholungsintervall
(115)Für diesen C-ITS-Dienst wird keine Wiederholung der DENM verwendet.
8.6.Verkehrsklasse
(116)Neu-, Aktualisierungs- und Löschungs-DENM werden auf Verkehrsklasse 1 gesetzt.
8.7.Benachrichtigungsparameter
8.7.1.DENM
(117)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 14: DENM-Datenelemente von „Einsatzfahrzeug im Einsatz“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan1000 m(4) [wenigerAls1000m(4)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
2 s
|
|
stationType [StationsTyp]
|
specialVehicles(10) [Sonderfahrzeuge(10)]
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 109. Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
causeCode [UrsachenKennung]
|
emergencyVehicleApproaching(95) [sichnäherndesEinsatzfahrzeug(95)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
emergencyVehicleApproaching(1) [sichnäherndesEinsatzfahrzeug(95)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
i
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
Alacarte-Container: StationaryVehicleContainer [ContainerStehendesFahrzeug]
|
|
stationarySince [stehendSeit]
|
Wird entsprechend der Dauer in Minuten, für die die erkennende C-ITS-Station stillsteht, festgesetzt. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
8.7.2.CAM
(118)Die vehicleRole [FahrzeugFunktion] wird mit einer Grundeinstellung initialisiert (vehicleRole von CAM wird auf default(0) [Grundwert(0)] gesetzt). Wird mindestens eine der Auslösebedingungen unter Nummer 106 erfüllt, wird die vehicleRole [FahrzeugFunktion] auf Einsatz(6) gesetzt.
(119)In der folgenden Tabelle werden die Datenelemente von CAM spezifiziert, die beim Auslösen des C-ITS-Dienstes festzusetzen sind.
Tabelle 15: CAM-Datenelemente von „Einsatzfahrzeug im Einsatz“
|
Datenfeld
|
Wert
|
|
CoopAwareness [kooperative Sensibilisierung]
|
|
generationDeltaTime [Deltazeit der Erzeugung]
|
Zeitpunkt, der der Zeit der Referenzposition in der CAM entspricht und als Zeit der CAM-Erzeugung betrachtet wird.
|
|
|
Wird gemäß [EN 302 637-2] festgesetzt.
|
|
BasicContainer
|
|
stationType [StationsTyp]
|
specialVehicles(10) [Sonderfahrzeuge(10)]
|
|
ReferencePosition [ReferenzPosition]
|
Die am Referenzpunkt der erzeugenden C-ITS-Station gemessene Position und Positionsgenauigkeit.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Der HighFrequencyContainer [Hochfrequenzcontainer] wird auf die BasicVehicleContainerHighFrequency [Hochfrequenz des Basisfahrzeugcontainers] gesetzt
|
|
heading [Kurs]
|
Kursrichtung der erzeugenden C-ITS-Station im Verhältnis zum geografischen Norden.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
speed [Geschwindigkeit]
|
Fahrgeschwindigkeit der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
driveDirection [Fahrtrichtung]
|
Fahrtrichtung des Fahrzeugs (vorwärts oder rückwärts) der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleLength [FahrzeugLänge]
|
Länge des Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleWidth [FahrzeugBreite]
|
Breite des Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
longitudinalAcceleration [LängsBeschleunigung]
|
Längsbeschleunigung des Fahrzeugs mit der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
curvature [Bogen]
|
Bogen des Fahrprofils des Fahrzeugs und Genauigkeit.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
curvatureCalcMode [Berechnungsmethode für den Bogen]
|
Beschreibt, ob zur Berechnung des Bogens für einen gemeldeten Bogenwert die Giergeschwindigkeit verwendet wird.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
yawRate [GierGeschwindigkeit]
|
Giergeschwindigkeit des Fahrzeugs zu einem bestimmten Zeitpunkt.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Der LowFrequencyContainer [Niederfrequenzcontainer] wird auf die BasicVehicleContainerLowFrequency [Niederfrequenz des Basisfahrzeugcontainers] gesetzt
|
|
vehicleRole [FahrzeugFunktion]
|
Einsatz(6)
|
|
exteriorLights [AußenBeleuchtung]
|
Beschreibt den Status der Außenbeleuchtungsschalter eines Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
pathHistory [StreckenHistorie]
|
Stellt die Bewegung des Fahrzeugs in einem kurz zurückliegenden Zeitraum und/oder über eine kurz zurückliegende Strecke dar.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
SpecialVehicleContainer [SonderfahrzeugContainer] wird auf EmergencyContainer [EinsatzContainer] gesetzt.
|
|
lightBarSirenInUse [LeuchtbalkenSireneInBetrieb]
|
Das Bit LeuchtbalkenAktiviert wird auf 1 (einÄnderung) gesetzt, wenn erkannt wird, dass der Leuchtbalken in Betrieb ist; andernfalls wird es auf 0 gesetzt.
|
|
|
Das Bit SireneAktiviert wird auf 1 gesetzt, wenn erkannt wird, dass die Sirene in Betrieb ist; andernfalls wird es auf 0 gesetzt.
|
|
emergencyPriority [Priorität für Einsatz]
|
Ist nicht erforderlich
|
|
causeCode [UrsachenKennung]
|
Gemäß Spezifikation unter Nummer 117
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
Gemäß Spezifikation unter Nummer 117
|
8.8.Netz- und Beförderungsebene
(120)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
8.9.Sicherheitsebene
(121)Treffen die unter Nummer 106 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu- und Aktualisierungs-DENM werden mit demselben Berechtigungsticket gesendet.
9.Warnung vor Sonderfahrzeug – stehendes, sicherndes Einsatzfahrzeug
9.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über ein stehendes Einsatzfahrzeug in einem Gefahrenbereich.
(122)Sobald der C-ITS-Dienst ausgelöst worden ist, übermittelt die C-ITS-Station des Einsatzfahrzeugs eine DENM und Teile der CAM-Datenfelder werden wie in Abschnitt 9.7.2 dargelegt eingestellt.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Warnung vor Sonderfahrzeug — Einsatzfahrzeug im Einsatz“;
·„Warnung vor Sonderfahrzeug – Warnung vor stehendem Bergungsdienst“.
9.2.Auslösebedingungen
9.2.1.Voraussetzungen
(123)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
·der stationType [StationsTyp] wird als Einsatzfahrzeug bestätigt (stationType von CAM ist auf specialVehicles(10) [Sonderfahrzeuge]) gesetzt. der C-ITS-Dienst ist auf Einsatzfahrzeuge beschränkt;
·der Standstill Timer [Stillstand-Timer] wird mit Null initialisiert.
(124)Der voreingestellte C-ITS-Dienst für die C-ITS-Station von Einsatzfahrzeugen ist „Einsatzfahrzeug im Einsatz“. Ein Wechsel zum C-ITS-Dienst „stehendes, sicherndes Einsatzfahrzeug“ wird nur unter den in Abschnitt 9.2.2 festgelegten Bedingungen ausgelöst.
9.2.2.Dienstspezifische Bedingungen
(125)Steht das Fahrzeug und ist der Leuchtbalken in Betrieb, wird ein Standstill Timer mit Null initialisiert und gestartet. Ist der Leuchtbalken nicht mehr in Betrieb oder steht das Fahrzeug nicht mehr, wird der Standstill Timer gestoppt und auf Null zurückgesetzt.
(126)Werden die unter Nummer 123 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)der Leuchtbalken ist in Betrieb und das Motorrelais ist aktiviert;
(b)der Leuchtbalken ist in Betrieb, die Warnblinklampen sind eingeschaltet und die Parkbremse ist aktiviert bzw. (bei einem Automatikgetriebe) ist „Parken“ ausgewählt worden;
(c)der Leuchtbalken ist in Betrieb, die Warnblinklampen sind eingeschaltet und der Standstill Timer steht auf 60 s oder mehr.
(127)Das Niveau der Informationsqualität kann durch die folgenden Bedingungen erhöht werden:
(d)der Status von mindestens einer Tür oder des Kofferraums ist „offen“;
(e)der Fahrersitz wird mittels einer der folgenden Techniken als „nicht besetzt“ erkannt:
(1)Kamera im Fahrzeuginnenraum;
(2)dem neuesten Stand entsprechende Technik für Sitzbelegungserkennung, die für die Erinnerungsfunktion der Sicherheitsgurte eingesetzt wird.
(128)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und des Fahrzeugs erfolgt.
(129)Wird der C-ITS-Dienst aufgrund der Erfüllung der Bedingung (a) oder (b) unter Nummer (126) ausgelöst, wird der Standstill Timer angehalten und auf 60 s gesetzt. Während der Aktualisierungsphase werden nur die Auslösebedingungen überprüft, aber keine Timer gestartet.
9.2.3.Qualität der Informationen
(130)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummern 126 und 127). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 16: Qualität der Information „stehendes, sicherndes Einsatzfahrzeug“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (c) erfüllt
|
1
|
|
Bedingung (b) erfüllt
|
2
|
|
Mindestens eine der Bedingungen (b) oder (c) ist erfüllt und Bedingung (d) ist erfüllt
|
3
|
|
Mindestens eine der Bedingungen (b) oder (c) ist erfüllt und Bedingung (e) ist erfüllt
|
4
|
|
Bedingung (a) erfüllt
|
5
|
(131)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
9.3.Beendigungsbedingungen
(132)Dieser C-ITS-Dienst wird durch eine Löschung der C-ITS-Station, die ihn erzeugte, beendet. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
9.3.1.Löschung
(133)Wird die folgende Bedingung erfüllt, bevor die im Datenelement validityDuration [GültigkeitsDauer] festgesetzte Zeit abgelaufen ist, wird die Erzeugung einer Löschungs-DENM ausgelöst:
(a)keine der für den C-ITS-Dienst spezifischen Bedingungen (a) bis (c) in Abschnitt 9.2.2 wird mehr erfüllt.
Die vehicleRole [FahrzeugFunktion] wird auf default(0) [Grundwert(0)] gesetzt, wenn der Leuchtbalken nicht mehr in Betrieb ist.
9.3.2.Verneinung
(134)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
9.4.Aktualisierung
(135)Die erzeugte DENM wird alle 60 s aktualisiert, wenn die Auslösebedingungen immer noch erfüllt werden. Alle Datenfelder, denen neue Werte zugewiesen werden, sind in der folgenden Tabelle 17 aufgeführt.
9.5.Wiederholungsdauer und Wiederholungsintervall
(136)DENM, die neu sind, aktualisiert wurden oder gelöscht wurden, werden über eine repetitionDuration [WiederholungsDauer] von 60 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird auf 180 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
9.6.Verkehrsklasse
(137)Neu-, Aktualisierungs- und Löschungs-DENM werden auf Verkehrsklasse 1 gesetzt.
9.7.Benachrichtigungsparameter
9.7.1.DENM
(138)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 17: DENM-Datenelemente von „stehendes, sicherndes Einsatzfahrzeug“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts – Zeitstempel, bei dem eine Neu-, Aktualisierungs- oder Löschungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird im Fall einer Neu- oder Aktualisierungs-DENM nicht festgesetzt. Wird auf isCancellation(0) [istLöschung(0)] gesetzt, wenn die Löschbedingungen erfüllt sind; Siehe Nummer 133.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan5km(5) [wenigerAls5km(5)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)]) gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
180 s
|
|
stationType [StationsTyp]
|
specialVehicles(10) [Sonderfahrzeuge(10)]
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 130. Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
causeCode [UrsachenKennung]
|
rescueAndRecoveryWorkInProgress(15)
[laufendeRettungs-UndBergungsarbeiten(15)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
emergencyVehicles(1) [Einsatzfahrzeuge(1)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die Fahrstreifenposition unbekannt, wird das Datenelement ausgelassen.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
Alacarte-Container: StationaryVehicleContainer [ContainerStehendesFahrzeug]
|
|
stationarySince [stehendSeit]
|
Wird entsprechend der Dauer in Minuten, für die die erkennende C-ITS-Station stillsteht, festgesetzt. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
9.7.2.CAM
(139)Die vehicleRole [FahrzeugFunktion] wird mit einer Grundeinstellung initialisiert (vehicleRole von CAM wird auf default(0) [Grundwert(0)] gesetzt). Wird mindestens eine der Auslösebedingungen unter Nummer 126 erfüllt, wird die vehicleRole [FahrzeugFunktion] auf Einsatz(6) gesetzt.
(140)In der folgenden Tabelle werden die Datenelemente von CAM spezifiziert, die beim Auslösen des C-ITS-Dienstes festzusetzen sind.
Tabelle 18: CAM-Datenelemente von „stehendes, sicherndes Einsatzfahrzeug“
|
Datenfeld
|
Wert
|
|
CoopAwareness [kooperative Sensibilisierung]
|
|
generationDeltaTime [Deltazeit der Erzeugung]
|
Zeitpunkt, der der Zeit der Referenzposition in der CAM entspricht und als Zeit der CAM-Erzeugung betrachtet wird.
|
|
|
Wird gemäß [EN 302 637-2] festgesetzt.
|
|
BasicContainer
|
|
stationType [StationsTyp]
|
specialVehicles(10) [Sonderfahrzeuge(10)]
|
|
ReferencePosition [ReferenzPosition]
|
Die am Referenzpunkt der erzeugenden C-ITS-Station gemessene Position und Positionsgenauigkeit.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Der HighFrequencyContainer [Hochfrequenzcontainer] wird auf die BasicVehicleContainerHighFrequency [Hochfrequenz des Basisfahrzeugcontainers] gesetzt
|
|
heading [Kurs]
|
Kursrichtung der erzeugenden C-ITS-Station im Verhältnis zum geografischen Norden.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
speed [Geschwindigkeit]
|
Fahrgeschwindigkeit der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
driveDirection [Fahrtrichtung]
|
Fahrtrichtung des Fahrzeugs (vorwärts oder rückwärts) der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleLength [FahrzeugLänge]
|
Länge des Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleWidth [FahrzeugBreite]
|
Breite des Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
longitudinalAcceleration [LängsBeschleunigung]
|
Längsbeschleunigung des Fahrzeugs mit der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
curvature [Bogen]
|
Bogen des Fahrprofils des Fahrzeugs und Genauigkeit.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
curvatureCalcMode [Berechnungsmethode für den Bogen]
|
Beschreibt, ob zur Berechnung des Bogens für einen gemeldeten Bogenwert die Giergeschwindigkeit verwendet wird.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
yawRate [GierGeschwindigkeit]
|
Giergeschwindigkeit des Fahrzeugs zu einem bestimmten Zeitpunkt.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Der LowFrequencyContainer [Niederfrequenzcontainer] wird auf die BasicVehicleContainerLowFrequency [Niederfrequenz des Basisfahrzeugcontainers] gesetzt
|
|
vehicleRole [FahrzeugFunktion]
|
emergency(6) [Einsatz(6)]
|
|
exteriorLights [AußenBeleuchtung]
|
Beschreibt den Status der Außenbeleuchtungsschalter eines Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
pathHistory [StreckenHistorie]
|
Stellt die Bewegung des Fahrzeugs in einem kurz zurückliegenden Zeitraum und/oder über eine kurz zurückliegende Strecke dar.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
SpecialVehicleContainer [SonderfahrzeugContainer] wird auf EmergencyContainer [EinsatzContainer] gesetzt.
|
|
lightBarSirenInUse [LeuchtbalkenSireneInBetrieb]
|
Das Bit lightBarActivated [LeuchtbalkenAktiviert] wird auf 1 (onChange) [einÄnderung] gesetzt, wenn erkannt wird, dass der Leuchtbalken in Betrieb ist, andernfalls wird es auf 0 gesetzt.
|
|
|
Das Bit sirenActivated [SireneAktiviert] wird auf 1 gesetzt, wenn erkannt wird, dass die Sirene in Betrieb ist, andernfalls wird es auf 0 gesetzt.
|
|
emergencyPriority [Priorität für Einsatz]
|
Ist nicht erforderlich.
|
|
causeCode [UrsachenKennung]
|
Gemäß Spezifikation unter Nummer 138
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
Gemäß Spezifikation unter Nummer 138
|
9.8.Netz- und Beförderungsebene
(141)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
9.9.Sicherheitsebene
(142)Treffen die unter Nummer 126 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu-, Aktualisierungs- und Lösch-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu-, Aktualisierungs- und Lösch-DENM werden mit dem gleichen Berechtigungsticket gesendet.
10.Warnung vor Sonderfahrzeug – Warnung vor stehendem Bergungsdienst“
10.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über ein Bergungsdienstfahrzeug, das einem liegengebliebenen Fahrzeug Unterstützung leistet. Der C-ITS-Dienst des sich bewegenden Bergungsdienstes, z. B. eines Transporters mit einem liegengebliebenen Fahrzeug, wird durch die CAM abgedeckt.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Warnung vor Sonderfahrzeug — Einsatzfahrzeug im Einsatz“;
·„Warnung vor Sonderfahrzeug – stehendes, sicherndes Einsatzfahrzeug“.
10.2.Auslösebedingungen
10.2.1.Voraussetzungen
(143)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
·der stationType [StationsTyp] wird als Einsatzfahrzeug bestätigt (stationType von CAM ist auf specialVehicles (10))[Sonderfahrzeuge] gesetzt. Der C-ITS-Dienst ist auf Fahrzeuge von Bergungsdiensten beschränkt;
·der Standstill Timer [Stillstand-Timer] wird mit Null initialisiert.
10.2.2.Dienstspezifische Bedingungen
(144)Steht das Fahrzeug und ist der Leuchtbalken in Betrieb, wird ein Standstill Timer mit Null initialisiert und gestartet. Ist der Leuchtbalken nicht mehr in Betrieb oder steht das Fahrzeug nicht mehr, wird der Standstill Timer gestoppt und auf Null zurückgesetzt.
(145)Werden die unter Nummer 143 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)der Leuchtbalken ist in Betrieb, die Warnblinklampen sind eingeschaltet und die Parkbremse ist aktiviert bzw. (bei einem Automatikgetriebe) ist „Parken“ ausgewählt worden;
(b)der Leuchtbalken ist in Betrieb, die Warnblinklampen sind eingeschaltet und der Standstill Timer steht auf 60 s oder mehr.
(146)Das Niveau der Informationsqualität kann durch die folgenden Bedingungen erhöht werden:
(c)der Status der Fahrertür ist „offen“;
(d)der Fahrersitz wird mittels einer der folgenden Techniken als „nicht besetzt“ erkannt:
(1)Kamera im Fahrzeuginnenraum;
(2)dem neuesten Stand entsprechende Technik für Sitzbelegungserkennung, die für die Erinnerungsfunktion der Sicherheitsgurte eingesetzt wird.
(147)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet. Diese Anforderung gilt für alle folgenden Gelegenheiten, in denen eine Analyse der Geschwindigkeit und des Fahrzeugs erfolgt.
(148)Wird der C-ITS-Dienst aufgrund der Erfüllung der Bedingung (a) unter Nummer (145) ausgelöst, wird der Standstill Timer angehalten und auf 60 s gesetzt. Während der Aktualisierungsphase werden nur die Auslösebedingungen überprüft, aber keine Timer gestartet.
10.2.3.Qualität der Informationen
(149)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummern 145 und 146). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 19: Qualität der Information „Warnung vor stehendem Bergungsdienst“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (b) erfüllt
|
1
|
|
Bedingung (a) erfüllt
|
2
|
|
Mindestens eine der Bedingungen (a) oder (b) erfüllt und Bedingung (c) erfüllt
|
3
|
|
Mindestens eine der Bedingungen (a) oder (b) erfüllt und Bedingung (d) erfüllt
|
4
|
(150)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
10.3.Beendigungsbedingungen
(151)Dieser C-ITS-Dienst wird durch eine Löschung der C-ITS-Station, die ihn erzeugte, beendet. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
10.3.1.Löschung
(152)Wird die folgende Bedingung erfüllt, bevor der im Datenelement validityDuration [GültigkeitsDauer] festgesetzte Zeitraum abgelaufen ist, wird die Erzeugung einer Löschungs-DENM ausgelöst und die vehicleRole [FahrzeugFunktion] wird auf default(0) [Grundwert(0)] gesetzt:
(a)die für den C-ITS-Dienst spezifischen Bedingungen (a) und (b) unter Nummer 145 werden nicht erfüllt.
10.3.2.Verneinung
(153)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
10.4.Aktualisierung
(154)Die erzeugte DENM wird alle 60 s aktualisiert, wenn die Auslösebedingungen immer noch erfüllt werden. Alle Datenfelder, denen neue Werte zugewiesen werden, sind in der folgenden Tabelle 20 aufgeführt.
10.5.Wiederholungsdauer und Wiederholungsintervall
(155)DENM, die neu sind, aktualisiert wurden oder gelöscht wurden, werden über eine repetitionDuration [WiederholungsDauer] von 60 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird auf 180 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
10.6.Verkehrsklasse
(156)Neu-, Aktualisierungs- und Löschungs-DENM werden auf Verkehrsklasse 1 gesetzt.
10.7.Benachrichtigungsparameter
10.7.1.DENM
(157)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 20: DENM-Datenelemente von „Warnung vor stehendem Bergungsdienst“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts – Zeitstempel, bei dem eine Neu-, Aktualisierungs- oder Löschungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird im Fall einer Neu- oder Aktualisierungs-DENM nicht festgesetzt. Wird auf isCancellation(0) [istLöschung(0)] gesetzt, wenn die Löschbedingungen erfüllt werden, siehe Nummer 152.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan5km(5) [wenigerAls5km(5)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
180 s
|
|
stationType [StationsTyp]
|
specialVehicles(10) [Sonderfahrzeuge(10)]
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 149. Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
causeCode [UrsachenKennung]
|
rescueAndRecoveryWorkInProgress(15) [laufendeRettungs-UndBergungsarbeiten(15)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 8942] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [KursDerEreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
|
|
|
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
|
|
|
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
Alacarte-Container: StationaryVehicleContainer [ContainerStehendesFahrzeug]
|
|
stationarySince [stehendSeit]
|
Wird entsprechend der Dauer in Minuten, für die die erkennende C-ITS-Station stillsteht, festgesetzt. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
10.7.2.CAM
(158)Die vehicleRole [FahrzeugFunktion] wird mit einer Grundeinstellung initialisiert (vehicleRole von CAM wird auf default(0) [Grundwert(0)] gesetzt). Wird mindestens eine der Auslösebedingungen unter Nummer 145 erfüllt, wird die vehicleRole [FahrzeugFunktion] auf rescue(5) [Rettung(5)] gesetzt.
(159)In der folgenden Tabelle werden die Datenelemente von CAM spezifiziert, die beim Auslösen des C-ITS-Dienstes festzusetzen sind.
Tabelle 21: DENM-Datenelemente von „Warnung vor stehendem Bergungsdienst“
|
Datenfeld
|
Wert
|
|
CoopAwareness [kooperative Sensibilisierung]
|
|
generationDeltaTime [Deltazeit der Erzeugung]
|
Zeitpunkt, der der Zeit der Referenzposition in der CAM entspricht und als Zeit der CAM-Erzeugung betrachtet wird.
|
|
|
Wird gemäß [EN 302 637-2] festgesetzt.
|
|
BasicContainer
|
|
stationType [StationsTyp]
|
specialVehicles(10) [Sonderfahrzeuge(10)]
|
|
ReferencePosition [ReferenzPosition]
|
Die am Referenzpunkt der erzeugenden C-ITS-Station gemessene Position und Positionsgenauigkeit.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Der HighFrequencyContainer [Hochfrequenzcontainer] wird auf die BasicVehicleContainerHighFrequency [Hochfrequenz des Basisfahrzeugcontainers] gesetzt
|
|
heading [Kurs]
|
Kursrichtung der erzeugenden C-ITS-Station im Verhältnis zum geografischen Norden.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
speed [Geschwindigkeit]
|
Fahrgeschwindigkeit der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
driveDirection [Fahrtrichtung]
|
Fahrtrichtung des Fahrzeugs (vorwärts oder rückwärts) der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleLength [FahrzeugLänge]
|
Länge des Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleWidth [FahrzeugBreite]
|
Breite des Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
longitudinalAcceleration [LängsBeschleunigung]
|
Längsbeschleunigung des Fahrzeugs mit der C-ITS-Station, von der die Meldung ausgeht.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
curvature [Bogen]
|
Bogen des Fahrprofils des Fahrzeugs und Genauigkeit.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
curvatureCalcMode [Berechnungsmethode für den Bogen]
|
Beschreibt, ob zur Berechnung des Bogens für einen gemeldeten Bogenwert die Giergeschwindigkeit verwendet wird.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
yawRate [GierGeschwindigkeit]
|
Giergeschwindigkeit des Fahrzeugs zu einem bestimmten Zeitpunkt.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Der LowFrequencyContainer [Niederfrequenzcontainer] wird auf die BasicVehicleContainerLowFrequency [Niederfrequenz des Basisfahrzeugcontainers] gesetzt
|
|
vehicleRole [FahrzeugFunktion]
|
rescue(5) [Rettung(5)]
|
|
exteriorLights [AußenBeleuchtung]
|
Beschreibt den Status der Außenbeleuchtungsschalter eines Fahrzeugs.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
pathHistory [StreckenHistorie]
|
Stellt die Bewegung des Fahrzeugs in einem kurz zurückliegenden Zeitraum und/oder über eine kurz zurückliegende Strecke dar.
|
|
|
Wird gemäß [TS 102 894-2] festgesetzt.
|
|
SpecialVehicleContainer [SonderfahrzeugContainer] wird auf SafetyCarContainer [SicherungsfahrzeugContainer] gesetzt
|
|
lightBarSirenInUse [LeuchtbalkenSireneInBetrieb]
|
Das Bit LeuchtbalkenAktiviert wird auf 1 (einÄnderung) gesetzt, wenn erkannt wird, dass der Leuchtbalken in Betrieb ist; andernfalls wird es auf 0 gesetzt.
|
|
|
Das Bit SireneAktiviert wird auf 1 gesetzt, wenn erkannt wird, dass die Sirene in Betrieb ist; andernfalls wird es auf 0 gesetzt.
|
|
causeCode [UrsachenKennung]
|
Gemäß Spezifikation unter Nummer 157
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
Gemäß Spezifikation unter Nummer 157
|
10.8.Netz- und Beförderungsebene
(160)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
10.9.Sicherheitsebene
(161)Treffen die unter Nummer 145 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu-, Aktualisierungs- und Lösch-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu-, Aktualisierungs- und Lösch-DENM werden mit dem gleichen Berechtigungsticket gesendet.
11.Austausch von IRC — Anforderung von IRC
11.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über kritische Fahrsituationen, in denen ein Zusammenstoß zwischen zwei Fahrzeugen wahrscheinlich oder unvermeidbar ist. Das Ego-Fahrzeug erkennt eine potenzielle Kollision und sendet seinen eigenen IRC [Aufprallreduzierungscontainer], um als Antwort den IRC des Kollisionsgegners zu erhalten.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Austausch von IRC — Antwort IRC“;
(162)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
11.2.Auslösebedingungen
11.2.1.Voraussetzungen
(163)Für diesen C-ITS-Dienst gelten keine besonderen Voraussetzungen.
11.2.2.Dienstspezifische Bedingungen
(164)Werden beide folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)die vom Algorithmus eines an Bord befindlichen Messgeräts errechnete Time to Collision (TTC) [Zeit bis zur Kollision] beträgt < 1,5 s. Die akzeptable Toleranz für den errechneten TTC-Wert beträgt 10 %;
(b)die relative Geschwindigkeit zwischen zwei potenziellen Kollisionsgegnern übersteigt 20 km/h.
Anmerkung: Die Berechnung der „Zeit bis zur Kollision“ (TTC) nur auf der Grundlage der GNSS-Position, die von den dem Stand der Technik entsprechenden GNSS-Empfängern übermittelt wird, ist für diesen Dienst nicht zuverlässig genug.
11.2.3.Qualität der Informationen
(165)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird. Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 22: Qualität der Information „Austausch von IRC — Anforderung von IRC“
|
Ereigniserkennung
|
Wert von InformationQuality
[InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
in sonstigen Fällen
|
1
|
11.3.Beendigungsbedingungen
(166)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
11.3.1.Löschung
(167)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
11.3.2.Verneinung
(168)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
11.4.Aktualisierung
(169)Für diesen C-ITS-Dienst wird keine Aktualisierungs-DENM verwendet.
11.5.Wiederholungsdauer und Wiederholungsintervall
(170)Neue DENM werden über eine repetitionDuration [WiederholungsDauer] von 300 ms (100 ms dreimal hintereinander) in einem repetitionInterval [WiederholungsIntervall] von 100 ms wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Da nicht garantiert ist, dass ein gesendeter IRC den Empfänger erreicht (z. B. aufgrund von Kanalbelastung, vorübergehendem Verlassen des Sendebereichs usw.) sendet der Sender den IRC dreimal hintereinander. Dies entspricht einer repetitionDuration [WiederholungsDauer] von 300 ms.
Anmerkung: Die geschätzte Dauer der Übermittlung (Anwendung zu Anwendung) eines IRC (Wiederholung nicht eingeschlossen) über das Automobil-WLAN beträgt 200300 ms. Wird in beiden Fällen (Anforderung und Antwort) nur der dritte Versuch empfangen (Schlimmstfall), steht die Informationen beiden Fahrzeugen nach 1 Sekunde zur Verfügung (2 * (300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz))). Aus diesem Grund ist der Auslöseparameter TTC < 1,5 s ausreichend. Das dreimalige Senden des IRC wird als guter Kompromiss zwischen Kanalbelastung und Sicherstellung einer erfolgreichen Übertragung angesehen.
Anmerkung: Nur die erste DENM wird ohne Beschränkungen im Rahmen der Decentralized Congestion Control (DCC) [dezentrale Stausteuerung] gesendet. Die zweite und dritte DENM können von der dezentralen Stausteuerung (DCC) (auf der Grundlage der aktuellen Kanalbelastung) betroffen sein.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
11.6.Verkehrsklasse
(171)Neue DENM werden auf traffic class [Verkehrsklasse] 0 festgelegt.
11.7.Benachrichtigungsparameter
11.7.1.DENM
(172)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 23: DENM-Datenelemente von „Austausch von IRC — Anforderung von IRC“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts - Zeitstempel, bei dem eine neue DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan100 m(1) [wenigerAls100m(1)]
Anmerkung: Dies deckt auch das Schlimmstfallszenario ab, dass mit nahezu 250 km/h auf ein gefährliches Stauende zugefahren wird (s = v*t = 69,4 m/s * 1,5 s = 104,2 m).
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
validityDuration [GültigkeitsDauer]
|
2 s
Anmerkung: Ist größer als TTC (Zeit bis zur Kollision).
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 165.
|
|
causeCode [UrsachenKennung]
|
collisionRisk(97) [KollisionsRisiko(97)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
roadType [StraßenTyp]
|
Wird gemäß [TS 102 894-2] festgesetzt. Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container: ImpactReductionContainer [AufprallReduzierungsContainer] (IRC)
|
|
heightLonCarrLeft
[HöheLinkerLängsträger]
|
Höhe des linken Längsträgers des Fahrzeugs von der Unter- bis zur Oberkante. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
heightLonCarrRight
[HöheRechterLängsträger]
|
Höhe des rechten Längsträgers des Fahrzeugs von der Unter- bis zur Oberkante. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
posLonCarrLeft [PositionLängsträgerLinks]
|
Längsabstand zwischen der Mitte des vorderen Stoßfängers des Fahrzeugs und der Vorderkante des linken Längsträgers des Fahrzeugs. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
posLonCarrRight [PositionLängsträgerRechte]
|
Längsabstand zwischen der Mitte des vorderen Stoßfängers des Fahrzeugs und der Vorderkante des rechten Längsträgers des Fahrzeugs. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
positionOfPillars [PositionDerSäulen]
|
Unter Fahrzeugsäulen werden die senkrechten oder nahezu senkrechten Stützen des Fahrzeugs verstanden, die als A-, B-, C- oder D-Säule bezeichnet werden. Sie werden gemäß [TS 102 894-2] festgesetzt.
|
|
posCentMass [PositionMassezentrum]
|
Lotrechter Abstand vom Zentrum der Masse eines Fahrzeugs mit Leerlast bis zur vorderen Linie des Fahrzeugbegrenzungsrechtecks. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
wheelBaseVehicle [RadstandFahrzeug]
|
Lotrechter Abstand zwischen der Vorder- und Hinterachse des Radstandes des Fahrzeugs. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
turningRadius [Wendekreis]
|
Die kleinste kreisförmige Drehung (d. h. Wende), die das Fahrzeug durchführen kann. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
posFrontAx [PositionVorderachse]
|
Lotrechter Abstand zwischen der vorderen Linie des Fahrzeugbegrenzungsrechtecks und der Vorderachse. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
positionOfOccupants [PositionDerInsassen]
|
BitSTring, der anzeigt, ob ein Fahrgastsitz belegt ist bzw. ob der Belegungsstatus erkennbar ist. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleMass [FahrzeugMasse]
|
Masse eines Fahrzeugs mit Leerlast. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
requestResponseIndication [AnforderungAntwortAngabe]
|
request(0) [Anforderung(0)]
|
11.7.2.CAM
(173)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
11.8.Netz- und Beförderungsebene
(174)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
11.9.Sicherheitsebene
(175)Gelten die unter Nummer 164 beschriebenen Auslösebedingungen, wird ein Wechsel des Berechtigungstickets (AT) blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist.
12.„Austausch von IRC — Antwort IRC“
12.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über kritische Fahrsituationen, in denen ein Zusammenstoß zwischen zwei Fahrzeugen wahrscheinlich oder unvermeidbar ist. Das Ego-Fahrzeug hat von einem anderen Fahrzeug einen IRC empfangen und sendet als Antwort darauf seinen eigenen IRC.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Austausch von IRC — Anforderung von IRC“.
(176)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
12.2.Auslösebedingungen
12.2.1.Voraussetzungen
(177)Es ist ein IRC gemäß Beschreibung in Tabelle 23 empfangen worden.
12.2.2.Dienstspezifische Bedingungen
(178)Werden die unter Nummer 177 genannte Voraussetzung und beide folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)requestResponseIndication [AnforderungAntwortAngabe] im empfangenen IRC ist auf request(0) [Anforderung(0)] gesetzt;
(b)der lotrechte Abstand zwischen dem anfordernden Fahrzeug (Ereignisposition im IRC) und dem Ego-Fahrzeug (Referenzposition gemäß Festlegung in der CAM) ist kleiner als 100 m.
Anmerkung: Wird ein IRC empfangen, muss der Empfänger vor der Beantwortung mit seinem eigenen IRC prüfen, ob er tatsächlich angefordert worden ist. Dies kann auf der Grundlage der requestResponseIndication [AnforderungAntwortAngabe] erfolgen. Um eine unnötige Belastung des Übertragungskanals durch mehrfach übermittelte IRC zu vermeiden, antworten nur Fahrzeuge in der unmittelbaren Nähe (innerhalb von 100 m) auf die Anforderung.
12.2.3.Qualität der Informationen
(179)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird. Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 24: Qualität der Information „Austausch von IRC — Antwort IRC“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
unbekannt(0)
|
|
in sonstigen Fällen
|
1
|
12.3.Beendigungsbedingungen
(180)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
12.3.1.Löschung
(181)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
12.3.2.Verneinung
(182)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
12.4.Aktualisierung
(183)Für diesen C-ITS-Dienst wird keine Aktualisierungs-DENM verwendet.
12.5.Wiederholungsdauer und Wiederholungsintervall
(184)Neue DENM werden über eine repetitionDuration [WiederholungsDauer] von 300 ms (100 ms dreimal hintereinander) in einem repetitionInterval [WiederholungsIntervall] von 100 ms wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Da nicht garantiert ist, dass ein gesendeter IRC den Empfänger erreicht (z. B. aufgrund von Kanalbelastung, vorübergehendem Verlassen des Sendebereichs usw.) sendet der Sender den IRC dreimal hintereinander. Dies entspricht einer repetitionDuration [WiederholungsDauer] von 300 ms.
Anmerkung: Die geschätzte Dauer der Übermittlung (Anwendung zu Anwendung) eines IRC (Wiederholung nicht eingeschlossen) über das Automobil-WLAN beträgt 200300 ms. Wird in beiden Fällen (Anforderung und Antwort) nur der dritte Versuch empfangen (Schlimmstfall), steht die Informationen beiden Fahrzeugen nach 1 Sekunde zur Verfügung (2 * (300 ms + 100 ms (@10 Hz) + 100 ms (@10 Hz))). Aus diesem Grund ist der Auslöseparameter TTC < 1,5 s ausreichend. Das dreimalige Senden des IRC wird als guter Kompromiss zwischen Kanalbelastung und Sicherstellung einer erfolgreichen Übertragung angesehen.
Anmerkung: Nur die erste DENM wird ohne DCC-Beschränkungen gesendet. Die zweite und dritte DENM können von der dezentralen Stausteuerung (DCC) (auf der Grundlage der aktuellen Kanalbelastung) betroffen sein.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
12.6.Verkehrsklasse
(185)Neue DENM werden auf traffic class [Verkehrsklasse] 0 festgelegt.
12.7.Benachrichtigungsparameter
12.7.1.DENM
(186)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 25: DENM-Datenelemente von „Austausch von IRC — Antwort IRC“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts - Zeitstempel, bei dem eine neue DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan100 m(1) [wenigerAls100m(1)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
validityDuration [GültigkeitsDauer]
|
2 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 179.
|
|
causeCode [UrsachenKennung]
|
collisionRisk(97) [KollisionsRisiko(97)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
roadType [StraßenTyp]
|
Wird gemäß [TS 102 894-2] festgesetzt. Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container: ImpactReductionContainer [AufprallReduzierungsContainer] (IRC)
|
|
heightLonCarrLeft
[HöheLinkerLängsträger]
|
Höhe des linken Längsträgers des Fahrzeugs von der Unter- bis zur Oberkante. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
heightLonCarrRight
[PositionLängsträgerLinks]
|
Höhe des rechten Längsträgers des Fahrzeugs von oder Unter- bis zur Oberkante. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
posLonCarrLeft [PositionLängsträgerLinks]
|
Längsabstand zwischen der Mitte des vorderen Stoßfängers des Fahrzeugs und der Vorderkante des linken Längsträgers des Fahrzeugs. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
posLonCarrRight [PositionLängsträgerRechte]
|
Längsabstand zwischen der Mitte des vorderen Stoßfängers des Fahrzeugs und der Vorderkante des rechten Längsträgers des Fahrzeugs. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
positionOfPillars [PositionDerSäulen]
|
Unter Fahrzeugsäulen werden die senkrechten oder nahezu senkrechten Stützen des Fahrzeugs verstanden, die als A-, B-, C- oder D-Säule bezeichnet werden. Sie werden gemäß [TS 102 894-2] festgesetzt.
|
|
posCentMass [PositionMassezentrum]
|
Lotrechter Abstand vom Zentrum der Masse eines Fahrzeugs mit Leerlast bis zur vorderen Linie des Fahrzeugbegrenzungsrechtecks. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
wheelBaseVehicle [RadstandFahrzeug]
|
Lotrechter Abstand zwischen der Vorder- und Hinterachse des Radstandes des Fahrzeugs. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
turningRadius [Wendekreis]
|
Die kleinste kreisförmige Drehung (d. h. Wende), die das Fahrzeug durchführen kann. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
posFrontAx [PositionVorderachse]
|
Lotrechter Abstand zwischen der vorderen Linie des Fahrzeugbegrenzungsrechtecks und der Vorderachse. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
positionOfOccupants [PositionDerInsassen]
|
BitString, der anzeigt, ob ein Fahrgastsitz belegt ist bzw. ob der Belegungsstatus erkennbar ist. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
vehicleMass [FahrzeugMasse]
|
Masse eines Fahrzeugs mit Leerlast. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
requestResponseIndication [AnforderungAntwortAngabe]
|
response(1) [Antwort(1)]
|
12.7.2.CAM
(187)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
12.8.Netz- und Beförderungsebene
(188)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
12.9.Sicherheitsebene
(189)Gelten die unter Nummer 178 beschriebenen Auslösebedingungen, wird ein Wechsel des Berechtigungstickets (AT) blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende neue DENM werden mit dem gleichen Berechtigungsticket (AT) gesendet.
13.Gefährliche Situation — elektronisches Gefahrenbremslicht
13.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über eine Notbremsung des Fahrers, z. B. als Reaktion auf ein stehendes oder langsameres Fahrzeug voraus. Das Ego-Fahrzeug selbst wird zu einem möglichen örtlichen Gefahrenbereich.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Gefährliche Situationen — automatische Bremsung“;
·„Gefährliche Situationen — Auslösung des reversiblen Insassenrückhaltesystems“.
13.2.Auslösebedingungen
13.2.1.Voraussetzungen
(190)Für diesen C-ITS-Dienst gelten keine besonderen Voraussetzungen.
(191)Eine Aktivierung parallel mit den anderen verwandten C-ITS-Diensten wird vermieden. Werden die C-ITS-Dienste „automatische Bremsung“ und/oder „Auslösung des reversiblen Insassenrückhaltesystems“ gleichzeitig ausgelöst, erhalten die C-ITS-Dienste folgende Priorität:
(a)„elektronisches Gefahrenbremslicht“ (höchste Priorität);
(b)„automatische Bremsung“;
(c)„Auslösung des reversiblen Insassenrückhaltesystems“ (geringste Priorität).
(192)Wird ein C-ITS-Dienst mit höherer Priorität ausgelöst, wird die Übertragung eines verwandten C-ITS-Dienstes niedrigerer Priorität, der bereits ausgelöst wurde und im Hinblick auf eine Aktualisierung noch aktiv ist, abgebrochen. Darüber hinaus wird die Erzeugung einer neuen DENM für den C-ITS-Dienst höherer Priorität angefordert.
13.2.2.Dienstspezifische Bedingungen
(193)Wird die folgende Bedingung erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst.
(a)Ein Signal, das die Anforderung für das elektronische Gefahrenbremslicht darstellt, wird erkannt. Die Bedingungen für eine solche Anforderung werden in [ECE 48], [ECE 13] und [ECE 13H] dargelegt.
Fahrzeuge können auch folgende, alternative Auslösebedingungen nutzen:
(b)die derzeitige Fahrzeuggeschwindigkeit liegt über 20 km/h und die derzeitige Beschleunigung ist mindestens 500 ms lang niedriger als -7 m/s².
(194)Die Beschleunigung des Fahrzeugs wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die im Hinblick auf Sensorrauschen gefilterte Beschleunigung verwendet.
13.2.3.Qualität der Informationen
(195)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 193). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 26: Qualität der Information „elektronisches Gefahrenbremslicht“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCOkonforme Umsetzung
|
0
|
|
Bedingung (a) erfüllt
|
1
|
|
Bedingung (a) erfüllt und derzeitige gefilterte Längsbeschleunigung des Fahrzeugs < -4 m/s^2
|
2
|
|
Bedingung (b) erfüllt
|
3
|
(196)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
13.3.Beendigungsbedingungen
(197)Der C-ITS-Dienst wird beendet, wenn die Bedingung (a) oder (b) nicht mehr gültig ist. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
13.3.1.Löschung
(198)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
13.3.2.Verneinung
(199)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
13.4.Aktualisierung
(200)Die erzeugte DENM wird alle 100 ms aktualisiert, wenn die Auslösebedingungen immer noch erfüllt werden. Alle Datenfelder, denen neue Werte zugewiesen werden, sind in der folgenden Tabelle 27 aufgeführt.
13.5.Wiederholungsdauer und Wiederholungsintervall
(201)Für diesen C-ITS-Dienst wird keine Wiederholung der DENM verwendet.
13.6.Verkehrsklasse
(202)Neu- und Aktualisierungs-DENM werden auf traffic class 0 [Verkehrsklasse] gesetzt.
13.7.Benachrichtigungsparameter
13.7.1.DENM
(203)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 27: DENM-Datenelemente von „elektronisches Gefahrenbremslicht“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan500 m(3) [wenigerAls500m(3)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [Straßentyp]
|
Richtung
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
2 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 195.
|
|
causeCode [UrsachenKennung]
|
dangerousSituation(99) [gefährlicheSituation(99)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
emergencyElectronicBrakeEngaged(1) [elektronische Gefahrenbremse betätigt]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
13.7.2.CAM
(204)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
13.8.Netz- und Beförderungsebene
(205)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
13.9.Sicherheitsebene
(206)Treffen die unter Nummer 193 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu- und Aktualisierungs-DENM werden mit dem gleichen Berechtigungsticket gesendet.
14.„Gefährliche Situationen — automatische Bremsung“
14.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über eine autonome Notbremsung des Fahrzeugs. Das Ego-Fahrzeug selbst wird zu einem möglichen örtlichen Gefahrenbereich.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·‚gefährliche Situationen — elektronisches Gefahrenbremslicht“;
·„gefährliche Situationen — Auslösung des reversiblen Insassenrückhaltesystems“.
14.2.Auslösebedingungen
14.2.1.Voraussetzungen
(207)Für diesen C-ITS-Dienst gelten keine besonderen Voraussetzungen.
(208)Eine Aktivierung parallel mit den anderen verwandten C-ITS-Diensten wird vermieden. Werden die C-ITS-Dienste „elektronisches Gefahrenbremslicht“ und/oder „Auslösung des reversiblen Insassenrückhaltesystems“ gleichzeitig ausgelöst, erhalten die C-ITS-Dienste folgende Priorität:
(a)„elektronisches Gefahrenbremslicht“ (höchste Priorität);
(b)„automatische Bremsung“;
(c)„Auslösung des reversiblen Insassenrückhaltesystems“ (geringste Priorität).
(209)Wird ein C-ITS-Dienst mit höherer Priorität ausgelöst, wird die Übertragung eines verwandten C-ITS-Dienstes niedrigerer Priorität, der bereits ausgelöst wurde und im Hinblick auf eine Aktualisierung noch aktiv ist, abgebrochen. Darüber hinaus wird die Erzeugung einer neuen DENM für den C-ITS-Dienst höherer Priorität angefordert.
14.2.2.Dienstspezifische Bedingungen
(210)Wird die folgende Bedingung erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(a)ein Signal, das eine Anforderung der Auslösung eines autonomen Notbremssystems darstellt, wird erkannt.
(211)Die Beschleunigung des Fahrzeugs wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die im Hinblick auf Sensorrauschen gefilterte Beschleunigung verwendet.
14.2.3.Qualität der Informationen
(212)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 210). Der Wert informationQuality [InformationsQualität] wird der nachstehenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 28: Qualität der Information „automatische Bremsung“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCO-konforme Umsetzung
|
0
|
|
Bedingung (a) erfüllt
|
1
|
|
Bedingung (a) erfüllt und derzeitige gefilterte Längsbeschleunigung des Fahrzeugs < -4 m/s^2
|
2
|
(213)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
14.3.Beendigungsbedingungen
(214)Der C-ITS-Dienst wird beendet, wenn die Bedingung (a) nicht mehr gültig ist. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
14.3.1.Löschung
(215)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
14.3.2.Verneinung
(216)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
14.4.Aktualisierung
(217)Die erzeugte DENM wird alle 100 ms aktualisiert, wenn die Auslösebedingungen immer noch erfüllt werden. Alle Datenfelder, denen neue Werte zugewiesen werden, sind in der folgenden Tabelle 29 aufgeführt.
14.5.Wiederholungsdauer und Wiederholungsintervall
(218)Für diesen C-ITS-Dienst wird keine Wiederholung der DENM verwendet.
14.6.Verkehrsklasse
(219)Neu- und Aktualisierungs-DENM werden auf traffic class 0 [Verkehrsklasse] gesetzt.
14.7.Benachrichtigungsparameter
14.7.1.DENM
(220)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 29: DENM-Datenelemente von „automatische Bremsung“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan500 m(3) [wenigerAls500m(3)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
2 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 212.
|
|
causeCode
|
dangerousSituation(99) [gefährlicheSituation(99)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
aebEngaged(5) [Airbag betätigt]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [KursDerEreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zu Schätzung der Fahrstreifenzahl nicht legitim.
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
14.7.2.CAM
(221)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
14.8.Netz- und Beförderungsebene
(222)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
14.9.Sicherheitsebene
(223)Treffen die unter Nummer 210 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu- und Aktualisierungs-DENM werden mit dem gleichen Berechtigungsticket gesendet.
15.Gefährliche Situation — Auslösung des reversiblen Insassenrückhaltesystems
15.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über ein auf eine kritische Fahrsituation zurückzuführendes aktives Eingreifen eines reversiblen Insassenrückhaltesystems (z. B. reversible Gurtstraffer) im Ego-Fahrzeug.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·‚gefährliche Situationen — elektronisches Gefahrenbremslicht“;
·„Gefährliche Situationen — automatische Bremsung“.
15.2.Auslösebedingungen
15.2.1.Voraussetzungen
(224)Für diesen C-ITS-Dienst gelten keine besonderen Voraussetzungen.
(225)Eine Aktivierung parallel mit den anderen verwandten C-ITS-Diensten wird vermieden. Werden die C-ITS-Dienste „elektronisches Gefahrenbremslicht“ und/oder „automatische Bremsung“ gleichzeitig ausgelöst, erhalten die C-ITS-Dienste folgende Priorität:
(a)„elektronisches Gefahrenbremslicht“ (höchste Priorität);
(b)„automatische Bremsung“;
(c)„Auslösung des reversiblen Insassenrückhaltesystems“ (geringste Priorität).
(226)Wird ein C-ITS-Dienst mit höherer Priorität ausgelöst, wird die Übertragung eines verwandten C-ITS-Dienstes niedrigerer Priorität, der bereits ausgelöst wurde und im Hinblick auf eine Aktualisierung noch aktiv ist, abgebrochen. Darüber hinaus wird die Erzeugung einer neuen DENM für den C-ITS-Dienst höherer Priorität angefordert.
15.2.2.Dienstspezifische Bedingungen
(227)Ist die folgende Bedingung erfüllt, wird die Erzeugung einer DENM ausgelöst:
(a)es wird ein Signal erkannt, das eine Aufforderung zum aktiven Eingreifen eines reversiblen Insassenrückhaltesystems (z. B. reversible Gurtstraffer) darstellt und auf eine kritische Fahrsituation zurückzuführen ist.
15.2.3.Qualität der Informationen
(228)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 227). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 30: Qualität der Information „Auslösung des reversiblen Insassenrückhaltesystems“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCO-konforme Umsetzung
|
0
|
|
Bedingung (a) erfüllt
|
1
|
|
Bedingung (a) erfüllt und derzeitige gefilterte Längsbeschleunigung des Fahrzeugs < -4 m/s^2
|
2
|
(229)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
15.3.Beendigungsbedingungen
(230)Der C-ITS-Dienst wird beendet, wenn die Bedingung (a) nicht mehr gültig ist. Mit der Beendigung des C-ITS-Dienstes wird auch die Anforderung einer DENM-Aktualisierung beendet.
15.3.1.Löschung
(231)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
15.3.2.Verneinung
(232)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
15.4.Aktualisierung
(233)Die erzeugte DENM wird alle 100 ms aktualisiert, wenn die Auslösebedingungen immer noch erfüllt werden. Alle Datenfelder, denen neue Werte zugewiesen werden, sind in der folgenden Tabelle 31 aufgeführt.
15.5.Wiederholungsdauer und Wiederholungsintervall
(234)Für diesen C-ITS-Dienst wird keine Wiederholung der DENM verwendet.
15.6.Verkehrsklasse
(235)Neu- und Aktualisierungs-DENM werden auf traffic class 0 [Verkehrsklasse] gesetzt.
15.7.Benachrichtigungsparameter
15.7.1.DENM
(236)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 31: DENM-Datenelemente von „Auslösung des reversiblen Insassenrückhaltesystems“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für jede Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
lessThan500 m(3) [wenigerAls500m(3)]
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Ist der roadType [StraßenTyp] bekannt, wird der Wert wie folgt festgesetzt:
|
|
|
RoadType [StraßenTyp]
|
Richtung
|
|
|
0
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
1
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
2
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
|
3
|
upstreamTraffic(1) [nachfolgender Verkehr]
|
|
|
In allen anderen Fällen wird der Wert auf allTrafficDirections(0) [alleVerkehrsrichtungen(0)] gesetzt.
|
|
validityDuration [GültigkeitsDauer]
|
2 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 228.
|
|
causeCode
[UrsachenKennung]
|
dangerousSituation(99) [gefährlicheSituation(99)]
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
preCrashSystemEngaged(2) [Präventives Insassenschutzsystem betätigt]
|
|
Location-Container
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Geschwindigkeit der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
eventPositionHeading [Kurs der EreignisPosition]
|
Kurs der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnenM3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
|
Alacarte-Container
|
|
lanePosition [FahrstreifenPosition]
|
Wird die lanePosition [FahrstreifenPosition] von einem Bordsensor (z. B. Radar, Kamera) übermittelt, wird der Wert gemäß [TS 102 894-2] festgesetzt. Für diese Version der Auslösebedingung ist die Nutzung von GNSS und digitaler Landkarte zur Schätzung der Fahrstreifenzahl nicht legitim.
Ist die lanePosition [FahrstreifenPosition] unbekannt, wird das Datenelement ausgelassen.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
15.7.2.CAM
(237)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
15.8.Netz- und Beförderungsebene
(238)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
15.9.Sicherheitsebene
(239)Treffen die unter Nummer 227 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM blockiert, solange die validityDuration [GültigkeitsDauer] nicht abgelaufen ist. Entsprechende Neu- und Aktualisierungs-DENM werden mit dem gleichen Berechtigungsticket gesendet.
16.Widrige Witterungsbedingungen — Nebel
16.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über Nebel, der die Sicht des Fahrers beeinträchtigen kann.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„widrige Witterungsbedingungen — Niederschlag“.
(240)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu- oder Aktualisierungs-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
16.2.Auslösebedingungen
16.2.1.Voraussetzungen
(241)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
(a)die Fahrzeuggeschwindigkeit ist höher als 7 km/h;
(b)die Fahrzeuggeschwindigkeit ist geringer als 80 km/h.
(242)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet.
16.2.2.Dienstspezifische Bedingungen
(243)Werden die unter Nummer 241 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(1)Fahrerreaktion und Beleuchtungsstatus:
(a)der Fahrer schaltet die Nebelschlussleuchte ein und das Abblendlicht ist enabled [eingeschaltet]. All diese Bedingungen müssen länger als 20 s lang gültig sein (zur Minimierung des Risikos eines falschen Gebrauchs durch den Fahrer müssen die Bedingungen über einen längeren Zeitraum gültig sein);
(b)der Fahrer schaltet die Nebelschlussleuchte ein, das Abblendlicht ist enabled [eingeschaltet] und die Fahrzeuggeschwindigkeit ist geringer als 60 km/h. All diese Bedingungen müssen für die Dauer von mehr als 20 s gültig sein;
(2)Sichtweiten-Messgerät:
(a)die Sichtweite beträgt aufgrund von Nebel länger als 5 s lang weniger als 80 m +/- 40 m Toleranz (die beeinträchtigte Sicht muss einen angemessenen Zeitraum erkannt werden. Der Zeitraum ist kürzer als bei den Bedingungen (a) und (b), weil verlässlichere Informationen vorliegen);
(b)die Sichtweite beträgt aufgrund von Nebel länger als 5 s lang weniger als 80 m +/- 40 m Toleranz und die Fahrzeuggeschwindigkeit ist geringer als 60 km/h (befindet sich das Fahrzeug in einem nichtstädtischen Gebiet, könnte diese Geschwindigkeit auf eine verringerte Sichtweite hinweisen).
(244)Während der Detection Blocking Time [ErkennungsSperrzeit] wird keine Neu- oder Aktualisierungs-DENM erzeugt. Die Detection Blocking Time [ErkennungsSperrzeit] beginnt zu laufen, sobald das Ereignis erkannt und eine diesbezügliche DENM ausgelöst worden ist. Auf diese Weise kann ein einzelnes Ereignis keine Serie von DENM auslösen. Beim Sichtweiten-Messgerät (Bedingungen (c) und (d)) beträgt die Detection Blocking Time [ErkennungsSperrzeit] 15 s. Bei den anderen Bedingungen gibt es keine Detection Blocking Time [ErkennungsSperrzeit].
(245)Zur Sicherstellung eines gleichbleibenden funktionellen Verhaltens der verschiedenen Auslösebedingungen und der Detection Blocking Time [ErkennungsSperrzeit] beträgt das Minimum Detection Interval [MindestErkennungsIntervall] zwischen zwei erkannten Ereignissen20 s.
16.2.3.Qualität der Informationen
(246)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 243). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 32: Qualität der Information „widrige Witterungsbedingung— Nebel“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCO-konforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (a) ist erfüllt
|
1
|
|
Bedingung (b) ist erfüllt
|
2
|
|
Bedingung (c) ist erfüllt
|
3
|
|
Bedingung (d) ist erfüllt
|
4
|
(247)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
16.3.Beendigungsbedingungen
(248)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
16.3.1.Löschung
(249)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
16.3.2.Verneinung
(250)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
16.4.Aktualisierung
(251)Das jeweils geeignete Aktualisierungsverfahren für die DENM wird auf der Grundlage folgender Bedingungen bestimmt:
(a)nach dem in Abschnitt 16.2.2 festgelegten Minimum Detection Interval [MindestErkennungsIntervall] wird mindestens eine der unter Nummer 243 beschriebenen Bedingungen erfüllt;
(b)die validityDuration [GültigkeitsDauer] der früheren DENM ist noch nicht abgelaufen;
(c)weder der Wert des Datenelements DeltaLatitude [Deltabreite] noch der des Datenelements DeltaLongitude [Deltalänge], der den Abstand zwischen dem aktuell erkannten Ereignis und dem zuvor erkannten Ereignis darstellt, übersteigt den Schwellenwert, der von den Datenelementen DeltaLatitude [Deltabreite] und DeltaLongitude [Deltalänge] abgedeckt werden kann.
(252)Werden die unter Nummer 251 beschriebenen Bedingungen (a), (b) und (c) erfüllt, wird eine Aktualisierungs-DENM erzeugt. Die Informationen über die Datenelemente der früheren DENM (eventPosition, eventDeltaTime, informationQuality) werden als zusätzlicher eventPoint [Ereignispunkt] in der eventHistory [EreignisHistorie] gespeichert.
Die event points [Ereignispunkte] werden in aufsteigender Reihenfolge nach Lebensdauer angeordnet, wobei der neueste eventPoint [Ereignispunkt] an erster Stelle steht. Event points [Ereignispunkte] in der eventHistory [EreignisHistorie], deren Lebensdauer die validityDuration [GültigkeitsDauer] übersteigt, werden bei der Aktualisierungs-DENM aus der eventHistory [EreignisHistorie] gelöscht. Übersteigt der von der eventHistory [EreignisHistorie] abgedeckte Abstand den von der Sicherheitsfunktion zugelassenen Schwellenwert, werden die ältesten event points [Ereignispunkte] aus der eventHistory [EreignisHistorie] gelöscht.
Die Informationen über das aktuell erkannte Ereignis werden den DENM-Datenfeldern der aktualisierten DENM zugeordnet.
Anmerkung: Die Handhabung von event points [Ereignispunkten], deren Lebensdauer die validityDuration [GültigkeitsDauer] nach der Erzeugung der Aktualisierungs-DENM übersteigt, ist Aufgabe des Empfängers.
(253)Werden die Bedingungen (a) und (b), nicht aber Bedingung (c), erfüllt, wird keine Aktualisierungs-DENM erzeugt. Stattdessen wird eine Neu-DENM erzeugt. Die Informationen über das aktuell erkannte Ereignis werden den DENM-Datenfeldern der zusätzlichen Neu-DENM zugeordnet. Die frühere DENM wird weiter übertragen, bis die repetitionDuration [WiederholungsDauer] der früheren DENM abgelaufen ist.
(254)Wird die Bedingung (a), nicht aber Bedingung (b), erfüllt, wird keine Aktualisierungs-DENM erzeugt; es wird aber eine dem aktuell erkannten Ereignis entsprechende Neu-DENM erzeugt.
Anmerkung: In diesem Fall ist die Übertragung der früheren DENM bereits beendet worden, weil die repetitionDuration [WiederholungsDauer] der früheren DENM abgelaufen ist.
(255)Wird Bedingung (a) nicht erfüllt, ist die Erzeugung einer Aktualisierungs-DENM nicht erforderlich.
16.5.Wiederholungsdauer und Wiederholungsintervall
(256)DENM, die neu sind oder aktualisiert wurden, werden über eine repetitionDuration [WiederholungsDauer] von 180 s in einem repetitionInterval [WiederholungsIntervall] von 4 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird auf 300 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
16.6.Verkehrsklasse
(257)Neu- und Aktualisierungs-DENM werden auf traffic class 1 [Verkehrsklasse] gesetzt.
16.7.Benachrichtigungsparameter
16.7.1.DENM
(258)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 33: DENM-Datenelemente von „widrige Witterungsbedingung — Nebel“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Der Zeitstempel gibt den Beginn der Erkennung des aktuellen Ereignisses wieder. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt und auf die Zeit der Erkennung des aktuellen Ereignisses gesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
relevanceDistance [RelevanzEntfernung]
|
·Neu-DENM: lessThan1000 m(4) [wenigerAls1000m(4)]
·Aktualisierungs-DENM: lessThan5km(5) [wenigerAls5km(5)] (Durch die Nutzung von Aktualisierungen wird die von der eventHistory [EreignisHistorie] erfasste Entfernung länger. Um alle relevanten ITS-Stationen ansprechen zu können, ist in diesem Fall die relevanceDistance [RelevanzEntfernung] länger.)
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
validityDuration [GültigkeitsDauer]
|
300 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 246. Wird für jede Aktualisierungs-DENM aufgefrischt und auf die InformationsQualität des aktuellen Ereignispunktes gesetzt.
|
|
causeCode [UrsachenKennung]
|
widrigeWitterungsbedingung-Sichtweite(18)
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)] oder fog(1) [Nebel(1)]
|
|
eventHistory [EreignisHistorie]
|
Dieses Element wird nur für Aktualisierungs-DENM verwendet (siehe Abschnitt 16.4).
|
|
Location-Container
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht mit Bezug zum aktuellen Ereignispunkt.
Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
16.7.2.CAM
(259)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
16.8.Netz- und Beförderungsebene
(260)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
16.9.Sicherheitsebene
(261)Treffen die unter Nummer 243 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM (ab dem Zeitpunkt, an dem die Neu-DENM erzeugt wurde) 15 Minuten lang blockiert. Entsprechende Neu- und Aktualisierungs-DENM werden mit dem gleichen Berechtigungsticket gesendet.
(262)Wechselt das Berechtigungsticket (AT) und ist eine DENM-Übertragung aktiv (Neu- oder Aktualisierungs-DENM), wird die Übertragung angehalten. Darüber hinaus werden die EventHistory und die PathHistory gelöscht. Anschließend wird der regelmäßige DENM-Erzeugungsprozess fortgesetzt.
17.Widrige Witterungsbedingungen — Niederschlag
17.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über Niederschlag, der die Sicht des Fahrers beeinträchtigen kann.
Die folgenden C-ITS-Dienste sind mit diesem Dienst verwandt, da sie ähnliche Auslösebedingungen haben:
·„Widrige Witterungsbedingungen — Nebel“.
(263)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu- oder Aktualisierungs-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
17.2.Auslösebedingungen
17.2.1.Voraussetzungen
(264)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
(a)die Fahrzeuggeschwindigkeit ist höher als 7 km/h;
(b)die Fahrzeuggeschwindigkeit ist niedriger als 80 km/h;
(c)Die Scheibenwischfunktion ist nicht aktiv.
(265)Die Fahrzeuggeschwindigkeit wird durch das Bussignal des Fahrzeugs, nicht mittels GNSS bestimmt. Es wird die (im Hinblick auf Sensorrauschen) gefilterte Geschwindigkeit des Fahrzeugs verwendet.
17.2.2.Dienstspezifische Bedingungen
(266)Werden die unter Nummer 264 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(1)Scheibenwischerstufe und Beleuchtungsstatus:
(a)der Scheibenwischer läuft mit Höchstgeschwindigkeit. Das Abblendlicht ist enabled [eingeschaltet]. Alle diese Bedingungen müssen länger als 20 s lang gültig sein.
(b)Der Scheibenwischer läuft mit Höchstgeschwindigkeit und die Fahrzeuggeschwindigkeit beträgt weniger als 60 km/h. Das Abblendlicht ist enabled [eingeschaltet]. Alle diese Bedingungen müssen länger als 20 s lang gültig sein.
(2)Regenmessgerät, Scheibenwischerstufe und Beleuchtungsstatus:
(a)Die Regenmenge beträgt mindestens 90 % der höchsten Ausgangsleistung des Messgeräts und die Scheibenwischer laufen mit Höchstgeschwindigkeit. Das Abblendlicht ist enabled [eingeschaltet]. Alle diese Bedingungen müssen länger als 20 s lang gültig sein.
(b)Die Regenmenge beträgt mindestens 90 % der höchsten Ausgangsleistung des Messgeräts und die Scheibenwischer laufen mit Höchstgeschwindigkeit. Das Abblendlicht ist enabled [eingeschaltet] und die Fahrzeuggeschwindigkeit beträgt weniger als 60 km/h. All diese Bedingungen müssen länger als 20 s lang gültig sein.
(267)Das Minimum Detection Interval [MindestErkennungsIntervall] zwischen zwei erkannten Ereignissen beträgt 20 s.
17.2.3.Qualität der Informationen
(268)Der Wert des Datenelements informationQuality [InformationsQualität] in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 266). Der Wert informationQuality wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 34: Qualität der Information „widrige Witterungsbedingung— Niederschlag“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCO-konforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (a) ist erfüllt
|
1
|
|
Bedingung (b) ist erfüllt
|
2
|
|
Bedingung (c) ist erfüllt
|
3
|
|
Bedingung (d) ist erfüllt
|
4
|
(269)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
17.3.Beendigungsbedingungen
(270)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
17.3.1.Löschung
(271)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
17.3.2.Verneinung
(272)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
17.4.Aktualisierung
(273)Das jeweils geeignete Aktualisierungsverfahren für die DENM wird auf der Grundlage folgender Bedingungen bestimmt:
(a)nach dem in Abschnitt 17.2.2 festgelegten Minimum Detection Interval [MindestErkennungsIntervall] wird mindestens eine der unter Nummer 266 beschriebenen Bedingungen erfüllt;
(b)die validityDuration [GültigkeitsDauer] der früheren DENM ist noch nicht abgelaufen;
(c)weder der Wert des Datenelements DeltaLatitude [Deltabreite] noch der des Datenelements DeltaLongitude [Deltalänge], der den Abstand zwischen dem aktuell erkannten Ereignis und dem zuvor erkannten Ereignis darstellt, übersteigt den Schwellenwert, der von den Datenelementen DeltaLatitude [Deltabreite] und DeltaLongitude [Deltalänge] abgedeckt werden kann.
(274)Werden die unter Nummer 273 beschriebenen Bedingungen (a), (b) und (c) erfüllt, wird eine Aktualisierungs-DENM erzeugt. Die Informationen über die Datenelemente der früheren DENM (eventPosition, eventDeltaTime, informationQuality) müssen als zusätzlicher eventPoint [Ereignispunkt] in der eventHistory [EreignisHistorie] gespeichert werden.
Die Ereignispunkte werden in aufsteigender Reihenfolge nach Lebensdauer angeordnet, wobei der neueste eventPoint [Ereignispunkt] an erster Stelle steht. Ereignispunkte in der eventHistory [EreignisHistorie], deren Lebensdauer die validityDuration [GültigkeitsDauer] übersteigt, werden bei der Aktualisierungs-DENM aus der eventHistory [EreignisHistorie] gelöscht. Übersteigt der von der eventHistory [EreignisHistorie] abgedeckte Abstand den von der Sicherheitsfunktion zugelassenen Schwellenwert, werden die ältesten Ereignispunkte aus der eventHistory [EreignisHistorie] gelöscht.
Die Informationen über das aktuell erkannte Ereignis müssen den DENM-Datenfeldern der aktualisierten DENM zugeordnet werden.
Anmerkung: Die Handhabung von Ereignispunkten, deren Lebensdauer die validityDuration [GültigkeitsDauer] nach der Erzeugung der Aktualisierungs-DENM übersteigt, ist Aufgabe des Empfängers.
(275)Werden die Bedingungen (a) und (b), nicht aber Bedingung (c), erfüllt, wird keine Aktualisierungs-DENM erzeugt. Stattdessen wird eine Neu-DENM erzeugt. Die Informationen über das aktuell erkannte Ereignis werden den DENM-Datenfeldern der zusätzlichen Neu-DENM zugeordnet. Die frühere DENM wird weiter übertragen, bis die repetitionDuration [WiederholungsDauer] der früheren DENM abgelaufen ist.
(276)Wird die Bedingung (a), nicht aber Bedingung (b), erfüllt, wird keine Aktualisierungs-DENM erzeugt; es wird aber eine dem aktuell erkannten Ereignis entsprechende Neu-DENM erzeugt.
Anmerkung: In diesem Fall ist die Übertragung der früheren DENM bereits beendet worden, weil die repetitionDuration [WiederholungsDauer] der früheren DENM abgelaufen ist.
(277)Wird Bedingung (a) nicht erfüllt, ist die Erzeugung einer Aktualisierungs-DENM nicht erforderlich.
17.5.Wiederholungsdauer und Wiederholungsintervall
(278)DENM, die neu sind oder aktualisiert wurden, werden über eine repetitionDuration [WiederholungsDauer] von 180 s in einem repetitionInterval [WiederholungsIntervall] von 4 s wiederholt. Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird auf 300 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
17.6.Verkehrsklasse
(279)Neu- und Aktualisierungs-DENM werden auf traffic class 1 [Verkehrsklasse] gesetzt.
17.7.Benachrichtigungsparameter
17.7.1.DENM
(280)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 35: DENM-Datenelemente von „widrige Witterungsbedingung — Niederschlag“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Der Zeitstempel gibt den Beginn der Erkennung des aktuellen Ereignispunkts wieder. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt und auf die Zeit der Erkennung des aktuellen Ereignispunkts gesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt und auf die Position des aktuellen Ereignispunkts gesetzt.
|
|
relevanceDistance [RelevanzEntfernung]
|
·Neu-DENM: lessThan1000 m(4) [wenigerAls1000m(4)]
·Aktualisierungs-DENM: lessThan5km(5) [wenigerAls5km(5)] (Durch die Nutzung von Aktualisierungen wird die von der eventHistory [EreignisHistorie] erfasste Entfernung länger. Um alle relevanten ITS-Stationen ansprechen zu können, ist in diesem Fall die relevanceDistance [RelevanzEntfernung] länger.)
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
validityDuration [GültigkeitsDauer]
|
300 s
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 268. Wird für jede Aktualisierungs-DENM aufgefrischt und auf die InformationsQualität des aktuellen Ereignispunktes gesetzt.
|
|
causeCode [UrsachenKennung]
|
widrige Witterungsbedingung-Niederschlag(19)
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)], heavyRain(1) [starkerRegen(1)] oder heavySnowfall(2) [starkerSchneefall(2)]
|
|
eventHistory [EreignisHistorie]
|
Dieses Element wird nur für Aktualisierungs-DENM verwendet (siehe Abschnitt 17.4).
|
|
Location-Container
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht mit Bezug zum aktuellen Ereignispunkt.
Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
|
|
|
Wird für eine Aktualisierungs-DENM aufgefrischt und auf den roadType [StraßenTyp] des aktuellen Ereignispunkts gesetzt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennungzuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
17.7.2.CAM
(281)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
17.8.Netz- und Beförderungsebene
(282)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
17.9.Sicherheitsebene
(283)Treffen die unter Nummer 266 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM (ab dem Zeitpunkt, an dem die Neu-DENM erzeugt wurde) 15 Minuten lang blockiert. Entsprechende Neu- und Aktualisierungs-DENM werden mit dem gleichen Berechtigungsticket gesendet.
(284)Wechselt das Berechtigungsticket (AT) und ist eine Übertragung einer Neu- oder Aktualisierungs-DENM aktiv, wird die Übertragung angehalten. Darüber hinaus werden die EventHistory und die PathHistory gelöscht. Anschließend wird der regelmäßige DENM-Erzeugungsprozess fortgesetzt.
18.Widrige Witterungsbedingungen — Traktionsverlust
18.1.Beschreibung des C-ITS-Dienstes
Dieser C-ITS-Dienst übermittelt von Fahrzeug zu Fahrzeug (V2V) Informationen über Glätte, die das Fahrverhalten beeinträchtigen kann.
(285)Ein DENM-Signal wird nur dann an den Stack gesendet, wenn die in diesem Abschnitt beschriebenen Auslösebedingungen als gültig bewertet werden. Ein solches Signal veranlasst den Stack, eine Neu- oder Aktualisierungs-DENM zu erzeugen. Sind die Auslösebedingungen nicht erfüllt, wird kein DENM-Signal erzeugt.
18.2.Auslösebedingungen
18.2.1.Voraussetzungen
(286)Die folgenden Voraussetzungen müssen erfüllt sein, bevor dieser C-ITS-Dienst ausgelöst wird:
(a)der Rückwärtsgang ist nicht enabled [eingeschaltet];
(b)es werden keine Fehler bezüglich des Motors, des Antriebsstrangs und des Bremssystems gemeldet.
18.2.2.Dienstspezifische Bedingungen
(287)Werden die unter Nummer 286 genannten Voraussetzungen und mindestens eine der folgenden Bedingungen erfüllt, sind die Auslösebedingungen für diesen C-ITS-Dienst erfüllt und die Erzeugung einer DENM wird ausgelöst:
(1)auf der Grundlage positiver Beschleunigung:
(a)auf der Grundlage von Antriebs-Schlupf-Regelung (ASR), Gaspedal, Fahrzeugbeschleunigung und Fahrzeuggeschwindigkeit. Eine ASR-Anforderung muss mindestens 200 ms lang aktiv sein (ebenso für andere, von der ASR abhängige Sicherheitsfunktionen). Das Gaspedal ist im Durchschnitt mehr als 30 % gedrückt, solange die Intervention der ASR aktiv ist. Die Beschleunigung des Fahrzeugs (Beschleunigung laut gefiltertem Bussignal des Fahrzeugs) beträgt weniger als 40 % der Fahrzeugbeschleunigung auf einer Oberfläche mit hohem Reibungskoeffizienten (wie bei trockenem Asphalt (in der Regel µ = 0,85)) bei gleicher Startdrehzahl und gleichem Fahrmanöver. (Damit verschiedene Antriebskonfigurationen wie beispielsweise Zweirad- gegenüber Allradantrieben abgedeckt werden können, werden hier keine detaillierten Werte genannt);
(b)auf der Grundlage von ASR, Gaspedal, Fahrzeugbeschleunigung und Fahrzeuggeschwindigkeit. Eine ASR-Anforderung muss mindestens 200 ms lang aktiv sein. Das Gaspedal ist im Durchschnitt mehr als 30 % gedrückt, solange die Intervention der ASR aktiv ist. Die Beschleunigung des Fahrzeugs (Beschleunigung laut gefiltertem Bussignal des Fahrzeugs) beträgt weniger als 20 % der Fahrzeugbeschleunigung auf einer Oberfläche mit hohem Reibungskoeffizienten (wie bei trockenem Asphalt (in der Regel µ = 0,85)) bei gleicher Startdrehzahl und gleichem Fahrmanöver.
(c)auf der Grundlage von ASR, Gaspedal, Fahrzeugbeschleunigung und Fahrzeuggeschwindigkeit. Eine ASR-Anforderung muss mindestens 200 ms lang aktiv sein. Das Gaspedal ist im Durchschnitt mehr als 30 % gedrückt, solange die Intervention der ASR aktiv ist. Die Beschleunigung des Fahrzeugs (Beschleunigung laut gefiltertem Bussignal des Fahrzeugs) beträgt weniger als 10 % der Fahrzeugbeschleunigung auf einer Oberfläche mit hohem Reibungskoeffizienten (wie bei trockenem Asphalt (in der Regel µ = 0,85)) bei gleicher Startdrehzahl und gleichem Fahrmanöver.
(d)auf der Grundlage von ASR und Gaspedal. Eine ASR-Anforderung muss mindestens 200 ms lang aktiv sein. Das Gaspedal ist im Durchschnitt weniger als 30 % gedrückt (um keine Intervention der ASR auf einem Boden mit hohem Reibungswert auszulösen), solange die Intervention der ASR aktiv ist;
(2)auf der Grundlage einer negativen Beschleunigung (Geschwindigkeitsverringerung):
(a)auf der Grundlage von Antiblockiersystem (ABS), Bremsdruck und Geschwindigkeitsverringerung. Die Intervention des ABS ist länger als 200 ms lang aktiv (gemäß anderen, vom ABS abhängigen Sicherheitsfunktionen). Der Bremsdruck beträgt mehr als 20 % des maximal erzielbaren Bremsdrucks. Die Beschleunigung des Fahrzeugs (Beschleunigung laut gefiltertem Bussignal des Fahrzeugs) beträgt weniger als 50 % der Fahrzeugbeschleunigung auf einer Oberfläche mit hohem Reibungskoeffizienten (wie bei trockenem Asphalt (in der Regel µ = 0,85)) bei gleicher Startdrehzahl und gleichem Fahrmanöver.
(b)auf der Grundlage von ABS, Bremsdruck und Geschwindigkeitsverringerung. Die Intervention des ABS ist länger als 200 ms lang aktiv. Der Bremsdruck beträgt mehr als 20 % des maximal erzielbaren Bremsdrucks. Die Beschleunigung des Fahrzeugs (Beschleunigung laut gefiltertem Bussignal des Fahrzeugs) beträgt weniger als 25 % der Fahrzeugbeschleunigung auf einer Oberfläche mit hohem Reibungskoeffizienten (wie bei trockenem Asphalt (in der Regel µ = 0,85)) bei gleicher Startdrehzahl und gleichem Fahrmanöver.
(c)auf der Grundlage von ABS, Bremsdruck und Geschwindigkeitsverringerung. Die Intervention des ABS ist länger als 200 ms lang aktiv. Der Bremsdruck beträgt mehr als 20 % des maximal erzielbaren Bremsdrucks. (um keine Intervention der ASR auf einem Boden mit hohem Reibungswert auszulösen). Die Beschleunigung des Fahrzeugs (Beschleunigung laut gefiltertem Bussignal des Fahrzeugs) beträgt weniger als 10 % der Fahrzeugbeschleunigung auf einer Oberfläche mit hohem Reibungskoeffizienten (wie bei trockenem Asphalt (in der Regel µ = 0,85)) bei gleicher Startdrehzahl und gleichem Fahrmanöver.
(d)auf der Grundlage von ABS und Bremsdruck. Die Intervention des ABS ist länger als 200 ms lang aktiv. Der Bremsdruck beträgt weniger als 20 % des maximal erzielbaren Bremsdrucks;
(3)auf der Grundlage einer Schätzung des Reibungskoeffizienten:
(a)der Reibungskoeffizient beträgt mindestens 5 s lang weniger als 0,3 (der Reibungskoeffizient auf Eis beträgt < 0,2; auf Schnee und losem Splitt beträgt er etwa 0,4. Der Reibungskoeffizient muss über einen bestimmten Zeitraum erfasst werden);
(b)der Reibungskoeffizient liegt mindestens 5 s lang unter 0,2.
(288)Werden die Bedingungen 1a-c oder 2a-c als gültig bewertet, wird die Beschleunigung/Geschwindigkeitsverringerung des Fahrzeugs durch das Bussignal des Fahrzeugs, nicht mittels GNSS-Analyse bestimmt.
(289)Während der Detection Blocking Time [ErkennungsSperrzeit] wird keine Neu- oder Aktualisierungs-DENM erzeugt. Die Detection Blocking Time [ErkennungsSperrzeit] beginnt zu laufen, sobald das Ereignis erkannt und eine diesbezügliche DENM ausgelöst worden ist. Auf diese Weise kann ein einzelnes Ereignis keine Serie von DENM auslösen. Für die Schätzung des Reibungskoeffizienten (Bedingungen 3a und 3b) beträgt die Detection Blocking Time [ErkennungsSperrzeit] 15 s. Bei den anderen Bedingungen beträgt die Detection Blocking Time [ErkennungsSperrzeit] 20 s.
(290)Zur Sicherstellung eines gleichbleibenden funktionellen Verhaltens der Auslösebedingungen (a) - (d) und der Detection Blocking Time [ErkennungsSperrzeit] beträgt das Minimum Detection Interval [MindestErkennungsIntervall] zwischen zwei erkannten Ereignissen 20 s.
18.2.3.Qualität der Informationen
(291)Der Wert des Datenelements informationQuality in der DENM hängt von der Art und Weise ab, wie das Ereignis erkannt wird (siehe Nummer 287). Der Wert informationQuality [InformationsQualität] wird der folgenden Tabelle entsprechend festgesetzt (es wird der höchstmögliche Wert verwendet):
Tabelle 36: Qualität der Information „widrige Witterungsbedingung — Traktionsverlust“
|
Ereigniserkennung
|
Wert von InformationQuality [InformationsQualität]
|
|
Keine TRCO-konforme Umsetzung
|
unbekannt(0)
|
|
Bedingung (1)(a) oder (2)(a) ist erfüllt
|
1
|
|
Bedingung (1)(b) ist erfüllt
|
2
|
|
Bedingung (1)(c) oder (2)(b) ist erfüllt
|
3
|
|
Bedingung (2)(c) ist erfüllt
|
4
|
|
Bedingung (1)(d) oder (2)(d) ist erfüllt
|
5
|
|
Bedingung (3)(a) ist erfüllt
|
6
|
|
Bedingung (3)(b) ist erfüllt
|
7
|
(292)Ändern sich die Auslösebedingungen zwischen zwei Aktualisierungen, ändert sich die informationQuality [InformationsQualität] bis zur nächsten Aktualisierung nicht. Werden die geänderten Bedingungen auch während der Aktualisierung der DENM noch erfüllt, wird die informationQuality [InformationsQualität] aktualisiert.
18.3.Beendigungsbedingungen
(293)Eine Beendigung des C-ITS-Dienstes wird nicht in Betracht gezogen.
18.3.1.Löschung
(294)Für diesen C-ITS-Dienst wird keine Lösch-DENM verwendet.
18.3.2.Verneinung
(295)Für diesen C-ITS-Dienst wird keine Verneinungs-DENM verwendet.
18.4.Aktualisierung
(296)Das jeweils geeignete Aktualisierungsverfahren für die DENM wird auf der Grundlage folgender Bedingungen bestimmt:
(a)nach dem in Abschnitt 18.2.2 festgelegten Minimum Detection Interval [MindestErkennungsIntervall] wird mindestens eine der unter Nummer 287 beschriebenen Bedingungen erfüllt;
(b)die validityDuration [GültigkeitsDauer] der früheren DENM ist noch nicht abgelaufen;
(c)weder der Wert des Datenelements DeltaLatitude [Deltabreite] noch der des Datenelements DeltaLongitude [Deltalänge], der den Abstand zwischen dem aktuell erkannten Ereignis und dem zuvor erkannten Ereignis darstellt, übersteigt den Schwellenwert, der von den Datenelementen DeltaLatitude [Deltabreite] und DeltaLongitude [Deltalänge] abgedeckt werden kann.
(297)Werden die unter Nummer 296 beschriebenen Bedingungen (a), (b) und (c) erfüllt, wird eine Aktualisierungs-DENM erzeugt. Die Informationen über die Datenelemente der früheren DENM (eventPosition, eventDeltaTime, informationQuality) müssen als zusätzlicher eventPoint [Ereignispunkt] in der eventHistory [EreignisHistorie] gespeichert werden.
Die event points [Ereignispunkte] werden in aufsteigender Reihenfolge nach Lebensdauer angeordnet, wobei der neueste eventPoint [Ereignispunkt] an erster Stelle steht. Event points [Ereignispunkte] in der eventHistory [EreignisHistorie], deren Lebensdauer die validityDuration [GültigkeitsDauer] (siehe Nummer 303) übersteigt, werden bei der Aktualisierungs-DENM aus der eventHistory [EreignisHistorie] gelöscht. Übersteigt der von der eventHistory [EreignisHistorie] abgedeckte Abstand den von der Sicherheitsfunktion zugelassenen Schwellenwert, werden die ältesten eventPoints [Ereignispunkte] aus der eventHistory [EreignisHistorie] gelöscht.
Die Informationen über das aktuell erkannte Ereignis müssen den DENM-Datenfeldern der aktualisierten DENM zugeordnet werden.
Anmerkung: Die Handhabung von event points [Ereignispunkten], deren Lebensdauer die validityDuration [GültigkeitsDauer] nach der Erzeugung der Aktualisierungs-DENM übersteigt, ist Aufgabe des Empfängers.
(298)Werden die Bedingungen (a) und (b), nicht aber Bedingung (c), erfüllt, wird keine Aktualisierungs-DENM erzeugt. Stattdessen wird eine Neu-DENM erzeugt. Die Informationen über das aktuell erkannte Ereignis werden den DENM-Datenfeldern der zusätzlichen Neu-DENM zugeordnet. Die frühere DENM wird weiter übertragen, bis die repetitionDuration [WiederholungsDauer] der früheren DENM abgelaufen ist.
(299)Wird die Bedingung (a), nicht aber Bedingung (b), erfüllt, wird keine Aktualisierungs-DENM erzeugt; es wird aber eine dem aktuell erkannten Ereignis entsprechende Neu-DENM erzeugt.
Anmerkung: In diesem Fall ist die Übertragung der früheren DENM bereits beendet worden, weil die repetitionDuration [WiederholungsDauer] der früheren DENM abgelaufen ist.
(300)Wird Bedingung (a) nicht erfüllt, ist die Erzeugung einer Aktualisierungs-DENM nicht erforderlich.
18.5.Wiederholungsdauer und Wiederholungsintervall
(301)Standardmäßig werden DENM, die neu sind oder aktualisiert wurden, über eine repetitionDuration [WiederholungsDauer] von 300 s in einem repetitionInterval [WiederholungsIntervall] von 1 s wiederholt.
Wird die DENM jedoch in einem städtischen Gebiet (gemäß Feststellung durch eine digitale Landkarte oder den Algorithmus eines Bordsensors) ausgelöst, wird sie über eine repetitionDuration [WiederholungsDauer] von 180 s mit einem repetitionInterval [WiederholungsIntervall] von 4 s wiederholt.
Aus diesem Grund werden die Parameter repetitionDuration und repetitionInterval der Schnittstelle zwischen der Anwendung und dem Basisdienst für dezentrale Umfeldmeldung (DEN) den vorstehend aufgeführten Werten entsprechend festgesetzt.
Anmerkung: Die validityDuration [GültigkeitsDauer] wird auf 600 s bzw. 300 s gesetzt. So kann eine Lücke bei DENM verhindert werden, wenn die repetitionDuration [WiederholungsDauer] der ursprünglichen DENM abgelaufen ist und die Aktualisierung noch nicht empfangen worden ist.
Anmerkung: Gehen zwei DENM mit dem gleichen causeCode [UrsachenKennung] von der gleichen C-ITS-Station aus, wird dieser Fall von der empfangenden C-ITS-Station verwaltet.
18.6.Verkehrsklasse
(302)Neu- und Aktualisierungs-DENM werden auf traffic class 1 [Verkehrsklasse] gesetzt.
18.7.Benachrichtigungsparameter
18.7.1.DENM
(303)In der folgenden Tabelle werden die festzusetzenden Datenelemente der DENM spezifiziert.
Tabelle 37: DENM-Datenelemente von „widrige Witterungsbedingung — Traktionsverlust“
|
Datenfeld
|
Wert
|
|
Management-Container
|
|
actionID [MaßnahmenID]
|
Kennung einer DENM. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
detectionTime [Erkennungszeit]
|
TimestampIts - Zeitstempel, bei dem das Ereignis von der erzeugenden C-ITS-Station erkannt wird. Der Zeitstempel gibt den Beginn der Erkennung des aktuellen Ereignispunkts wieder. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt und auf die Zeit der Erkennung des aktuellen Ereignispunkts gesetzt.
|
|
referenceTime [ReferenzZeit]
|
TimestampIts-Zeitstempel, bei dem eine Neu-DENM oder eine Aktualisierungs-DENM erzeugt wird. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
termination [Beendigung]
|
Wird nicht festgesetzt, weil in diesem C-ITS-Dienst weder Verneinung noch Löschung verwendet werden.
|
|
eventPosition [EreignisPosition]
|
ReferencePosition [ReferenzPosition]. Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt und auf die Position des aktuellen Ereignispunkts gesetzt.
|
|
relevanceDistance [RelevanzEntfernung]
|
·Neu-DENM: lessThan1000 m(4) [wenigerAls1000m(4)]
·Aktualisierungs-DENM: lessThan5km(5) [wenigerAls5km(5)] (Durch die Nutzung von Aktualisierungen wird die von der eventHistory [EreignisHistorie] erfasste Entfernung länger. Um alle relevanten ITS-Stationen ansprechen zu können, ist in diesem Fall die relevanceDistance [RelevanzEntfernung] länger.)
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
allTrafficDirections(0) [alleVerkehrsrichtungen(0)]
|
|
validityDuration [GültigkeitsDauer]
|
Grundwert: 600 s
In städtischen Gebieten gemäß Feststellung durch eine digitale Landkarte oder den Algorithmus eines Bordsensors: 300 s. (Verfügt das Fahrzeug nicht über Informationen über den Status städtisch/nicht städtisch, wird der Grundwert verwendet.)
|
|
stationType [StationsTyp]
|
Die Art der C-ITS-Station, von der die Meldung ausgeht. Wird gemäß [TS 102 894-2] festgesetzt.
|
|
Situation-Container
|
|
informationQuality [InformationsQualität]
|
Siehe Nummer 291. Wird für jede Aktualisierungs-DENM aufgefrischt und auf die informationQuality [InformationsQualität] des aktuellen Ereignispunktes gesetzt.
|
|
causeCode [UrsachenKennung]
|
widrigeWitterungsbedingung-Haftung(6)
|
|
subCauseCode [nachgeordnete UrsachenKennung]
|
unavailable(0) [nicht verfügbar(0)]
|
|
eventHistory [EreignisHistorie]
|
Dieses Element wird nur für Aktualisierungs-DENM verwendet (siehe Abschnitt 18.4).
|
|
Location-Container
|
|
traces [Verfolgung]
|
PathHistory [StreckenHistorie] der C-ITS-Station, von der die Meldung ausgeht mit Bezug zum aktuellen Ereignispunkt.
Wird gemäß [TS 102 894-2] festgesetzt.
Wird für eine Aktualisierungs-DENM aufgefrischt.
|
|
roadType [StraßenTyp]
|
RoadType der Straße, auf der sich die erkennende C-ITS-Station befindet.
Wird für eine Aktualisierungs-DENM aufgefrischt und auf den roadType [StraßenTyp] des aktuellen Ereignispunkts gesetzt.
|
|
|
Wird gemäß [TS 102 894-2] in Verbindung mit folgenden Regeln festgesetzt:
|
|
|
Städtisch / nicht städtisch
|
Strukturelle Trennung
|
Datenelement
|
|
|
Städtisch
|
Nein
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Städtisch
|
Ja
|
urban-WithStructuralSeparation ToOppositeLanes(1)
[Städtisch-MitStrukturellerTrennung zuGegenfahrbahnen(1)]
|
|
|
Städtisch
|
Unbekannt
|
urban-NoStructuralSeparation ToOppositeLanes(0)
[städtisch-keineStrukturelleTrennung zuGegenfahrbahnen(0)]
|
|
|
Nicht städtisch
|
Nein
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Nicht städtisch
|
Ja
|
nonUrban-WithStructuralSeparation ToOppositeLanes(3)
[Nichtstädtisch-MitStrukturellerTrennung zuGegenfahrbahnen(3)]
|
|
|
Nicht städtisch
|
Unbekannt
|
nonUrban-NoStructuralSeparation ToOppositeLanes(2)
[Nichtstädtisch-keineStrukturelleTrennung zuGegenfahrbahnen(2)]
|
|
|
Lässt sich die Information über den Status städtisch/nicht städtisch nicht feststellen, wird das Datenelement ausgelassen.
|
18.7.2.CAM
(304)Für diesen C-ITS-Dienst wird keine CAM-Anpassung eingesetzt.
18.8.Netz- und Beförderungsebene
(305)Der Parameter DENM destination area [DENM-Bestimmungsgebiet] der Schnittstelle zwischen dem DEN-Basisdienst und der Vernetzungs- und Beförderungsebene entspricht einer Kreisform mit einem Radius gleich der relevanceDistance [RelevanzEntfernung].
18.9.Sicherheitsebene
(306)Treffen die unter Nummer 287 beschriebenen Auslösebedingungen zu, wird ein Wechsel des Berechtigungstickets (AT) für Neu- und Aktualisierungs-DENM (ab dem Zeitpunkt, an dem die Neu-DENM erzeugt wurde) 15 Minuten lang blockiert. Entsprechende Neu- und Aktualisierungs-DENM werden mit dem gleichen Berechtigungsticket gesendet.
(307)Wechselt das Berechtigungsticket (AT) und ist eine Übertragung einer Neu- oder Aktualisierungs-DENM aktiv, wird die Übertragung angehalten. Darüber hinaus werden die EventHistory und die PathHistory gelöscht. Anschließend wird der regelmäßige DENM-Erzeugungsprozess fortgesetzt.
19.Anzeige von Verkehrszeichen im Fahrzeug — dynamische Information über Geschwindigkeitsbegrenzungen
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von IVI) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über die aktuell gültige Geschwindigkeitsbegrenzung je Segment, Fahrstreifen oder Fahrzeugkategorie, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(308)Diese Information muss mit den aktuell gültigen dynamischen Verkehrszeichen kohärent sein.
(309)Das [ISO/TS 14823]-Datenfeld wird eingestellt mit serviceCategoryCode = regulatory, nature = 5, serialnumber = 57, attributes/spe/spm = the value of the speed limit in km/h and unit = 0 [DienstKategorieCode = ordnungsrechtlich, Art = 5, Seriennummer = 57, /Attribute/spe/spm = Wert der Geschwindigkeitsbegrenzung in km/h und Einheit = 0] (d.h. kmproStunde) oder dem Äquivalent für andere Länder (z. B. 1 für MeilenproStunde).
(310)Hinsichtlich des Endes der Geschwindigkeitsbegrenzung kann Folgendes genutzt werden: Das [ISO/TS 14823]-Datenfeld wird eingestellt mit serviceCategoryCode = regulatory (12), nature = 6, serialnumber = 14 (notice of end of speed limit) or serviceCategoryCode = informative (13), nature = 6, serial number = 63 (notice of end of all restrictions by electronic signs) [DienstKategorieCode = ordnungsrechtlich (12), Art = 6 Seriennummer = 14 (Hinweis auf Ende der Geschwindigkeitsbegrenzung) oder DienstKategorieCode = informativ (13), Art = 6, Seriennummer = 63 (Hinweis auf Ende aller Beschränkungen mittels elektronischer Verkehrszeichen)], wenn dieses Verkehrszeichen auf der Straße nicht gezeigt wird. Endmeldungen können redundant sein, wenn der Endpunkt der Relevanzzone der anfänglichen IVI-Meldung die Geschwindigkeitsbegrenzung bereits beendet.
20.Anzeige von Verkehrszeichen im Fahrzeug — eingebettetes Sprachspeichersystem (VMS) „Freitext“
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von Informationen der Infrastruktur an das Fahrzeug (IVI)) zwischen Infrastruktur und Fahrzeug (I2V) Informationen als „Freitext“, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber. Die Priorität der gesendeten Verkehrszeichenmeldungen (IVS) wird vom Straßenbetreiber festgelegt.
(311)Diese Information muss mit den aktuell gültigen dynamischen Verkehrszeichen kohärent sein.
21.Anzeige von Verkehrszeichen im Fahrzeug — sonstige Informationen über Verkehrszeichen
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von IVI) zwischen Infrastruktur und Fahrzeug (I2V) Informationen Verkehrszeichen wie beispielsweise Überholverbote oder Fahrstreifenempfehlungen, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber, nicht aber dynamische Geschwindigkeitsbegrenzungen und Freitextinformationen.
(312)Diese Information muss mit den aktuell gültigen dynamischen Verkehrszeichen kohärent sein.
(313)Das [ISO/TS 14 823] Datenfeld wird eingestellt mit serviceCategoryCode = informative [DienstKategorieCode = informativ]; nature = 6 [Art = 6]; Seriennummer = 59 (Fahrstreifen gesperrt), 60 (Fahrbahn frei), 61 (Fahrstreifen nach links verlassen) oder 62 (Fahrstreifen nach rechts verlassen).
(314)Hinsichtlich „Ende der Beschränkung“ können DienstKategorieCode = informativ (13), Art = 6, Seriennummer = 63 für „Ende aller Beschränkungen durch elektronische Verkehrszeichen“ verwendet werden, wenn dieses elektronische Verkehrszeichen erscheint. Endmeldungen können redundant sein, wenn der Endpunkt der Relevanzzone der anfänglichen IVI-Meldung die Information durch das Verkehrszeichen bereits beendet.
22.Warnungen vor gefährlichen Situationen — Unfallbereich
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über einen Unfallbereich und verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(315)Der causeCode [UrsachenKennung] wird auf 2 (Unfall) und der subCauseCode [nachgeordneteUrsachenKennung] auf 0 bis 7 (außer 6) gesetzt.
23.Warnungen vor gefährlichen Situationen — Verkehrsstau voraus
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) je Segment oder Fahrstreifen Informationen über einen Verkehrsstau voraus und verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber (in der die Positionen, die Länge des Verkehrsstaus und die betroffenen Abschnitte/Fahrstreifen genannt werden, sofern diese Informationen verfügbar sind).
(316)Der causeCode [UrsachenKennung] wird auf 27 (gefährliches Stauende) und der subCauseCode [nachgeordneteUrsachenKennung] auf 0 unavailable(0) [nicht verfügbar(0)] gesetzt, um ein gefährliches Stauende anzuzeigen. Zur Übermittlung von Informationen über die Gesamtlänge des Staus wird der causeCode [UrsachenKennung] auf 1 (Verkehrsstau) und der subCauseCode [nachgeordneteUrsachenKennung] auf 0 gesetzt.
24.Warnungen vor gefährlichen Situationen — stehendes Fahrzeug
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über ein stehendes Fahrzeug und verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(317)Der causeCode [UrsachenKennung] wird auf 94 (stehendes Fahrzeug) und der subCauseCode [nachgeordneteUrsachenKennung] auf 0 unavailable(0) [nicht verfügbar(0)] oder 2 (liegengebliebenes Fahrzeug) gesetzt.
25.Warnungen vor gefährlichen Situationen — Warnung vor Witterungsbedingungen
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über aktuelle und/oder erwartete Niederschläge oder extreme Witterungsbedingungen (Szenario 1) oder über geringe Sichtweiten (Szenario 3) und verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(318)Der causeCode [UrsachenKennung] wird auf 17 (extreme Witterungsbedingung) oder 19 (Niederschlag) gesetzt.
26.Warnungen vor gefährlichen Situationen — vorübergehende Straßenglätte
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über glatte Straßenabschnitte und verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(319)Der causeCode [UrsachenKennung] wird auf 6 (Haftung) und der subCauseCode [nachgeordneteUrsachenKennung] auf Werte zwischen 0 und 9 gesetzt.
27.Warnungen vor gefährlichen Situationen — Tier oder Person auf der Fahrbahn
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über Tiere oder Personen auf der Fahrbahn und verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(320)Der causeCode [UrsachenKennung] wird auf 11 (Tier auf der Fahrbahn) oder 12 (Menschen auf der Fahrbahn) gesetzt.
28.Warnungen vor gefährlichen Situationen — Hindernis auf der Fahrbahn
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über ein oder mehrere Hindernis(se) auf einem oder mehreren Fahrstreif(en). Der Verkehr kann jedoch weiterlaufen (keine Sperrung). Der Dienst verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(321)Der causeCode [UrsachenKennung] wird auf 10 (Hindernis auf der Fahrbahn) und der subCauseCode [nachgeordneteUrsachenKennung] auf Werte zwischen 0 und 5 (6 und 7 werden nicht verwendet) gesetzt.
29.Warnung vor Straßenarbeiten — Fahrstreifensperrung (und andere Einschränkungen)
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über die Sperrung eines Teils eines Fahrstreifens, eines vollständigen Fahrstreifens oder mehrerer Fahrstreifen (einschließlich des Standstreifens), aber ohne Vollsperrung der Straße. Der Dienst verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
Er kann auf folgende Weise bereitgestellt werden:
·feste, geplante Straßenarbeiten (ausgelöst durch die Verkehrseinsatzzentrale) – der Straßenbetreiber programmiert feste, geplante (oder ad-hoc erfolgende) Straßenarbeiten in sein Verkehrsmanagementsystem (TMS) ein;
·eigenständiger Modus – für kurz- oder langfristige Straßenarbeiten wird ein Anhänger genutzt, der nicht mit der Verkehrseinsatzzentrale verbunden ist (keine Verbindung verfügbar);
·erweitert („eigenständig“, gefolgt von „ausgelöst durch Verkehrseinsatzzentrale“) — die Meldung wird erst von einem Anhänger aus gesendet und kann später aktualisiert werden, auch mit zusätzlichen Einzelheiten von der Verkehrseinsatzzentrale.
(322)Der causeCode [UrsachenKennung] wird auf 3 (Straßenarbeiten) und der subCauseCode [nachgeordneteUrsachenKennung] auf 0 oder 4 gesetzt.
30.Warnung vor Straßenarbeiten — Straßensperrung
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über eine durch eine Reihe fester Straßenarbeiten verursachte Straßensperrung. Die Sperrung ist vorübergehend. Der Dienst verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
(323)Der causeCode [Ursachenkennung] wird auf 3 (Straßenarbeiten) und der subCauseCode [nachgeordneteUrsachenKennung] auf 1 gesetzt.
31.Warnung vor Straßenarbeiten — Straßenarbeiten (mobil)
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von DEN) zwischen Infrastruktur und Fahrzeug (I2V) Informationen über einen Bereich der Straße, in dem aufgrund einer geplanten mobilen Baustelle an einer bestimmten Stelle ein Fahrstreifen verengt oder geschlossen wurde (aber ohne Straßensperrung). Der Dienst verwendet dazu eine einzige Warnmeldungs-ID, entsprechend der Festsetzung und Verbreitung durch den Straßenbetreiber.
Dieser C-ITS-Dienst kann auf eine der folgenden Arten bereitgestellt werden:
·Ausgelöst durch Verkehrseinsatzzentrale — der Straßenbetreiber programmiert mobile, geplante (oder ad-hoc erfolgende) Straßenarbeiten in sein Verkehrsmanagementsystem ein. Diese Information enthält alle Elemente, die zur Identifizierung des Arbeitsbereichs verwendet werden können (Anfangs-/Endposition, Dauer). Die Beauftragten werden nicht den gesamten Bereich nutzen, sondern die tatsächliche Baustelle innerhalb des Bereichs markieren. Weitere Informationen wie die Geschwindigkeitsbegrenzung in jedem verengten Abschnitt können hinzugefügt werden.
·eigenständiger Modus – für kurz- oder langfristige Straßenarbeiten wird ein Anhänger genutzt, der nicht mit der Verkehrseinsatzzentrale verbunden ist (keine Verbindung verfügbar).
(324)Der causeCode [UrsachenKennung] wird auf 3 (Straßenarbeiten) und der subCauseCode [nachgeordneteUrsachenKennung] auf 3 gesetzt.
32.Beampelte Kreuzungen — Geschwindigkeitsempfehlungen bezüglich grüner Welle
Dieser C-ITS-Dienst übermittelt (mittels Nutzung von Informationen zu Ampelphasen und Timing (SPAT) sowie topologischen Informationen für die Kreuzung (MAP)) zwischen Infrastruktur und Fahrzeug (I2V) Informationen zur Geschwindigkeitsempfehlung für Verkehrsteilnehmer, die an mittels Verkehrsampeln gesteuerte Kreuzungen heranfahren und diese passieren; dabei stützt sich der Dienst auf den aktuellen Phasenstatus und das vorausgesagte Timing der Verkehrsampeln sowie die Topologie für die nächste(n) Kreuzung(en).
Er kann auf folgende Weise bereitgestellt werden:
·das Fahrzeug berechnet die Geschwindigkeitsempfehlung – die beampelte Kreuzung übermittelt regelmäßig in Echtzeit den aktuellen Status der Ampelphase und das Timing der anstehenden Phasenwechsel. Das sich nähernde Fahrzeug, dem der eigene Standort und seine Geschwindigkeit bekannt sind, empfängt die Meldungen und berechnet die optimale Geschwindigkeit für das Heranfahren an die Kreuzung;
·die Infrastruktur berechnet die Geschwindigkeitsempfehlung – die beampelte Kreuzung berechnet und überträgt regelmäßig in Echtzeit Informationen mit Geschwindigkeitsempfehlungen für mehrere Straßensegmente der Kreuzungszufahrt. Das sich nähernde Fahrzeug, dem der eigene Standort und seine Geschwindigkeit bekannt sind, empfängt die Meldungen und extrahiert die optimale Geschwindigkeit für das Heranfahren an die Kreuzung;
·Geschwindigkeitsempfehlung für grüne Welle – eine Reihe mittels Verkehrsampeln gesteuerter, synchronisierter Kreuzungen überträgt vorab festgelegte/geplante Geschwindigkeitsempfehlungen für die grüne Welle. Das sich nähernde Fahrzeug, dem der eigene Standort und seine Geschwindigkeit bekannt sind, empfängt die Meldungen und extrahiert die Geschwindigkeit bezüglich der grünen Welle beim Passieren der Kreuzungen.
(325)Die von der beampelten Kreuzung übertragenen Informationen über den aktuellen Status der Ampelphase und das Timing der anstehenden Phasenwechsel müssen hinreichend genau und verlässlich sein, damit eine qualitativ hochwertige Geschwindigkeitsempfehlung sichergestellt werden kann.
(326)Die Informationen müssen mit den physischen Ampelleuchten an den Kreuzungen übereinstimmen.
(327)Verkehrsbedingungen wie Fahrzeugschlangen oder Staus beeinträchtigen die Gültigkeit der Geschwindigkeitsempfehlung und sind daher zu berücksichtigen.
(328)Die empfohlenen Geschwindigkeiten dürfen nie über der gesetzlichen Höchstgeschwindigkeit liegen.
33.Beampelte Kreuzungen — Vorrang für öffentlichen Personennahverkehr
Dieser C-ITS-Dienst räumt an beampelten Kreuzungen Fahrzeugen des öffentlichen Personennahverkehrs Vorrang gegenüber Privatfahrzeugen ein und nutzt dazu Signal Request Extended Message [erweiterte Meldung (Ampel)-Signalanforderung] (SREM) und Signal Request Status Extended Message [erweiterte Meldung, Status, (Ampel-)Signalanforderung]. Das Fahrzeug des öffentlichen Personennahverkehrs übermittelt mittels einer Meldung vom Fahrzeug zur Infrastruktur (V2I) eine Priorisierungsanforderung. Das Priorisierungssystem für den öffentlichen Personennahverkehr verarbeitet die Anforderung, nimmt sie an oder lehnt sie ab und sendet mittels einer Meldung von der Infrastruktur an das Fahrzeug (I2V) eine Rückmeldung an das Fahrzeug des öffentlichen Personennahverkehrs. Wird die Anforderung angenommen und können beispielsweise „Rotphasen“ verkürzt und „Grünphasen“ verlängert werden, erhält das Fahrzeug des öffentlichen Personennahverkehrs an der Haltelinie mit minimaler Verzögerung „Grün“. Nachdem das Fahrzeug die Kreuzung erfolgreich durchfahren hat, schaltet die Ampelsteuerung in den Normalbetrieb zurück.
(329)Die stationID des Fahrzeugs ändert sich während der Verarbeitung der Priorisierungsanforderung nicht.
(330)Die Authentifizierung und Autorisierung von Fahrzeugen des öffentlichen Personennahverkehrs müssen sichergestellt sein.
(331)Die Priorisierungsanforderung muss so rechtzeitig übermittelt werden, dass das System zur Priorisierung des öffentlichen Personennahverkehrs reagieren kann.
ANHANG II
1.Einleitung
1.1.Referenzdokumente
In diesem Anhang werden folgende Referenzdokumente herangezogen:
EN 302 636-4-1
ETSI EN 302 636-4-1, Intelligent Transport Systems (ITS); Vehicular Communications; Geonetworking; Teil 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Unterabschnitt 1: Media-Independent Functionality. V1.3.1 (2017-08)
TS 102 894-2
ETSI TS 102 894-2, Intelligent Transport Systems (ITS); Users and applications requirements; Teil 2: Applications and facilities layer common data dictionary, V1.3.1 (2018-08)
ISO/TS 19091
ISO/TS 19091, Intelligente Transportsysteme - Kooperative ITS - Nutzung von V2I und I2V-Kommunikation für Anwendungen bezogen auf Signalanlagen an Kreuzungen (2017-03)
EN 302 663
ETSI EN 302 663, Intelligent Transport Systems (ITS); Access layer specification for Intelligent Transport Systems operating in the 5 GHz frequency band, V1.2.1 (2013-07)
TS 102 687
ETSI TS 102 687, Intelligent Transport Systems (ITS); Decentralized Congestion Control Mechanisms for Intelligent Transport Systems operating in the 5 GHz range; Access layer part, V1.2.1 (2018-04)
TS 102 792
ETSI TS 102 792, Intelligent Transport Systems (ITS); Mitigation techniques to avoid interference between European CEN Dedicated Short Range Communication (CEN DSRC) equipment and Intelligent Transport Systems (ITS) operating in the 5 GHz frequency range, V1.2.1 (2015-06)
EN 302 637-2
ETSI EN 302 637-2, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Teil 2: Specification of Cooperative Awareness Basic Service, V1.4.0 (2018-08); Bezugnahmen auf dieses Dokument sind ab dem Datum der Veröffentlichung der Fassung 1.4.1 als Bezugnahmen auf jene Fassung zu verstehen;
TS 102 724
ETSI TS 102 724, Intelligent Transport Systems (ITS); Harmonized Channel Specifications for Intelligent Transport Systems operating in the 5 GHz frequency band, V1.1.1 (2012-10)
EN 302 636-5-1
ETSI EN 302 636-5-1, Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Teil 5: Transport Protocols; Unterabschnitt 1: Basic Transport Protocol, V2.1.1 (2017-08)
TS 103 248
ETSI TS 103 248, Intelligent Transport Systems (ITS); GeoNetworking; Port Numbers for the Basic Transport Protocol (BTP), V1.2.1 (2018-08)
EN 302 931
ETSI EN 302 931, Vehicular Communications; Geographical Area Definition, V1.1.1 (2011-7)
EN 302 637-3
ETSI EN 302 637-3, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic Service, V1.3.0 (2018-08); Bezugnahmen auf dieses Dokument sind ab dem Datum der Veröffentlichung der Fassung 1.3.1 als Bezugnahmen auf jene Fassung zu verstehen;
TS 102 636-4-2
ETSI TS 102 636-4-2, Intelligent Transport Systems (ITS); Vehicular Communications; GeoNetworking; Teil 4: Geographical addressing and forwarding for point-to-point and point-to-multipoint communications; Unterabschnitt 2: Media-dependent functionalities for ITS-G5, V1.1.1 (2013-10)
SAE J2945/1
SAE J2945/1, On-board System Requirements for V2V Safety Communications, (2016-03)
TS 103 097
ETSI TS 103 097, Intelligent Transport Systems (ITS); Security; Security Header and Certificate Formats, V1.3.1 (2017-10)
ISO 8855
ISO 8855, Straßenfahrzeuge - Fahrzeugdynamik und Fahrverhalten - Begriffe, (2011-12)
TS 103 301
ETSI TS 103 301, Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of Applications; Facilities layer protocols and communication requirements for infrastructure services, V1.2.1 (2018-08)
TS 103 175
ETSI TS 103 175, Intelligent Transport Systems (ITS); Cross Layer DCC Management Entity for operation in the ITS G5A and ITS G5B medium, V1.1.1 (2015-06)
ISO/TS 19321
ISO/TS 19321, Intelligente Transportsysteme - Kooperative ITS - Verzeichnis von Datenstrukturen fahrzeugseitiger Informationen (IVI) (15.4.2015)
ISO 3166-1
ISO 3166-1:2013, Codes für die Namen von Ländern und deren Untereinheiten – Teil 1: Ländercodes
ISO 14816
ISO 14816:2005, Telematik für den Straßenverkehr und Transport - Automatische Identifizierung von Fahrzeugen und Geräten; Nummerierung und Datenstrukturen
ISO/TS 14823
ISO/TS 14823:2017, Intelligente Verkehrssysteme - Graphisches Verzeichnis
IEEE 802.11
IEEE 802.11-2016, IEEE Standard for Information technology — Telecommunications and information exchange between systems, local and metropolitan area networks — Specific requirements, Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications, (2016-12-14)
1.2.Notationen und Abkürzungen
In diesem Anhang werden folgende Notationen und Abkürzungen verwendet:
AT
Authorization Ticket [Berechtigungsschein]
BTP
Basic Transport Protocol [grundlegendes Verkehrsprotokoll]
CA
Cooperative Awareness [kooperative Aufklärung]
CAM
Cooperative Awareness Message [kooperative Aufklärungsmeldung]
CBR
Channel Busy Ratio [Verhältniswert für belegten Kanal]
CCH
Control Channel [Steuerkanal]
CDD
Common Data Dictionary [gemeinsames Datenverzeichnis]
CEN-DSRC
Europäische Komitee für Normung (CEN) - Dedicated Short Range Communication [dedizierte Nahbereichskommunikation]
C-ITS
Kooperatives Intelligentes Verkehrssystem
DCC
Decentralized Congestion Control [dezentrale Stausteuerung]
DEN
Decentralized Environmental Notification [dezentrale Umfeldbenachrichtigung]
DENM
Decentralized Environmental Notification Message [Meldung mit dezentraler Umfeldbenachrichtigung]
DP
Decentralized Congestion Control Profile [Profil für dezentrale Stausteuerung]
ETSI
Europäisches Institut für Telekommunikationsnormen (European Telecommunications Standards Institute)
GBC
GeoBroadcast
GN
GeoNetworking
GNSS
Global Navigation Satellite System [globales Satellitennavigationssystem]
IEC
Institute of Electrical and Electronics Engineers [Institut für Elektro- und Elektronik-Ingenieure]
IVI
Infrastructure to Vehicle Information [Information Infrastruktur - Fahrzeug]
IVIM
Infrastructure to Vehicle Information Message [Informationsmeldung Infrastruktur - Fahrzeug]
MAP
Topology information for the intersection [topologische Information für Kreuzung]
MAPEM
MAP Extended Message [MAP-erweiterte Meldung]
NH
Next Header [nächster Kopfsatz]
NTP
Network Time Protocol (Netzzeitprotokoll)
PAI
Position Accuracy Indicator [Anzeiger für Positionsgenauigkeit]
PoTi
Position and Time [Position und Zeit]
QPSK
Quadrature Phase-Shift Keying [Vierphasen-Umtastung]
RLT
Road Lane Topology [Fahrstreifentopologie]
RSU
Road-side Unit [Infrastrukturkomponente]
SCF
Store Carry Forward [Speicher-Vortrag]
SHB
Single Hop Broadcast [Ausstrahlung in Einzeletappen]
SPATEM
Signal Phase and Timing Extended Message [erweiterte Meldung Ampelphase und Timing]
SREM
Signal Request Extended Message [erweiterte Meldung (Ampel)-Signalanforderung]
SSEM
Signal Request Status Extended Message [erweiterte Meldung (Ampel)Signalanforderung, Status]
TAI
Temps Atomique International [Internationale Atomzeit]
TAL
Trust Assurance Level [Grad der Vertrauenswürdigkeit]
TLM
Traffic Light Manoeuvre [Verkehrsampelmanöver]
TC
Traffic Class [Verkehrsklasse]
UTC
Coordinated Universal Time [Koordinierte Weltzeit]
WGS84
Weltweites geodätisches System von 84
1.3.Begriffsbestimmungen
In diesem Anhang werden folgende Begriffsbestimmungen verwendet:
(a)Unter „C-ITS-Zeit“ oder „Zeitbasis“ ist gemäß der Definition in [ETSI EN 302 636-4-1] die Zahl der seit 2004-01-01 00:00:00.000 koordinierter Weltzeit (UTC) verstrichenen Millisekunden nach internationaler Atomzeit (TAI) zu verstehen. Die Zeitstempel gemäß der Definition in [ETSI TS 102 894-2] entsprechen diesem Zeitformat.
Anmerkung: „Millisekunden nach internationaler Atomzeit“ bezeichnet die tatsächlich gezählte, nicht durch Schaltsekunden nach dem 1. Januar 2004 veränderte Zahl der Millisekunden.
(b)Unter „Stationsuhr“ ist eine Uhr zu verstehen, die die Zeit kooperativer intelligenter Verkehrssysteme (C-ITS) in einer C-ITS-Station darstellt.
2.Anforderungen an fahrzeugseitige, für die Nahbereichskommunikation ausgelegte C-ITS-Stationen
Dieses Systemprofil legt einen Mindestsatz an Normen fest und füllt erforderlichenfalls Informationslücken bezüglich der Realisierung einer dialogfähigen fahrzeugseitigen C-ITS-Station auf der Senderseite. Das Profil umfasst nur Anforderungen an die Dialogfähigkeit und lässt etwaige zusätzliche Anforderungen offen. Es beschreibt folglich nicht die vollständige Funktionsweise der fahrzeugseitigen C-ITS-Station.
Das Systemprofil ermöglicht den Einsatz der Prioritätsdienste (insbesondere von Fahrzeug zu Fahrzeug (V2V)). Es kann auch andere Dienste unterstützen, diese erfordern aber eventuell weitere Systemspezifikationen.
Das Profil stellt Beschreibungen, Definitionen und Regeln für die Ebenen der Referenzarchitektur von ETSI ITS-Station /ITS-S Host bereit (Anwendungen, Einrichtungen, Vernetzung & Verkehr sowie Zugang).
2.1.Begriffsbestimmungen
In diesem Teil des Anhangs werden folgende Begriffsbestimmungen verwendet:
(a)Die „Fahrzeugzustände“ enthalten die absolute Position, den Kurs und die Geschwindigkeit zu einem bestimmten Zeitpunkt.
(b)Unter mit einer „statistischen Sicherheit“ von 95 % bereitgestellter Information ist zu verstehen, dass an 95 % der Datenpunkte in einer vorgegebenen statistischen Grundlage der richtige Wert innerhalb des durch den geschätzten Wert plus/minus Vertrauensintervall festgelegten Bereichs liegt.
(c)Unter „Versperrung der Sicht“ ist der Anteil der Hemisphärenwerte zu verstehen, der wegen Bergen, Gebäuden, Bäumen usw. für Galileo und andere globale Satellitennavigationssysteme (GNSS) versperrt ist.
(d)„CEN-DSRC“ (Comité Européen de Normalisation – Mikrowellen-Nahbereichskommunikation) ist eine Mikrowellentechnologie, die in elektronischen Mautsystemen zur Finanzierung von Kosten der Straßeninfrastruktur oder zur Erhebung von Straßennutzungsgebühren eingesetzt wird. Für die Zwecke dieses Anhangs fallen alle 5,8 GHz-Mikrowellentechnologien, die in der Richtlinie 2004/52/EG des Europäischen Parlaments und des Rates sowie der Kommissionsentscheidung 2009/750/EG genannt werden, unter den Begriff „CEN-DSRC“.
2.2.Parametereinstellungen
In diesem Teil des Anhangs werden die in Tabelle 1 aufgeführten Parametereinstellungen verwendet.
Tabelle 1: Parametereinstellungen
|
Parameter
|
Wert
|
Maßeinheit
|
Beschreibung
|
|
pAlDataRateCch
|
6
|
Mbit/s
|
Vorgegebene Datenübertragungsgeschwindigkeit (Grundwert) für den Steuerkanal (CCH)
|
|
pAlDataRateCchHigh
|
12
|
Mbit/s
|
Optionale höhere Datenübertragungsgeschwindigkeit für den Steuerkanal als der Grundwert
|
|
pAlDataRateCchLow
|
3
|
Mbit/s
|
Optionale niedrigere Datenübertragungsgeschwindigkeit für den Steuerkanal als der Grundwert
|
|
pBtpCamPort
|
2001
|
Entfällt
|
Bekannter Zielport für CAM
|
|
pBtpDenmPort
|
2002
|
Entfällt
|
Bekannter Zielport für DENM
|
|
pBtpDestPortInfo
|
0
|
Entfällt
|
Wert für die Zielport-Information
|
|
pCamGenNumber
|
3
|
Entfällt
|
Zahl der aufeinanderfolgend generierten CAM ohne Zeiteinschränkungen
|
|
pCamTraceMaxLength
|
500
|
m
|
Höchstlänge einer Verfolgungsspur in CAM
|
|
pCamTraceMinLength
|
200
|
m
|
Mindestlänge einer Verfolgungsspur in CAM
|
|
pCamTrafficClass
|
2
|
Entfällt
|
Verkehrsklassenwert (TC), mit dem CAM gesendet werden
|
|
pDccCcaThresh
|
-85
|
dBm
|
Mindestempfindlichkeit des Kanals
|
|
pDccMeasuringInterval
|
100
|
ms
|
Wert für das Intervall, in dem die Kanalbelastung bereitgestellt wird
|
|
pDccMinSensitivity
|
-88
|
dBm
|
Wert für die Mindestempfindlichkeit des Empfängers
|
|
pDccProbingDuration
|
8
|
µs
|
Wert für die Dauer der Messsondenprobe
|
|
pDccPToll
|
10
|
dBm
|
Wert für die Sendeleistung innerhalb geschützter Zonen
|
|
pDCCSensitivityMargin
|
3
|
dB
|
Wert für die Parametermarge pDccMinSensitivity
|
|
pDenmTraceMaxLength
|
1000
|
m
|
Maximale Länge einer Verfolgungsspur in DENM
|
|
pDenmTraceMinLength
|
600
|
m
|
Minimale Länge einer Verfolgungsspur in DENM
|
|
pGnAddrConfMode
|
ANONYM (2)
|
Entfällt
|
Konfigurationsmethode für GeoNetworking (GN) Adresse
|
|
pGnBtpNh
|
2
|
Entfällt
|
Wert für das Feld Nächster Kopfsatz (NH) im gemeinsamen Kopfsatz von GN
|
|
pGnChannelOffLoad
|
0
|
Entfällt
|
Wert für das Feld Kanalentlastung
|
|
pGnEtherType
|
0x8947
|
--
|
Wert für den zu verwendenden EtherType
|
|
pGnGbcHtField
|
4
|
Entfällt
|
Wert für das Feld KopfsatzTyp bei GeoBroadcast (GBC)
|
|
pGnGbcScf
|
1
|
Entfällt
|
Wert für das Feld Speichervortrag bei GeoBroadcast (GBC)
|
|
pGnInterfaceType
|
ITS-G5 (1)
|
Entfällt
|
Von GN zu nutzender Schnittstellentyp
|
|
pGnIsMobile
|
1
|
Entfällt
|
Definiert, ob die C-ITS-Station mobil ist oder nicht
|
|
pGnMaxAreaSize
|
80
|
km²
|
Unterstützte, abzudeckende Fläche
|
|
pGnSecurity
|
AKTIVIERT (1)
|
Entfällt
|
Definiert die Verwendung von GN-Sicherheitskopfsätzen
|
|
pGnShbHstField
|
0
|
Entfällt
|
Wert für das Feld KopfsatzUnterTyp bei Funk in Einzeletappe (SHB)
|
|
pGnShbHtField
|
5
|
Entfällt
|
Wert für das Feld KopfsatzTyp bei SHB
|
|
pGnShbLifeTimeBase
|
1
|
Entfällt
|
Wert für das Feld LebensDauerBasis bei SHB.
|
|
pGnShbLifeTimeMultiplier
|
1
|
Entfällt
|
Wert für das Feld LebensDauerMultiplikator bei SHB
|
|
pPotiMaxTimeDiff
|
20
|
ms
|
Maximaler Zeitunterschied zwischen Stationsuhr und Zeitbasis
|
|
pPotiWindowTime
|
120
|
s
|
Größe des gleitenden Fensters Position und Zeit (PoTi) in Sekunden
|
|
pPotiUpdateRate
|
10
|
Hz
|
Aktualisierungsgeschwindigkeit für Positions- und Zeitangaben
|
|
pSecCamToleranceTime
|
2
|
s
|
Maximale Zeitabweichung zwischen der Zeit im Sicherheitskopfsatz der kooperativen Aufklärungsmeldung (CAM) und der Stationsuhr zur Annahme der CAM
|
|
pSecGnScc
|
0
|
Entfällt
|
Wert für das SCC-Feld der GN-Adresse
|
|
pSecGnSourceAddressType
|
0
|
Entfällt
|
Wert für das Feld M der GN-Adresse (Konfigurationstyp der Adresse)
|
|
pSecMaxAcceptDistance
|
6
|
km
|
Maximale Entfernung zwischen Sender und Empfänger für die Annahme von Meldungen
|
|
pSecMessageToleranceTime
|
10
|
min
|
Maximale Zeitabweichung zwischen der Zeit im Sicherheitskopfsatz der Meldung (außer CAM) und der Stationsuhr für die Annahme der Meldung
|
|
pSecRestartDelay
|
1
|
min
|
Übergangsfrist für Wechsel des Berechtigungsscheins nach dem Einschalten des Zündterminals
|
|
pTraceAllowableError
|
0,47
|
m
|
Parameter für die Berechnung der Streckenhistorie; weitere Einzelheiten: siehe Anhang A.5 [SAE J2945/1].
|
|
pTraceDeltaPhi
|
1
|
°
|
Parameter für die Berechnung der Streckenhistorie; weitere Einzelheiten: siehe Anhang A.5 [SAE J2945/1].
|
|
pTraceEarthMeridian
|
6 378 137
|
km
|
Mittlerer Erdradius (laut Internationaler Union für Geodäsie und Geophysik (IUGG)). Wird für die Berechnung von Verfolgungsspuren verwendet; weitere Einzelheiten: siehe Anhang A.5 [SAE J2945/1].
|
|
pTraceMaxDeltaDistance
|
22.5
|
m
|
Parameter für die Berechnung von Verfolgungsspuren; weitere Einzelheiten: siehe Anhang A.5 [SAE J2945/1].
|
2.3.Sicherheit
(1)Eine fahrzeugseitige C-ITS-Station wird sicher mit einem bestimmten Fahrzeug verbunden. Wird die fahrzeugseitige C-ITS-Station eingeschaltet, muss sie überprüfen, ob sie in dem Fahrzeug in Betrieb ist, mit dem sie sicher verbunden worden ist. Lässt sich eine solche Bedingung für eine korrekte Funktionsweise nicht verifizieren, wird die C-ITS-Station deaktiviert und damit verhindert, dass sie Meldungen sendet (d. h. es wird mindestens die Funkübertragungsebene der C-ITS-Station deaktiviert).
(2)Die fahrzeugseitige C-ITS-Station vergleicht den Zeitstempel im Sicherheitskopfsatz mit der Empfangszeit und nimmt nur CAM in der letzten Zeit von pSecCamToleranceTime sowie andere Meldungen innerhalb der letzten Zeit von pSecMessageToleranceTime an.
(3)Die fahrzeugseitige C-ITS-Station prüft die Entfernung von der Senderposition – im Sicherheitskopfsatz falls verfügbar – und leitet nur Meldungen weiter, die eine Entfernung vom Sender von pSecMaxAcceptDistance oder weniger haben.
(4)Die Verifizierung einer Meldung umfasst mindestens eine kryptografische Verifizierung der Signatur der Meldung.
(5)Die fahrzeugseitige C-ITS-Station leitet nur verifizierte Meldungen weiter.
(6)Die fahrzeugseitige C-ITS-Station verwendet gemäß [TS 103 097] und [EN 302 636-4-1] einen durchgängigen Sicherheitskopfsatz (end-to-end) und eine Signatur pro Meldung.
(7)Die Signatur wird gemäß Satz 7.2.1 in [TS 103 097] mittels eines geheimen Schlüssels, der einem gültigen Berechtigungsschein entspricht, generiert.
(8)Alle mittels Nahbereichskommunikation übermittelten Adressen und Kennungen werden geändert, wenn der Berechtigungsschein geändert wird.
2.4.Positionierung und Timing
(9)Die Fahrzeugzustände müssen kohärent sein. Daher beziehen sich Kurs und Geschwindigkeit auf die gleiche Zeit wie die absolute Position (z. B. GenerierungsDeltaZeit in CAM).
Anmerkung: Bei den Genauigkeitswerten der Zustandsvariablen sind Ungenauigkeiten, die aufgrund zeitbezogener Effekte entstehen können, zu berücksichtigen.
(10)Die fahrzeugseitige C-ITS-Station nutzt der Spezifikation in [TS 102 894-2] entsprechend das weltweite geodätische System von 84 (WGS84) als Referenzkoordinatensystem.
Anmerkung: Da das mit der Kontinentalplatte Europas verbundene Europäische Terrestrische Referenzsystem (ETRS89) um 2,5 cm/Jahr im WGS84 abdriftet, ist darauf hinzuweisen, dass fahrzeugseitige C-ITS-Stationen das jeweils genutzte Referenzierungssystem kennen müssen. Wird ein erweitertes Referenzierungssystem wie ein mit Echtzeit-Kinematik erweitertes System für eine hochpräzise Standortreferenzierung verwendet, muss diese Verschiebung eventuell kompensiert werden.
(11)Informationen zur Höhe über NN sind als Höhe über dem WGS84 Ellipsoid zu interpretieren.
Anmerkung: Alternative Interpretationen der Höhe über NN mittels Geoid-Definitionen (z. B. relativ zu Normalnull) dürfen nicht verwendet werden.
(12)Bezüglich der horizontalen Position wird eine Vertrauensfläche anstatt eines einzelnen Vertrauensintervalls genutzt. Die Vertrauensfläche wird beschrieben als Ellipse, die durch eine Haupt- und eine Nebenachse und die Ausrichtung der Hauptachse relativ zur Himmelsrichtung Norden gemäß Festlegung unter Nummer (10) definiert wird.
(13)Die fahrzeugseitige C-ITS-Station interpretiert „Kurs“ als die Richtung des horizontalen Geschwindigkeitsvektors. Der Ausgangspunkt des Geschwindigkeitsvektors ist der ITS-Referenzpunkt des Fahrzeugs gemäß der Definition unter B.19 „ReferenzPosition“ in [EN 302 637-2].
Anmerkung: Alternative Kursinterpretationen, die sich auf die Ausrichtung der Fahrzeugkarosserie beziehen, dürfen nicht verwendet werden.
Anmerkung: Diese Definition impliziert, dass das Ergebnis einer geraden Rückwärtsfahrt eine Differenz von 180 ° zwischen dem Kurs des Fahrzeugs und der Ausrichtung der Fahrzeugkarosserie ist.
(14)Die C-ITS-Zeit ist die Grundlage für alle Zeitstempel aller von der fahrzeugseitigen C-ITS-Station in allen EU-Mitgliedstaaten gesendeten Meldungen.
(15)Sind sie eingeschaltet, aktualisieren die C-ITS-Stationen die Fahrzeugzustände mit einer Häufigkeit, die mindestens der pPotiUpdateRate entspricht.
(16)Zeitstempel in Meldungen basieren auf der Stationsuhr.
(17)Die Differenz zwischen der Stationsuhr und der C-ITS-Zeit wird geschätzt. Ist die absolute Differenz |Stationsuhrzeit - C-ITS-Zeit | >= pPotiMaxTimeDiff, ist die fahrzeugseitige C-ITS-Station nicht aktiv.
Anmerkung: Ein genauer Zeitstempel ist nicht nur für die Zeitsynchronisierung erforderlich, sondern impliziert auch, dass die Systemzustände an genau dem betreffenden Zeitpunkt gültig sind, d. h. dass die Fahrzeugzustände kohärent bleiben.
(18)Kommt das Fahrzeug zum Stillstand, meldet das System den letzten bekannten Kurswert (Bewegungsrichtung des Fahrzeugs). Der Wert wird entsperrt, wenn sich das Fahrzeug wieder in Bewegung setzt.
2.5.Systemverhalten
(19)Die fahrzeugseitige C-ITS-Station betreibt den Basisdienst „kooperative Aufklärung“ (Cooperative Awareness Basic Service), wenn sie sich auf öffentlichen Straßen befindet und die Fahrdynamik regelmäßig ist.
Anmerkung: Der Betrieb des Cooperative Awareness Basic Service schließt die Übertragung von CAM ein, wenn alle Bedingungen für die Generierung von CAM erfüllt sind.
(20)TRACES-Daten und Daten über die Historie werden nur erstellt, wenn Informationen über das Positions-Vertrauen verfügbar sind und die Stationsuhr sich auf Punkt (90) (91) stützt.
(21)Ein Fahrzeuginsasse ist in der Lage, die fahrzeugseitige C-ITS-Station jederzeit problemlos zu deaktivieren.
(22)Die fahrzeugseitige C-ITS-Station handhabt CAM-Übertragungen so, dass keine überholten Meldungen übertragen werden, auch dann nicht, wenn die Stausteuerung angewendet wird.
2.6.Zugangsebene
(23)Um Meldungen zur Unterstützung des Basisdienstes „Cooperative Awareness“ und der in Anhang I dieser Verordnung spezifizierten vorrangigen C-ITS-Dienste zu senden, nutzt die fahrzeugseitige C-ITS-Station den Steuerkanal G5-CCH gemäß Tabelle 3 in der Norm [EN 302 663].
(24)Die Zugangsebene der fahrzeugseitigen C-ITS-Station muss der Norm [EN 302 663] entsprechen, mit Ausnahme von Emissionsgrenzen und der Sätze 4.2.1, 4.5 und 6.
(25)Die fahrzeugseitige C-ITS-Station verwendet auf dem Steuerkanal eine vorgegebene Übertragungsgeschwindigkeit von pAlDataRateCch.
(26)Die fahrzeugseitige C-ITS-Station unterstützt auch die Übertragungsgeschwindigkeiten pAlDataRateCchLow und pAlDataRateCchHigh auf dem Steuerkanal.
(27)Die Zugangsebene der fahrzeugseitigen C-ITS-Station muss [TS 102 724] entsprechen.
(28)Die fahrzeugseitige C-ITS-Station unterstützt die folgenden in [TS 102 724] definierten Profile für dezentrale Stausteuerung (DP): DP0, DP1, DP2 und DP3.
Diese Profile für dezentrale Stausteuerung (DCC) verwenden die folgenden Identifizierungswerte für DCC-Profile:
·DP0, wird nur für DENM mit Verkehrsklasse = 0 verwendet;
·DP1, wird für DENM mit Verkehrsklasse = 1 verwendet;
·DP2, wird für CAM mit Verkehrsklasse = pCamTrafficClass verwendet;
·DP3, wird für weitergeleitete DENM und andere Meldungen mit geringer Priorität verwendet.
(29)Der Mechanismus für dezentrale Stausteuerung (DCC) der fahrzeugseitigen C-ITS-Station entspricht [TS 102 687].
(30)Die Einstellungen in Tabelle A.1 in [TS 102 687] werden verwendet, wenn der in Satz 5.3 von [TS 102 687] umrissene reaktive DCC-Algorithmus implementiert wird.
Anmerkung: Tabelle A.2 in [TS 102 687] basiert auf der Verbreitung von CAM und dezentralen Umfeldbenachrichtigungen (DENM) für vorrangige C-ITS-Dienste mit einer durchschnittlichen Ton von 500 μs.
(31)Die folgende Glättungsfunktion der Verhältniswerte für belegten Kanal (CBR) wird durchgeführt, wenn die fahrzeugseitige C-ITS-Station den in Satz 5.3 von [TS 102 687] umrissenen reaktiven DCC-Algorithmus nutzt: CBR_now = (CBR(n)+CBR(n-1))/2 (
Anmerkung: Dabei sind „n“ und „n-1“ die aktuellen bzw. früheren Zeiträume der CBR-Stichprobenauswahl).
(32)Die fahrzeugseitige C-ITS-Station muss mindestens in der Lage sein, die durch den Wert der höchsten CAM-Generierungsfrequenz (d. h. 10 Hz) bestimmte Anzahl an Meldungen zu erzeugen und zu übertragen; werden Erkennungsalgorithmen verwendet, wird dieser Wert um die aus diesen Auslösebedingungen abgeleitete, zumindest erforderliche DENM-Generierungsfrequenz erhöht.
(33)Die fahrzeugseitige C-ITS-Station hält die folgenden maximalen Meldungsfrequenzen ein, sofern sie mit dem in Satz 5.3 von [TS 102 687] umrissenen DCC-Algorithmus arbeitet:
·entspannter Zustand: die Summe aller auf DP1, DP2 und DP3 gesandten Meldungen überschreitet Rmax_relaxed = 16,7 Meldungen pro Sekunde nicht. Plötzliche Meldungsanhäufungen (Bursts) sind zulässig für DP0 mit RBurst = 20 Meldungen pro Sekunde und einer Höchstdauer von TBurst = 1 Sekunde; sie dürfen nur alle TBurstPeriod = 10 Sekunden stattfinden. Zählt man also DP0-Meldungen hinzu, beträgt die maximale Meldungsfrequenz Rmax_relaxed = 36,7 Meldungen pro Sekunde;
·aktive Zustände: die maximale Meldungsfrequenz für jeden Zustand wird in Tabelle A.2 in [TS 102 687] angegeben;
·restriktiver Zustand: die maximale Meldungsfrequenz pro fahrzeugseitiger C-ITS-Station wird auf 2,2 Meldungen pro Sekunde, d. h. den Kehrwert von TTX_MAX = 460 ms festgesetzt.
(34)Die fahrzeugseitige C-ITS-Station unterstützt eine Sendeleistungssteuerung pro Paket.
Anmerkung: PTx kann vom aktuellen Zustand der dezentralen Stausteuerung (DCC) (d. h. entspannt, aktiv oder restriktiv) und dem DCC-Profil (d. h. DP0, DP1, usw.) abhängen.
(35)Die fahrzeugseitige C-ITS-Station senkt beim Einfahren in die Schutzzone ihre Sendeleistung auf PToll = pDccPToll, verändert aber keine anderen DCC-Übertragungsparameter laut Tabelle A.2 in [TS 102 687]. DP0-Meldungen sind von dieser Einschränkung ausgenommen.
(36)Ist die fahrzeugseitige C-ITS-Station nicht mit einem CEN-DSRC-Funkmelder gemäß Beschreibung in Satz 5.2.5 von [TS 102 792] ausgestattet, führt sie ein Verzeichnis von Schutzzonenpositionen gemäß Beschreibung in Satz 5.5.1 von [TS 102 792]. Dieses Verzeichnis setzt sich wie folgt zusammen:
·einem Satz von Schutzzonen, die in der „neuesten Fassung“ (verfügbar, als das Fahrzeug entwickelt wurde) der Datenbank für Schutzzonen aufgeführt werden. Die fahrzeugseitige C-ITS-Station kann einen Aktualisierungsmechanismus für die Datenbank enthalten.
·einem Satz von Schutzzonen, die mittels Empfang von CEN-DSRC Reduzierungs-CAM gemäß Beschreibung in den Sätzen 5.2.5 und 5.2.2.3 von [TS 102 792] identifiziert wurden;
·einer vorübergehend geschützten Zone, die mittels Empfang von CEN-DSRC Störungsminderungs-CAM gemäß Beschreibung in Satz 5.2.2.2 von [TS 102 792] identifiziert wurde.
(37)Ist die fahrzeugseitige C-ITS-Station mit einem CEN-DSRC-Funkmelder ausgestattet, wird eine Störungsminderung gemäß Beschreibung in Satz 5.2.5 von [TS 102 792] angewendet und die C-ITS-Station des Fahrzeugs generiert CAM gemäß Satz 5.5.1 von [TS 102 792].
(38)Ist die fahrzeugseitige C-ITS-Station nicht mit einem CEN-DSRC-Funkmelder ausgestattet, so wird gemäß [TS 102 792] eine Störungsminderung auf Basis des unter Nummer (36) definierten Verzeichnisses und der empfangenen CAM anderer Verkehrsteilnehmer, die Nummer (37) implementiert haben, angewendet.
Anmerkung: Klarstellung von Satz 5.2.5 der [TS 102 792]: Eine mobile ITS-Station sollte jedes Mal eine Störungsminderung zur nächstgelegenen Position einer Mauterhebungsstation durchführen. Werden mehrere Positionen im gleichen Gebiet angegeben, sollte die mobile ITS-Station jeder Stationsposition antworten, wobei dies möglicherweise nacheinander erfolgen kann. Schutzzonen mit identischer SchutzZonenID können als eine einzige Station betrachtet werden. Enthalten die Datenbank für Schutzzonen und die CEN-DSRC Störungsminderungs-CAM eine gültige Schutzzone mit identischer SchutzZonenID, wird der Störungsminderung nur der Inhalt der CEN-DSRC Störungsminderungs-CAM zugrunde gelegt.
2.7.Vernetzungs- und Beförderungsebene
(39)Der medienunabhängige Teil des GeoNetworking (GN) der fahrzeugseitigen C-ITS-Station muss der Norm [EN 302 636-4-1] entsprechen.
(40)Alle vorgegebenen Konstanten und Parameter des Profils der fahrzeugseitigen C-ITS-Station, die in dieser Verordnung nicht definiert oder aufgehoben werden, werden gemäß Anhang H der Norm [EN 302 636-4-1] festgelegt.
(41)GN wird mit auf pGnSecurity festgelegter itsGnSecurity verwendet.
(42)GN wird mit auf pGnAddrConfMode festgelegter itsGnLocalAddrConfMethod verwendet.
(43)Der GN-Parameter itsGnMaxGeoAreaSize wird auf pGnMaxAreaSize festgelegt.
(44)GeoNetworking (GN) führt in einer fahrzeugseitigen C-ITS-Station keine Paketwiederholung durch und die entsprechenden Schritte in den Verfahren für die Handhabung von Meldungspaketen gemäß Beschreibung in Satz 10.3 von [EN 302 636-4-1] werden nicht ausgeführt.
Der Parameter „maximale Wiederholungszeit“ des Dienstes GN-DATEN-Anforderung und die GN-Protokollkonstante itsGnMinPacketRepetitionInterval gelten für fahrzeugseitige C-ITS-Stationen nicht.
(45)GN wird mit einem auf pGnInterfaceType GN-Schnittstellentyp (GnIfType) eingesetzt.
(46)Die fahrzeugseitige C-ITS-Station nutzt bei allen CAM-Paketen, die sie sendet, die Kopfsätze „Ausstrahlung in Einzeletappe“ (Single Hop Broadcast (SHB)) gemäß der Definition in [EN 302 636-4-1].
Demzufolge verwendet der gemeinsame GN-Kopfsatz bei der Übertragung von SHB-Paketen für das HT-Feld einen Wert von pGnShbHtField und für das HST-Feld einen Wert von pGnShbHstField.
Die fahrzeugseitige C-ITS-Station nutzt bei allen DENM-Paketen, die sie sendet GBC-Kopfsätze gemäß der Definition in [EN 302 63641].
Demzufolge verwendet der gemeinsame GN-Kopfsatz bei der Übertragung von DENM-Paketen für das HT-Feld einen Wert von pGnGbcHtField.
Für das HST-Feld wird einer der folgenden Werte verwendet:
·0 für kreisförmige Gebiete;
·1 für rechteckige Gebiete;
·2 für ellipsenförmige Gebiete.
Anmerkung: Dieses Profil gilt für die Handhabung von SHB- und GBC-Paketen. Es erstreckt sich nicht auf die Handhabung anderer, in [EN 302 636-4-1] definierter GN-Pakettypen und steht somit deren Implementierung nicht entgegen.
(47)Die fahrzeugseitige C-ITS-Station legt das Feld LebensDauer aller SHB-Pakete auf folgende Weise fest:
·das Teilfeld Multiplikator auf pGnShbLifeTimeMultiplier [Lebensdauermultiplikator] und das Teilfeld Basis auf pGnShbLifeTimeBase [Lebensdauerbasis] setzen.
(48)Die fahrzeugseitige C-ITS-Station setzt das Feld LebensDauer aller GBC-Pakete auf den Mindestwert für GültigkeitsDauer und WiederholungsIntervall, sofern GültigkeitsDauer und WiederholungsIntervall im maßgeblichen Dienstprofil definiert worden sind. Der Wert des Feldes LebensDauer darf die itsGnMaxPacketLifetime gemäß der Spezifikation in Anhang H der Norm [EN 302 636-4-1] nicht übersteigen.
(49)Die fahrzeugseitige C-ITS-Station speichert GBC-Pakete zwischen, wenn keine Nachbarn verfügbar sind (Speichervortrag). Demzufolge wird das Bit SpeicherVortrag (Store Carry Forward (SCF)) des TC-Feldes von GBC-Paketen auf pGnGbcScf gesetzt.
(50)Die fahrzeugseitige C-ITS-Station braucht keine Pakete zur Kanalentlastung in einen anderen umzuladen. Demzufolge ist das Bit „Kanalentlastung“ des TC-Feldes auf pGnChannelOffLoad zu setzen.
(51)Die fahrzeugseitige C-ITS-Station verwendet die unter Nummer (28) spezifizierten DCC-Profile. Demzufolge nutzen die Bits „DCC-Profil-ID“ des TC-Feldes die unter Nummer (28) definierten Werte für die DCC-Profilidentifizierung.
(52)Die fahrzeugseitige C-ITS-Station setzt das Bit itsGnIsMobile des Feldes „Flags“ auf pGnIsMobile.
(53)Die fahrzeugseitige C-ITS-Station unterstützt den Betriebsmodus für Mehrfachetappen. Sie implementiert den in den Anhängen D, E.3 und F.3 zu [EN 302 63641] spezifizierten Weiterleitungsalgorithmus.
(54)Bei der Weiterleitung von Paketen verwendet die fahrzeugseitige C-ITS-Station das in [TS 102 724] definierte DCC-Profil DP3, auf das unter Nummer (28) Bezug genommen wird.
(55)Die fahrzeugseitige C-ITS-Station verwendet auf der Vernetzungs- und Beförderungsebene eine Erkennung für doppelte Pakete. Demzufolge wird der in Anhang A.2 zu [EN 302 636-4-1] spezifizierte Algorithmus für die Erkennung doppelt vorhandener Pakete verwendet.
(56)Alle von der fahrzeugseitigen C-ITS-Station gesendeten GN-Rahmen nutzen den EtherType-Wert pGnEtherType, den die Registrierungsstelle des Instituts für Elektro- und Elektronik-Ingenieure (IEEE) unter http://standards.ieee.org/develop/regauth/ethertype/eth.txt aufführt.
(57)Das grundlegende Verkehrsprotokoll (Basic Transport Protocol (BTP)) der fahrzeugseitigen C-ITS-Station muss der Norm [EN 302 636-5-1] entsprechen.
(58)Die fahrzeugseitige C-ITS-Station benutzt BTP-B-Kopfsätze. Demzufolge verwendet der gemeinsame GN-Kopfsatz für das NH-Feld einen Wert von pGnBtpNh.
(59)Die fahrzeugseitige C-ITS-Station setzt das Feld Zielport-Info auf den Wert pBtpDestPortInfo.
(60)Im BTP-B-Kopfsatz setzt die fahrzeugseitige C-ITS-Station den Zielport für CAM auf den Wert pBtpCamPort.
(61)Im BTP-B-Kopfsatz setzt die fahrzeugseitige C-ITS-Station den Zielport für DENM auf den Wert pBtpDenmPort.
(62)Die fahrzeugseitige C-ITS-Station unterstützt kreisförmige, rechteckige und ellipsenförmige Gebiete gemäß der Definition in [EN 302 931]. Jeder im maßgeblichen Dienstprofil definierte Einsatzfall muss eine der vorstehend genannten Arten von geografischen Gebieten spezifizieren; diese werden durch den GN-Kopfsatz gemäß der Norm [EN 302 636-4-1] angezeigt.
(63)Berechnet eine fahrzeugseitige C-ITS-Station die Entfernung zwischen zwei Positionen mit Hilfe von Galileo oder anderen GNSS-Koordinaten (z. B. für StreckenDeltaPunkte oder bei kreisförmigen Relevanzgebieten), wird die Großkreisentfernung oder eine genauere Leistungen erbringende Methode genutzt.
2.8.Anlagenebene
(64)Der Basisdienst „kooperative Aufklärung“ (Cooperative Awareness Basic Service) der fahrzeugseitigen C-ITS-Station muss der Norm [EN 302 637-2] entsprechen.
(65)Das Feld „Streckenhistorie“ im CAM-Niederfrequenzcontainer wird nach der unter Nummer (86) spezifizierten Methode generiert und enthält ein Datenelement „Streckenhistorie“, das eine Mindestentfernung von pCamTraceMinLength abdeckt (der Parameter K_PHDISTANCE_M gemäß der Definition in Anhang A.5 zu [SAE J2945/1]).
Eine Ausnahme von der von der Streckenhistorie mindestens abgedeckten Entfernung wird nur gemacht, wenn:
·das Fahrzeug die abgedeckte Entfernung mit seinem aktuellen Berechtigungsschein (AT) physisch noch nicht zurückgelegt hat (z. B. nach dem Starten des Fahrzeugs oder unmittelbar nach einem Wechsel des Berechtigungsscheins während der Fahrt); oder
·wenn die Höchstzahl an StreckenPunkten genutzt wird, die von der Streckenhistorie abgedeckte Gesamtlänge aber pCamTraceMinLength noch nicht erreicht.
Anmerkung: Dies kann der Fall sein, wenn die Straßentopologie enge Kurven umfasst und die Entfernung zwischen aufeinanderfolgenden StreckenPunkten verkürzt wird.
Das Fahrzeug darf nur in den vorstehend genannten Fällen Streckenhistorie-Informationen senden, die eine geringere Entfernung als pCamTraceMinLength abdecken.
(66)Die Streckenhistorie in CAM deckt höchstens pCamTraceMaxLength ab.
(67)Die Streckenhistorie in CAM schließt an jeden StreckenPunkt die StreckenDeltaZeit ein. Sie beschreibt eine Liste tatsächlich durchfahrener geografischer Standorte, die – geordnet nach der Zeit, zu der das Fahrzeug die Positionen erreichte – zur derzeitigen Fahrzeugposition führen, wobei der erste Punkt der zeitlich der aktuellen Zeit am nächsten liegende Punkt ist.
(68)Bewegt sich die fahrzeugseitige C-ITS-Station nicht, d. h. ändern sich die Informationen zur StreckenPunkt-Position nicht, wird die StreckenDeltaZeit des ersten StreckenPunktes trotzdem bei jeder CAM aktualisiert.
(69)Bewegt sich die fahrzeugseitige C-ITS-Station nicht, d. h. ändern sich die Informationen zur StreckenPunkt-Position über eine Zeitspanne, die länger als der Höchstwert der StreckenDeltaZeit (spezifiziert in [TS 102 894-2]) ist, nicht, wird die StreckenDeltaZeit des ersten StreckenPunktes in der CAM auf den Höchstwert festgesetzt.
(70)Der CA-Basisdienst bleibt solange aktiv, wie sich das Fahrzeug mit regulärer Fahrdynamik auf öffentlichen Straßen befindet. Solange der CA-Basisdienst aktiv ist, werden CAM nach den Regeln in der Norm [EN 302 637-2] generiert.
(71)Eine fahrzeugseitige C-ITS-Station überträgt CAM-Meldungen, soweit Informationen zur Zuverlässigkeit der Position vorhanden sind und die Stationsuhr Nummer (91) entspricht.
(72)Der Verkehrsklassewert (TC) für CAM-Meldungen wird auf pCamTrafficClass gesetzt.
(73)Der Parameter T_GenCam_Dcc (siehe [EN 302 637-2]) wird auf den Wert der kürzesten Zeit zwischen zwei Übertragungen, Toff, gesetzt, wie in Tabelle A.2 (DCC Mechanismen) in [TS 102 687] angegeben.
(74)Der im Management für die CAM-Generierungshäufigkeit spezifizierte, einstellbare Parameter N_GenCam (siehe [EN 302 637-2]) wird für die fahrzeugseitige C-ITS-Station auf pCamGenNumber gesetzt.
(75)Der Basisdienst der dezentralen Umfeldbenachrichtigungen (DEN) der fahrzeugseitigen C-ITS-Station muss der Norm [EN 302 637-3] entsprechen.
(76)Die Wiederholung der DENM wird vom DEN-Basisdienst gemäß der Norm [EN 302 637-3] vorgenommen.
(77)Das Feld „Streckenhistorie“ in DEN-Meldungen wird nach der unter Nummer (86) spezifizierten Methode erzeugt und enthält Verfolgungsspur-Datenelemente, die eine Mindestentfernung von pDenmTraceMinLength abdecken (der in Anhang A.5 zu [SAE J2945/1] definierte Parameter K_PHDISTANCE_M).
Eine Ausnahme von der mittels Verfolgungsspuren mindestens abgedeckten Entfernung wird nur gemacht, wenn:
·das Fahrzeug die abgedeckte Entfernung mit seinem aktuellen Berechtigungsschein (AT) physisch noch nicht zurückgelegt hat. (z. B. nach dem Starten des Fahrzeugs oder unmittelbar nach einem Wechsel des Berechtigungsscheins während der Fahrt); oder
·wenn die Höchstzahl an StreckenPunkten genutzt wird, die von der StreckenHistorie abgedeckte Gesamtlänge aber pDenmTraceMinLength noch nicht erreicht.
Anmerkung: Dies kann der Fall sein, wenn die Straßentopologie enge Kurven umfasst und die Entfernung zwischen aufeinanderfolgenden StreckenPunkten verkürzt wird.
Das Fahrzeug darf nur in den vorstehend genannten Fällen Verfolgungsspurinformationen senden, die eine geringere Entfernung als pDenmTraceMinLength abdecken.
(78)Die Verfolgungsspuren in den DENM dürfen höchstens die pDenmTraceMaxLength abdecken.
(79)Eine fahrzeugseitige C-ITS-Station verwendet DENM-Verfolgungsspuren wie folgt:
·Das erste Element der Verfolgungsspur beschreibt eine nach Zeit geordnete Liste tatsächlich durchfahrener geografischer Standorte, die, wie in Nummer (67) angegeben, zu der Ereignisposition führen.
(80)Die Datenelemente StreckenDeltaZeit der StreckenPunkte im ersten Element der DENM-Verfolgungsspur werden nur aktualisiert, wenn die DENM aktualisiert wird.
(81)Bewegt sich das ereigniserkennende Fahrzeug nicht, d. h. ändert sich die Information zur Position des StreckenPunkts nicht, wird die StreckenDeltaZeit des ersten Streckenpunktes des ersten Elements der DENM-Verfolgungsspur trotzdem mit jedem DEN_Update aktualisiert.
Anmerkung: Dies ist nur bei stationären Ereignissen der Fall, bei denen das erkennende Fahrzeug mit dem Ereignis identisch ist, z. B. bei einer Warnung vor stehendem Fahrzeug. Bei dynamischen Ereignissen wie Gefahrensituationen oder Ereignissen, die nicht mit dem Fahrzeug identisch sind (Warnungen vor widriger Witterung usw.) trifft dies nicht zu.
(82)Bewegt sich die fahrzeugseitige C-ITS-Station nicht, d. h. ändern sich die Informationen zur StreckenPunkt-Position über eine Zeitspanne, die länger als der Höchstwert der StreckenDeltaZeit (spezifiziert in [TS 102 894-2]) ist, nicht, wird die StreckenDeltaZeit des ersten DENM-Verfolgungselements auf den Höchstwert festgesetzt.
(83)In den DENM-Verfolgungsspuren können weitere Elemente der StreckenHistorie vorhanden sein. Anders als das erste Element beschreiben diese jedoch alternative Strecken zum Ereignis. Die Strecken können am Zeitpunkt der Ereigniserkennung verfügbar oder nicht verfügbar sein. Auf den alternativen Strecken werden die StreckenPunkte nach Position geordnet (d. h. Strecken mit der kürzesten Strecke) und enthalten keine StreckenDeltaZeit.
(84)Für die vorrangigen Dienste generiert die fahrzeugseitige C-ITS-Station nur DENM gemäß Beschreibung im maßgeblichen Dienstprofil.
(85)Die Datenelemente, die den Inhalt der CAM und DENM bilden, müssen [TS 102 894-2] entsprechen und verwenden das in den Nummern (87), (10) und (11) spezifizierte Koordinatensystem.
(86)Die von der fahrzeugseitigen C-ITS-Station verwendeten Verfolgungsspuren und Streckenhistorien werden mit Hilfe der Design Method One [Konstruktionsmethode] gemäß Anhang A.5 der Norm [SAE J2945/1] generiert. Die fahrzeugseitige C-ITS-Station verwendet diese Generierungsmethode mit folgenden Einstellungen:
·K_PHALLOWABLEERROR_M = pTraceAllowableError, dabei ist PH_ActualError < K_PHALLOWABLEERROR_M;
·maximal Entfernung zwischen präzisen Streckenpunkten, K_PH_CHORDLENGTHTHRESHOLD = pTraceMaxDeltaDistance;
·K_PH_MAXESTIMATEDRADIUS = REarthMeridian;
·K_PHSMALLDELTAPHI_R = pTraceDeltaPhi;
·REarthMeridian = pTraceEarthMeridian (laut IUGG), wird für die Berechnung von Großkreisen oder der orthodromischen Entfernung verwendet:
PH_ActualChordLength =
REarthMeridian*cos-1[cos(lat1)cos(lat2)cos(long1-long2)+sin(lat1)sin(lat2)]
(87)Die fahrzeugseitige C-ITS-Station nutzt ein Koordinatensystem, das mit Abschnitt 2.13 der [ISO 8855] konform ist.
Anmerkung: Dies bedeutet, dass die X- und die Y-Achse parallel zur Grundebene stehen, die Z-Achse senkrecht nach oben ausgerichtet ist, die Y-Achse auf die linke Seite der Vorwärtsrichtung des Fahrzeugs zeigt und dass die X-Achse zur Vorwärtsfahrtrichtung des Fahrzeuges weist.
2.9.Anforderungen im Zusammenhang mit der Hardware
(88)Die statistische Sicherheit von 95 % (siehe Abschnitt 2.1 Buchstabe b und Nummer (12)) gilt in jedem der in Nummer (92) aufgeführten Szenarien. Dies bedeutet, dass in einem Test zur Beurteilung der statistischen Sicherheit (der offline stattfinden kann) eine statistische Mittelung aller Zustände und Szenarien nicht geeignet ist.
Stattdessen wird ein gleitendes Fenster mit den Fahrzeugzuständen (siehe Abschnitt 2.1 Buchstabe a) der letzten Sekunden von pPotiWindowTime als statistische Grundlage verwendet.
Anmerkung: Der vorgeschlagene Mechanismus zur Validierung der statistischen Sicherheit mit Hilfe des gleitenden Fensters wird üblicherweise offline in Form einer Nachbearbeitung erfasster Testdaten durchgeführt. Es ist nicht erforderlich, dass die fahrzeugseitige C-ITS-Station online, d. h. während sie sich mit regulärer Fahrdynamik auf öffentlichen Straßen befindet, eine Validierung der statistischen Sicherheit durchführt.
Anmerkung: Der Ansatz des gleitenden Fensters bietet gegenüber nach einzelnen Szenarien getrennten Statistiken folgende Vorteile:
·Übergänge zwischen Szenarien werden eingeschlossen;
·die statistische Sicherheit gilt „jetzt“ und nicht „für die Lebensdauer“. „Plötzliche Fehleranhäufungen“ (viele ungültige Werte für die statistische Sicherheit innerhalb kurzer Zeit) sind nicht zulässig, was
·den Nutzen des statistischen Sicherheitswerts für Anwendungen erhöht;
·eine schnelle Feststellung von Genauigkeitsverlusten innerhalb von POTI (Position und Zeit) erfordert;
·die präzise Abgrenzung der Testdaten wirkt sich nicht auf die Parameter zur Validierung der statistischen Sicherheit aus. Gleichwohl müssen die Testdaten alle unter Nummer (92) aufgeführten Szenarien enthalten;
·weitere statistische Berechnungen sind nicht erforderlich; die Szenarien decken alle maßgeblichen Zustände ab;
·die Intervalllängen ähneln der Länge typischer Szenarien für Umfeld- und Fahrbedingungen (z. B. Stadttunnel, Warten an einer Verkehrsampel, Fahrmanöver);
·5 % der Intervalle ähneln typischen kurzfristigen Effekten (z. B. Fahren unter einer Brücke).
(89)Von einem Fahrzeug wird angenommen, dass es sich in regulärer Fahrdynamik befindet, wenn:
·es die anfängliche Startphase durchlaufen hat;
·es wie vom Hersteller vorgesehen verwendet wird;
·eine normale Lenkung des Fahrzeugs möglich ist (Beispiele: es ist nicht unmittelbar in einen Unfall verwickelt; die Fahrbahnoberfläche erlaubt eine normale Reifenhaftung);
·alle folgenden Bedingungen (Werte) gelten für Personenkraftwagen:
·die Querbeschleunigung des Fahrzeugs beträgt < 1,9 m/s^2;
·d > -2,4 m/s^2 (Verzögerung);
·die Längsbeschleunigung des Fahrzeugs beträgt < 2,5 m/s^2;
·die Fahrzeuggeschwindigkeit beträgt ≤ Minimum von (130 km/h, Vmax).
(90)Unter optimalen GNSS-Bedingungen und bei regulärer Fahrdynamik gemäß der Definition in Nummer (89) sollten an mindestens 95 % der 3D-Positionsdatenpunkte in einem Datensatz die Werte der statistischen Sicherheit den folgenden Werten entsprechen oder sie unterschreiten:
·statistische Sicherheit der horizontalen Position 5 m;
·statistische Sicherheit der vertikalen Position 20 m.
In anderen Szenarien gelten die Anforderungsherabsetzungen unter Nummer (92). Diese Anforderung stellt in allen C-ITS-Meldungen die Nützlichkeit der gesendeten Informationen sicher.
(91)Die Stationsuhr liegt innerhalb der Grenzen der pPotiMaxTimeDiff der C-ITS-Zeit, d. h. Delta t = |Stationsuhrzeit - C-ITS-Zeit| < pPotiMaxTimeDiff.
(92)Eine fahrzeugseitige C-ITS-Station muss in der Lage sein, auch in schwierigen Szenarien nützliche Schätzungen des Fahrzeugzustands bereitzustellen. Zur Berücksichtigung unvermeidlicher Qualitätsverluste werden in Tabelle 2 die für die statistische Sicherheit erforderlichen Werte für verschiedene Szenarien definiert.
„C“ ist der Höchstwert von semiMajorConfidence und semiMinorConfidence. Die für „C“ geltende Bedingung wird im Datensatz des jeweiligen Szenarios an 95 % der Datenpunkte erfüllt.
Anmerkung: Bezüglich des analysierten Abschnitts der Verfolgungsspur müssen die Kriterien bei folgender Gefälledynamik erfüllt werden: durchschnittliches Gefälle <= 4 % und maximales Gefälle <= 15 %.
Anmerkung: Als Voraussetzung gilt, dass jedes Szenario mit einer Minute Fahren im Freien unter regulärer Fahrdynamik begonnen wird.
Anmerkung: Keine C-Werte zeigen an, dass das Szenario getestet werden muss, um sicherzustellen, dass das gemeldete Vertrauensintervall gültig ist, es wird aber kein Grenzwert angegeben.
Tabelle 2: Szenarien
|
ID
|
Szenario
|
Definition
|
Annahme
|
|
Umfeld bei regulärer Fahrdynamik
|
|
S1
|
Freier Himmel
|
Der Himmel ist weniger als 20 % verdeckt, wobei sich das Fahrzeug mit normaler Fahrdynamik bewegt; normale Straßenverhältnisse
|
C <= 5 m
|
|
S2
|
Tunnel
|
Mindestens 30 s und 250 m (vmin=30 km/h) lang ist kein GNSS-Satellit sichtbar; GNSS-Signalreflektion an Ein- und Ausgang des Tunnels
|
C < 15 m
|
|
S3
|
Parkgebäude
|
Keine unmittelbar sichtbaren GNSS-Satelliten, aber Verbindungen durch Reflektionen, T > 60 s, vmax < 20 km/h, mindestens zwei 90 °-Kurven und s > 100 m, zwei Rampen in Ein- und Ausfahrtsbereich
|
jeder Wert ist zulässig
|
|
S4
|
Halb freier Himmel
|
Der Himmel ist länger als 30 s lang 30-50 % verdeckt (Verdeckung an einer Seite des Wagens konzentriert); Fahrbedingungen wie S1
|
C < 7 m
|
|
S5
|
Wald
|
Der Himmel ist länger als 30 s lang zu 30-50 % von Objekten unter Einschluss von Bäumen, die höher als die Antenne sind, verdeckt.
|
C < 10 m
|
|
S6
|
Berge (Tal)
|
Der Himmel ist zu 40-60 % von hohem/n Berg(en) verdeckt; Fahrbedingungen wie S1
|
C < 10 m
|
|
S7
|
Stadt
|
Auf einer Fahrt von 300 s war der Himmel 30-50 % verdeckt (kurze Zeiträume mit weniger als 30-50 % Verdeckung zulässig), es kam zu häufigen Reflektionen des GNSS-Signals von Gebäuden unter Einschluss von kurzen Verlusten des GNSS-Signals (d. h. weniger als vier Satelliten); Fahrbedingungen wie S1
|
C < 14 m
|
|
S8
|
Moderat städtisch
|
Der Himmel ist zu 2040 % verdeckt, t > 60 s, s > 400 m. Fahrbedingungen wie S1, mit Stopps, Bäumen und/oder Gebäuden sowie Alleen.
|
C < 10 m
|
|
Fahrbedingungen im Freien
|
|
S9
|
Dynamisches Fahren
|
Testfahrt mit Längsbeschleunigungen von mehr als -6 m/s² und Querbeschleunigungen von > (±) 5 m/s²
|
C < 7 m
|
|
S10
|
Statisch
|
30 min Fahrzeugstillstand
|
C < 5 m
|
|
S11
|
Unebene Fahrbahn
|
Testfahrt auf unbefestigter Straße mit Schlaglöchern, v= 20-50 km/h
|
C < 10 m
|
|
S12
|
Vereiste Fahrbahn
|
Testfahrt mit Längsbeschleunigungen von mehr als -0,5 m/s² und Querbeschleunigungen von > (±) 0,5 m/s², µ < 0,15
|
C < 7 m
|
|
S13
|
Hohe Geschwindigkeit
|
V= minimum von (130 km/h, Vmax) 30 s lang auf trockener Fahrbahn
|
C < 5 m
|
(93)Unter optimalen GNSS-Bedingungen und bei regulärer Fahrdynamik gemäß der Definition in Nummer (89) sollten an mindestens 95 % der Datenpunkte in einem Datensatz die Geschwindigkeitswerte der statistischen Sicherheit folgenden Werten entsprechen oder sie unterschreiten:
·0,6 m/s bei Geschwindigkeiten zwischen 1,4 m/s und 12.5 m/s;
·0,3 m/s bei Geschwindigkeiten größer als 12,5 m/s.
(94)Unter optimalen GNSS-Bedingungen und bei regulärer Fahrdynamik gemäß der Definition in Nummer (89) sollten an mindestens 95 % der Datenpunkte in einem Datensatz die den Kurs betreffenden Werte der statistischen Sicherheit folgenden Werten entsprechen oder sie unterschreiten:
·3° bei Geschwindigkeiten zwischen 1,4 m/s und 12,5 m/s;
·2° bei Geschwindigkeiten größer als 12,5 m/s.
3.Anforderungen an straßenseitige C-ITS-Stationen, die auf Nahbereichskommunikation ausgelegt sind
Dieses Systemprofil legt einen Mindestsatz an Normen fest und füllt erforderlichenfalls Informationslücken bezüglich der Realisierung einer dialogfähigen, straßenseitigen C-ITS-Station auf der Senderseite. Das Profil umfasst nur Anforderungen an die Dialogfähigkeit und lässt etwaige zusätzliche Anforderungen offen. Es beschreibt folglich nicht die vollständige Funktionsweise der straßenseitigen C-ITS-Station.
Das Systemprofil ermöglicht den Einsatz der Prioritätsdienste (insbesondere von Infrastruktur zu Fahrzeug (I2V)). Es kann auch andere Dienste unterstützen, diese erfordern aber eventuell weitere Systemspezifikationen.
Das Profil stellt Beschreibungen, Definitionen und Regeln für die Ebenen der Referenzarchitektur und des Managements von ETSI ITS-Station /ITS-S Host bereit (Anwendungen, Einrichtungen, Vernetzung & Verkehr sowie Zugang).
3.1.Positionierung und Timing
(95)Die C-ITS-Zeit einer statischen straßenseitigen C-ITS-Station bildet die Grundlage für alle Zeitstempel in allen übertragenen Meldungen und GeoNetworking (GN) Funkbaken.
Anmerkung: Dies bedeutet, dass Zeitstempel in GN-Kopfsätzen in CAM/DENM/IVIM-Nutzdaten die gleiche Uhr- und Zeitbasis verwenden müssen. Bei SPATEM und MAPEM sollte der Zeitstempel der Spezifikation in [ISO TS 19091] entsprechen.
(96)Die Position statischer straßenseitiger C-ITS-Stationen wird genau gemessen und dauerhaft eingestellt.
Die Werte für die statistische Sicherheit entsprechen in mindestens 95 % der Datensätze den folgenden Werten oder unterschreiten sie:
·statistische Sicherheit der horizontalen Position (Breite, Länge) von 5 m;
·statistische Sicherheit der Position von 20 m über NN.
Anmerkung: Damit wird bei der Positionsgenauigkeit GNSS-Jitter vermieden und die statistische Sicherheit auf fast 100 % gesteigert.
(97)Die Differenz zwischen Stationsuhr und Zeitbasis wird geschätzt. Die absolute Differenz |Stationsuhrzeit — Zeitbasis| sollte 20 ms nicht überschreiten, muss aber auf jeden Fall weniger als 200 ms betragen. Die straßenseitige C-ITS-Station überträgt keine Meldungen, wenn die Stationsuhrzeit um mehr als 200 ms abweicht.
Anmerkung: Ein genauer Zeitstempel ist nicht nur für die Zeitsynchronisierung erforderlich, sondern bedeutet auch, dass die Systemzustände an genau dem betreffenden Zeitpunkt gültig sind, d. h. dass die Systemzustände kohärent bleiben.
Anmerkung: Die Informationen für die Zeitsynchronisierung können bei einem Galileo- oder anderen GNSS-Empfänger oder bei einem Netzzeitprotokoll-Dienst (NTP) eingeholt werden.
3.2.Systemverhalten
(98)Alle straßenseitigen C-ITS-Stationen müssen in der Lage sein, die Infrastrukturmeldungen zu senden (z. B. DENM, CAM, Informationsmeldungen Infrastruktur - Fahrzeug (IVIM), Meldung Ampelphase und Timing erweitert (SPATEM), MAP-erweiterte Meldung (MAPEM) und Meldung (Ampel)Signalanforderung, Status erweitert (SSEM).
(99)Straßenseitige C-ITS-Stationen müssen in der Lage sein, DENM, CAM und Meldungen für erweiterte (Ampel)-Signalanforderungen (SREM) gemäß der Definition in Abschnitt 3.6 zu empfangen.
3.3.Zugangsebene
Die Zugangsebene umfasst die beiden niedrigsten Ebenen im Protokoll-Stack, d. h. physische (PHY) Ebene und die Daten-Linkebene, wobei letztere in Medienzugangssteuerung (MAC) und logische Verbindungssteuerung (LLC) unterteilt ist.
(100)Straßenseitige C-ITS-Stationen nutzen die optionalen erweiterten Empfängerleistungsanforderungen gemäß der Definition in IEEE 802.11-2016 Tabellen 17-19.
(101)Straßenseitige C-ITS-Stationen nutzen für das Senden von Meldungen zur Unterstützung der vorrangigen C-ITS-Dienste gemäß der Spezifikation in Anhang 3 den Steuerkanal G5-CCH gemäß Tabelle 3 in [EN 302 663] und verwenden eine vorgegebene Übertragungsgeschwindigkeit 6 Mbit/s (Vierphasen-Umtastung (QPSK) 1/2).
(102)Die Zugangsebene straßenseitiger C-ITS-Stationen muss der Norm [EN 302 663] entsprechen, mit Ausnahme von Emissionsgrenzen und der Sätze 4.2.1, 4.5 und 6.
(103)Straßenseitige C-ITS-Stationen müssen [TS 102 687] entsprechen.
(104)Straßenseitige C-ITS-Stationen müssen die ihnen zur Verfügung stehenden, begrenzten Hard- und Softwareressourcen verwalten und können dem Grundsatz der „größten Anstrengung“ entsprechend Verkehrsformung (Traffic Shaping) oder selektive Weiterleitungen praktizieren.
Anmerkung: Verkehrsformung ist besonders für weitergeleitete DENM-Meldungen relevant, denn es ist davon auszugehen, dass in bestimmten Situationen (wie großen Verkehrsstaus oder anderen extremen Szenarien im Fahrzeugnetz) die DENM-Last abrupt zunehmen könnte. In derartigen Fällen ist es straßenseitigen C-ITS-Stationen ausdrücklich erlaubt, auf die Weiterleitung fremder DENM-Meldungen zu verzichten.
(105)Die straßenseitige C-ITS-Station muss mindestens in der Lage sein, die durch den Wert der höchsten CAM-Generierungsfrequenz (d. h. 10 Hz) bestimmte Anzahl an Meldungen zu generieren und zu übertragen; werden Erkennungsalgorithmen verwendet, wird dieser Wert um die aus diesen Auslösebedingungen abgeleitete, zumindest erforderliche DENM-Generierungsfrequenz erhöht.
(106)Straßenseitige C-ITS-Stationen müssen den in der Norm [EN 302 663] festgelegten Ausstrahlmodus (Broadcast Mode) unterstützen.
(107)Eine Schutzzone ist wie folgt definiert:
·Besteht ein Mauterhebungsstandort aus einer einzelnen CEN-DSRC Infrastrukturkomponente (Road-side Unit, RSU), so wird eine Schutzzone mit einem vorgegeben Radius von 55 m um dem Standort der CEN-DSRC-Infrastrukturkomponente als Mittelpunkt festgelegt;
·befinden sich mehrere CEN-DSRC-Infrastrukturkomponenten in der Nähe, so sind Überschneidungen von Schutzzonen durch die Bildung einer kombinierten Schutzzone so weit wie möglich zu vermeiden. Eine kombinierte Schutzzone nutzt den geografischen Mittelpunkt (Umkreismittelpunkt) aller betroffenen DSRC-Infrastrukturkomponenten als Mittelpunkt. Der Radius wird durch den Umkreisradius +55 m vorgegeben. Ein maximaler Radius von 255 m darf aber auf keinen Fall überschritten werden.
Anmerkung: Aufgrund des maximalen Radius von 255 m lassen sich Überschneidungen nicht immer vermeiden.
(108)Befindet sich eine straßenseitige C-ITS-Station in der Nähe von Mauterhebungsgeräten (zumindest innerhalb der Schutzzone), die auf der Basis von CEN-DSRC arbeiten, so muss sie Störungsminderungstechniken gemäß der Definition in [TS 102 792] verwenden.
(109)Mobile straßenseitige C-ITS-Stationen verwenden Störungsminderungsmethoden auf der Grundlage von Ankündigungen von Mauterhebungszonen.
(110)Wird eine straßenseitige C-ITS-Station für die Anzeige einer vorhandenen Mauterhebungsstation eingesetzt, so überträgt sie Schutzzonen umfassende CAM nach der Technik gemäß [TS 102 792] mit dem in der Norm [EN 302 637-2] spezifizierten CA-Meldungsformat. Sie überträgt diese CAM auf dem Steuerkanal, bevor eine fahrzeugseitige C-ITS-Station in die Schutzzone einfährt.
(111)Die Zugangsebene straßenseitiger C-ITS-Stationen muss [TS 102 724] entsprechen.
(112)Straßenseitige C-ITS-Stationen müssen DCC-Techniken gemäß [TS 102 687] verwenden.
3.4.Netz- und Beförderungsebene
(113)Straßenseitige C-ITS-Stationen verwenden gemäß der Norm [EN 302 636-4-1] GN als Vernetzungsprotokoll.
(114)Alle vorgegebenen Konstanten und Parameter des Profils für die straßenseitige Infrastruktur, die in diesem Anhang nicht spezifiziert sind, werden gemäß der Spezifikation in Anhang H der Norm [EN 302 636-4-1] festgelegt.
(115)GN führt keine Paketwiederholung durch und die entsprechenden, in den Pakethandhabungsverfahren in Satz 10.3 der Norm [EN 302 63641] definierten Schritte werden nicht ausgeführt. Der Parameter „maximale Wiederholungszeit“ des Dienstes GN-DATEN-Anforderung und die GN-Protokollkonstante itsGnMinPacketRepetitionInterval gelten nicht.
(116)Straßenseitige C-ITS-Stationen können zur Konfiguration der GN-Adresse „anonyme Adresse“ wählen (itsGnLocalAddrConfMethod auf ANONYMOUS(2) gesetzt).
(117)Straßenseitige C-ITS-Stationen nutzen GN in der Weise, dass itsGnIfType auf ITS-G5(1) gesetzt ist.
(118)Ist die GN-Paketwiederholung deaktiviert, gilt itsGnMinPacketRepetitionInterval nicht.
(119)Das Feld LebensDauer (LifeTime) aller SHB-Pakete wird auf eine Sekunde gesetzt.
(120)Das Feld LebensDauer aller GBC-Pakete wird auf den jeweiligen Mindestwert von GültigkeitsDauer und WiederholungsIntervall gesetzt, darf aber nicht höher als der in Anhang H der Norm [EN 302 636-4-1] spezifizierte Parameter itsGnMaxPacketLifetime sein.
(121)Ist „Speichervortrag“ aktiviert, wird das SCF-Bit im TC-Feld auf eins gesetzt.
Anmerkung: Infolgedessen können Pakete zwischengespeichert werden, wenn keine Nachbarn verfügbar sind.
(122)Eine straßenseitige C-ITS-Station braucht keine Pakete zur Kanalentlastung in einen anderen Kanal umzuladen. Demzufolge ist das Bit „Kanalentlastung“ des TC-Feldes für alle Meldungstypen auf 0 zu setzen.
(123)Stationäre straßenseitige C-ITS-Stationen setzen das Bit itsGnIsMobile des Flag-Feldes auf 0. Mobile straßenseitige C-ITS-Stationen setzen das Bit itsGnIsMobile des Flag-Feldes auf 1.
(124)Straßenseitige C-ITS-Stationen müssen den Betriebsmodus für Mehrfachetappen unterstützen, indem sie die in den Anhängen E.3 und F.3 spezifizierten Algorithmen gemäß den Grundsätzen in Anhang D der Norm [EN 302 636-4-1] verwenden.
(125)Straßenseitige C-ITS-Stationen verwenden auf der Vernetzungs- und Beförderungsebene eine Erkennung für doppelte Pakete. Für die Erkennung doppelter Pakete ist der in Anhang A.2 der Norm [EN 302 636-4-1] spezifizierte Algorithmus zu verwenden.
(126)Straßenseitige C-ITS-Stationen können nur GeoNetworking (GN) Funkbaken (Beacons) senden, deren Anzeiger für Positionsgenauigkeit (Position Accuracy Indicator, PAI) auf 1 gesetzt ist.
(127)Von der straßenseitigen C-ITS-Station gesendete GN-Rahmen nutzen den EtherType-Wert 0x8947, den die Registrierungsstelle des IEEE unter http://standards.ieee.org/develop/regauth/ethertype/eth.txt aufführt.
(128)Straßenseitige C-ITS-Stationen implementieren das BTP gemäß der Norm [EN 302 636-5-1].
(129)Straßenseitige C-ITS-Stationen verwenden BTP-B-Kopfsätze. Demzufolge verwendet der gemeinsame GN-Kopfsatz für das NH-Feld einen Wert von 2.
(130)Straßenseitige C-ITS-Stationen setzen das Feld Zielport-Info auf den Wert 0.
(131)Straßenseitige C-ITS-Stationen stellen den Zielport je nach eingestellter Meldung gemäß der Spezifikation in [TS 103 248] ein.
(132)Geografische Gebiete werden gemäß der Norm [EN 302 931] verwendet.
(133)Straßenseitige C-ITS-Stationen unterstützen mindestens kreisförmige, rechteckige und ellipsenförmige geografische Gebiete gemäß der Definition in [EN 302 931]. Jeder C-ITS-Dienst spezifiziert eine der vorstehend genannten Arten geografischer Gebiete; diese werden durch den GN-Kopfsatz gemäß der Norm [EN 302 636-4-1] angezeigt.
(134)Berechnet die straßenseitige C-ITS-Station die Entfernung zwischen zwei Positionen mithilfe von Galileo oder anderen GNSS-Koordinaten (z. B. für StreckenDeltaPunkte oder bei kreisförmigen Relevanzgebieten), so wird empfohlen, die Großkreisentfernung oder eine genauere Leistungen erbringende Methode zu verwenden. Dabei ist darauf zu achten, dass große Rundungsfehler oder Gleitkommasysteme mit geringer Präzision vermieden werden (indem man beispielsweise die Haversine-Formel einsetzt).
Handelt es sich bei dem Relevanzgebiet um eine Ellipse oder ein Rechteck, müssen die kartesischen Koordinaten des Gebietsmittelpunkts und der aktuellen Position gemäß der Norm [EN 302 931] berechnet werden, damit beurteilt werden kann, ob das Paket in Etappen aufgeteilt werden kann. Zu diesem Zweck wird die Methode der „lokalen Tangentialebene“ oder eine andere, die gleiche Genauigkeit ergebende Methode empfohlen.
3.5.Anlagenebene
(135)Der DEN-Basisdienst straßenseitiger C-ITS-Stationen muss der Norm [EN 302 637-3] entsprechen.
(136)Straßenseitige C-ITS-Stationen setzen die Wiederholung von DENM gemäß der Norm [EN 302 637-3] um.
(137)Die Fälle, in denen DENM-Aktualisierungen ausgelöst werden, werden im relevanten Dienstprofil in Anhang I spezifiziert.
(138)Sendet eine straßenseitige C-ITS-Station eine DENM, werden die Verfolgungsspuren als Liste geografischer Standorte, die von der Ereignisposition bis zum ersten Streckenpunkt zurückführen, beschrieben.
(139)Wird eine mobile straßenseitige C-ITS-Station stationär, so wird die StreckenDeLtaZeit des ersten StreckenPunkts des ersten Elements der DENM-Verfolgungsspuren auf den in der Norm [EN 302 637-3] angegebenen Höchstwert festgesetzt. Daher kommt es nicht zum „Herausfallen“ von DatenPunkten aus dem ersten Element der DENM-Verfolgungsspuren. Dies gilt nur für C-ITS-Dienste, deren Basis ein Anhänger ist.
(140)In den DENM-Verfolgungsspuren können weitere Elemente der StreckenHistorie vorhanden sein. Anders als das erste Element beschreiben diese jedoch alternative Strecken zum Ereignis. Die Strecken können am Zeitpunkt der Ereigniserkennung verfügbar oder nicht verfügbar sein.
(141)Bei straßenseitigen C-ITS-Stationen ist der Verkehrsklassewert (TC) einer Meldung spezifisch für den Basisdienst des Meldungsformats oder den C-ITS-Dienst selbst und wird daher im relevanten Dienstprofil in Anhang I spezifiziert. Der gewählte Verkehrsklassewert muss den Meldungsklassifikationen gemäß der Spezifikation in [TS 102 636-4-2] und [TS 103 301] entsprechen, mit der Ausnahme, dass Meldungen im Rahmen einer Infrastruktur-zu-Fahrzeug-Information (IVI) in Bezug auf veränderliche Geschwindigkeitsbegrenzungen DENM gleichwertige Meldungen mit geringer Priorität sind und daher denselben Verkehrsklassewert haben können.
(142)Das straßenseitige System verwendet ein Koordinatensystem, das mit der Norm [ISO 8855] Abschnitt 2.13 im Einklang steht.
Anmerkung: Dies bedeutet, dass die X- und die Y-Achse parallel zur Grundebene stehen, die Z-Achse senkrecht nach oben ausgerichtet ist, die Y-Achse auf die linke Seite der Vorwärtsrichtung des Fahrzeugs zeigt und dass die X-Achse zur Vorwärtsfahrtrichtung des Fahrzeuges weist.
(143)Für die Übertragung von Meldungen durch straßenseitige Systeme wird gemäß der Spezifikation in [TS 103 301] die Einstellung CPS_001 für das Protokoll und Kommunikationsprofil der Anlagenebene verwendet.
(144)Die in einer von einer straßenseitigen C-ITS-Station gesendeten CAM bereitgestellten Schutzzonendaten dürfen nicht den Schutzzoneninformationen widersprechen, die in der Schutzzonendatenbank oder einer gleichwertigen Datenbank bereitgestellt werden. Wird die gleiche Zone in der Schutzzonendatenbank definiert, wird die gleiche ID als SchutzZonenID verwendet. Andernfalls verwendet man eine ID größer als 67108863, die in der Datenbank nicht genutzt wird.
(145)Straßenseitige C-ITS-Stationen, die für die Verbreitung von Schutzzonendaten vorgesehen sind, übermitteln regelmäßig Schutzzonendaten enthaltende CAM, wobei das in der Norm [EN 302 637-2] spezifizierte Meldungsformat verwendet wird. Eine CAM-Beendigung wird nicht eingesetzt.
Anmerkung: Die spezifischen Datenelemente für den C-ITS-Koexistenzdienst befinden sich im HochFrequenzContainer (highFrequencyContainer) und dem Datenrahmen InfrastrukturkomponentenContainerHochFrequenz (rsuContainerHighFrequency).
Anmerkung: Eine CAM kann andere, nicht mit dem C-ITS-Koexistenzdienst zusammenhängende Datenelemente enthalten.
(146)Die Antennen von für die Verbreitung von Schutzzonendaten vorgesehenen straßenseitigen C-ITS-Stationen werden so angebracht, dass die CAM für die Schutzzone rechtzeitig vor dem Einfahren in die Schutzzone empfangen werden können.
Anmerkung: In den Vorkehrungen für die Erfüllung dieser Anforderungen muss die Verarbeitungszeit berücksichtigt werden, die Geräte von Verkehrsteilnehmern für die Verarbeitung der empfangenen Informationen benötigen. Als Referenz sollte eine Zeit von 300 ms verwendet werden.
(147)Eine für die Verbreitung von Schutzzonendaten vorgesehene straßenseitige C-ITS-Station übermittelt Schutzzonendaten enthaltende CAM mit einer Übertragungsfrequenz, die sicherstellt, dass mobile C-ITS-Stationen in der Lage sind, die Anwesenheit von Schutzzonen rechtzeitig festzustellen.
(148)Für die Verbreitung von Schutzzonendaten vorgesehene straßenseitige C-ITS-Stationen werden außerhalb von Schutzzonen installiert oder gemäß [TS 102 792] konfiguriert.
(149)Eine CAM enthält höchstens eine vorübergehende Schutzzone (d. h. GeschützteKommunikationszone mit SchutzzonenTyp=1).
Anmerkung: Dies bezieht sich speziell auf temporäre Mauterhebungs- und Kontrollfahrzeuge. Mobile C-ITS-Stationen müssen gemäß [TS 102 792] Satz 5.2.2.2 nur eine vorübergehend geschützte Zone speichern, damit Mehrdeutigkeiten vermieden werden.
(150)Wird der Koexistenzdienst der Anlagenebene (ITS-G5 — CEN-DSRC) genutzt, so wird er gemäß [EN 302 637-2] und der Spezifikation in [TS 102 792] verwendet.
(151)[ISO/TS 19321] bezieht sich auf eine ältere Fassung (1.2.1) des gemeinsamen Datenverzeichnisses (CDD) für Nutzlastdaten in [TS 102 894-2]. Daher stützen sich alle auf [ISO/TS 19 321] basierenden IVI C-ITS-Dienste auf die aktualisierte Fassung (1.3.1), bis die [ISO/TS 19321] entsprechend aktualisiert worden ist.
(152)Der CA-Basisdienst ist so lange aktiv, wie die mobile straßenseitige C-ITS-Station bei regulärer Fahrdynamik am Verkehr auf öffentlichen Straßen beteiligt ist. Solange der CA-Basisdienst aktiv ist, werden CAM nach den Regeln in der Norm [EN 302 637-2] generiert.
(153)Straßenseitige C-ITS-Stationen übertragen CAM-Meldungen, soweit Informationen über die Zuverlässigkeit der Position vorhanden sind und die Stationsuhr Nummer (97) entspricht.
(154)Der Parameter T_GenCam_Dcc wird auf die Mindestzeit zwischen zwei Übertragungen, Toff, gesetzt; diese wird von dem in Nummer (103) spezifizierten DCC-Mechanismus bereitgestellt.
(155)Der im Management für die CAM-Generierungsfrequenz spezifizierte, einstellbare Parameter N_GenCam wird für die straßenseitige C-ITS-Station auf 0 gesetzt, sofern sie nicht für die Verbreitung von Schutzzonendaten gemäß Nummer (145) vorgesehen ist.
3.6.Management
Es müssen nicht alle spezifizierten Sicherheitsdienste implementiert werden. Für einige Dienste wird darüber hinaus die Implementierung intern durch den Betreiber der C-ITS-Station festgelegt.
(156)Straßenseitige C-ITS-Stationen zur Umsetzung von ITS-G5-Funktionalitäten müssen eine Managementebene einschließlich einer DCC_CROSS-Einheit gemäß [TS 103 175] implementieren.
3.7.Dienstelemente
3.7.1.DEN-Basisdient
Der DEN-Basisdienst nutzt zur Verbreitung von DENM die von den Protokolleinheiten der ITS-Vernetzungs- und Beförderungsebene bereitgestellten Dienste.
Eine DENM enthält Informationen über ein Ereignis, das sich potenziell auf die Verkehrssicherheit oder die Verkehrsbedingungen auswirken kann. Ein Ereignis wird durch einen Ereignistyp, eine Ereignisposition, eine Erkennungszeit und eine zeitliche Dauer beschrieben. Diese Attribute können sich im räumlichen und zeitlichen Verlauf ändern. DENM-Übertragungen können in bestimmten Situationen von der C-ITS-Station, von der die Meldung ausgeht, unabhängig sein.
Der DEN-Basisdienst erzeugt vier Arten von DENM:
•
Neu-DENM,
•
Aktualisierungs-DENM,
•
Löschungs-DENM,
•
Verneinungs-DENM.
(157)Der DENM-Kopfsatz entspricht der Spezifikation im Datenverzeichnis [TS 102 894-2].
(158)Datenelemente, Datenrahmen und Dienstparameter von DENM werden gemäß Tabelle 3 festgesetzt. Darüber hinaus werden die DENM-Datenrahmen und -Dienstparameter für C-ITS-Dienste für Warnungen vor Straßenarbeiten der Tabelle 4 entsprechend festgesetzt.
Tabelle 3: DENM-Elemente im Allgemeinen
|
Bezeichnung
|
Einsatz
|
Verwendung
|
|
Management-Container
|
Obligatorisch
|
|
|
actionID [MaßnahmenID]
|
obligatorisch
|
Inhalt:
Die actionID (MaßnahmenID) ist die eindeutige Kennung einer DENM und besteht aus den Datenelementen originatingStationID (ID der Station, von der die Meldung ausgeht) und sequenceNumber (SequenzNummer). originatingStationID ist die eindeutige Kennung der C-ITS-Station, deren Anlagenebene die Meldung erzeugte und bei der es sich um die zentrale oder die straßenseitige C-ITS-Station handeln kann. Erfolgt keine Festsetzung durch die zentrale C-ITS-Station, haben Meldungen, deren Inhalt zentral generiert wird, die aber von verschiedenen straßenseitigen C-ITS-Stationen ausgestrahlt werden, unterschiedliche originatingStationID, was zu unterschiedlichen actionIDs (MaßnahmenID) führt.
Werden die originatingStationID und die sequenceNumber (Sequenznummer) von der zentralen C-ITS-Station ausgegeben und wird der zentral generierte Inhalt (möglicherweise) über mehrere straßenseitige C-ITS-Stationen versendet, sieht das System für alle Meldungen bezüglich desselben Ereignisses dieselbe actionID (MaßnahmenID) vor; dabei ist es unerheblich, welche straßenseitige C-ITS-Station die Meldung sendet. Sobald eine actionID (MaßnahmenID) festgelegt worden ist, ändert sie sich bei Meldungen, die sich auf dasselbe Ereignis beziehen, nicht, auch wenn die Meldungen häufig aktualisiert werden.
Wert:
nicht vordefiniert, wird vom System festsetzt
|
|
detectionTime [ErkennungsZeit]
|
Obligatorisch
|
Anfänglich wird dieses Datenelement auf die Uhrzeit gesetzt, zu der das Ereignis erkannt wurde. In Nutzungsszenarien, in denen die straßenseitige C-ITS-Station als eigenständiges Gerät eingesetzt wird, stammt die Zeit aus einer lokalen Zeitquelle. In Nutzungsszenarien, in denen eine Verbindung zur zentralen C-ITS-Station besteht, wird die ErkennungsZeit anfänglich auf die Uhrzeit gesetzt, zu der die Anwendung, die die DENM erzeugt, die maßgebliche Information empfängt, d. h. den Augenblick des Beginns bzw. der Erkennung von Straßenarbeiten oder gefährlichen Situationen auf einer Funktionsebene.
Wert:
die ErkennungsZeit wird anfänglich auf die Zeit des Beginns des Ereignisses (neue DENM) eingestellt und dann für jede Aktualisierung der DENM neu eingestellt. Für die Beendigung der DENM stellt dieses Datenelement die Uhrzeit dar, zu der die Beendigung des Ereignisses erkannt wird.
|
|
referenceTime [ReferenzZeit]
|
Obligatorisch
|
Inhalt:
Die ReferenzZeit wird auf die Uhrzeit eingestellt, zu der die DENM-Meldung generiert oder aktualisiert wird.
Wert:
Automatisch festgelegt
|
|
termination [Beendigung]
|
Optional
|
Spezifisch für den jeweiligen C-ITS-Dienst
|
|
eventPosition [EreignisPosition]
|
Obligatorisch
|
Im Nutzungsszenario „Infrastruktur an Fahrzeug“ wird das Datenfeld EreignisPosition zur Lokalisierung von Fahrstreifen- oder Fahrbahnsperrungen oder gefährlichen Situationen verwendet. Es stellt die Position dar, an der die physische Sperrung auf dem Fahrstreifen (einschließlich des Standstreifens) bzw. der Fahrbahn oder die gefährliche Situation beginnt. Die Genauigkeit muss der Fahrstreifenebene, mindestens aber der Fahrbahnebene entsprechen.
Es können Datenelemente für Höhe über NN und statistische Sicherheit verwendet werden oder die Datenelemente können auf die „nicht verfügbar“ entsprechenden Werte gesetzt werden.
|
|
relevanceDistance [RelevanzEntfernung]
|
Optional
|
Optional
|
|
relevanceTrafficDirection [RelevanzVerkehrsrichtung]
|
Obligatorisch
|
Inhalt:
Fester Wert. Bei Autobahnen wird dieser Wert auf 1 gesetzt (Vorausverkehr).
Dieses Datenfeld gibt an, für welche Verkehrsrichtung die Meldung relevant ist (aus der Perspektive der EreignisPosition).
|
|
validityDuration [GültigkeitsDauer]
|
Obligatorisch
|
Ereignisse werden durch DEN-Meldungen dargestellt. Die Dauer einer einzelnen DENM basiert auf dem (konfigurierbaren) Wert von „validityDuration“ (GültigkeitsDauer). Solange ein Ereignis für den Straßenbetreiber gültig ist, wird es (mittels DENM-Wiederholung) fortlaufend gesendet und aktualisiert (mittels DENM-Aktualisierung, wobei zugleich „GültigkeitsDauer“ „ErkennungsZeit“ und „Referenzzeit“ erneuert werden). Eine Meldungsaktualisierung wird dadurch ausgelöst, dass die „GültigkeitsDauer“ unter einen bestimmten (ebenfalls konfigurierbaren) Schwellenwert fällt. Ist das Ereignis nicht mehr gültig, lässt man entweder die eingestellte Zeit ablaufen oder es wird aktiv gelöscht (DENM-Löschung).
Inhalt:
Die Gültigkeitsdauer des Datenelements wird auf einen festen Wert eingestellt.
Wert:
Spezifisch für den jeweiligen C-ITS-Dienst.
|
|
TransmissionInterval [ÜbertragungsIntervall]
|
Nicht verwendet
|
Nicht verwendet
|
|
stationType [StationsTyp]
|
Obligatorisch
|
Inhalt:
Fester Wert, wird auf 15 gesetzt (straßenSeitige Einheit). Dies trifft auf ortsfeste und mobile straßenseitige C-ITS-Stationen zu. Bei Fahrzeugen des Straßenbetreibers kann der Wert 9 (Anhänger) oder 10 (SonderFahrzeuge) sein.
Wert:
Auf 9, 10 oder 15 eingestellt.
|
|
Situationscontainer
|
Obligatorisch
|
|
|
informationQuality [InformationsQualität]
|
Obligatorisch
|
Die Informationsqualität stellt die Wahrscheinlichkeit des Eintretens auf einer Skala von 0 bis 7 dar.
Werte: Risiko (2), wahrscheinlich (4), gewiss (6)
Wird (0) empfangen, sollte die Meldung zurückgewiesen werden; wird (7) empfangen, sollte sie als gewiss betrachtet werden.
|
|
eventType [EreignisTyp]
|
Obligatorisch
|
Kombination des Datenelements causeCode (UrsachenKennung) und des Datenelements subCauseCode (nachgeordneteUrsachenKennung). Spezifisch für den jeweiligen C-ITS-Dienst.
|
|
linkedCause [verknüpfteUrsache]
|
Optional
|
Möglichkeit der Verknüpfung der aktuellen Meldung mit einem Satz aus Ursachenkennung / nachgeordneterUrsachenKennung (ähnlich dem EreignisTyp), um weitere Informationen bereitstellen zu können.
|
|
eventHistory [EreignisHistorie]
|
Optional
|
Inhalt:
Dieses Profil nutzt dieses Datenelement auf optionaler Grundlage, wenn sich der Endpunkt der physischen Sperrung bestimmen lässt. Ist dies der Fall, beschreibt es den Beginn einer Sperrung bis zum Ende der Sperrung oder dem Beginn einer neuen Sperrung (weitere DENM). In diesem Zusammenhang werden die Werte der EreignisPunkte ohne entsprechende EreignisDeltaZeit übermittelt, weil die Punkte einen georäumlichen Umfang und kein Fahrprofil beschreiben.
Das Datenelement InformationsQualität in der EreignisHistorie wird auf den gleichen Wert gesetzt wie die vorstehend spezifizierte InformationsQualität der gesamten DENM.
Werden Kartenprojektionen verwendet, beziehen sich diese auf Punkte in der Mitte des Fahrstreifens oder der Fahrbahn.
Die maximale Abweichung zwischen der Realität und den Kartenprojektionen darf ein Viertel der Fahrbahnbreite nicht überschreiten.
|
|
Standort-Container
|
Optional
|
|
|
eventSpeed [EreignisGeschwindigkeit]
|
Optional
|
Dieses Datenfeld wird, sofern verfügbar, nur bei in Bewegung befindlichen Ereignissen bereitgestellt. Bei statischen Ereignissen wird es nicht bereitgestellt.
|
|
eventPositionHeading [Kurs der Ereignisposition]
|
Optional
|
Informationen über die Kursrichtung werden nur bei in Bewegung befindlichen Ereignissen mittels EreignisPositionsKurs übermittelt. Stationäre Ereignisse auf DENM-Basis verwenden dieses Datenfeld nicht.
|
|
traces [VerfolgungsSpuren]
|
Obligatorisch
|
Der erste Spurpunkt in der Meldung ist der der Ereignisposition am nächsten gelegene Punkt. Dieser Punkt befindet sich in der Mitte des Fahrstreifens oder der Fahrbahn stromaufwärts von der Ereignisposition, wobei die Krümmung der Straße berücksichtigt wird. Sie wird als Verschiebung oder Deltaposition um die Ereignisposition gekennzeichnet. Zusätzliche Spurpunkte werden als Verschiebungen oder Deltapositionen in Bezug auf ihre vorherigen Verfolgungsspurpunkte definiert. Die Verfolgungsspurpunkte werden in aufsteigender Reihenfolge aufgeführt und definieren folglich auch den Kurs des Ereignisses.
Es können bis zu sieben Verfolgungsspuren vorhanden sein.
Werden Kartenprojektionen verwendet, beziehen sich diese auf Punkte in der Mitte des Fahrstreifens oder der Fahrbahn.
Die maximale Abweichung zwischen der Realität und den Kartenprojektionen darf ein Viertel der Fahrbahnbreite nicht überschreiten.
|
|
roadType [Straßentyp]
|
Optional
|
Optional
|
|
Alacarte-Container
|
Optional
|
|
|
lanePosition [FahrstreifenPosition]
|
Optional
|
Spezifisch für den jeweiligen C-ITS-Dienst.
|
|
impactReduction [AufprallReduzierung]
|
Nicht verwendet
|
Nicht verwendet
|
|
externalTemperature [AußenTemperatur]
|
Nicht verwendet
|
Nicht verwendet
|
|
lightBarSirenInUse [LeuchtbalkenSireneInBetrieb]
|
Nicht verwendet
|
Nicht verwendet
|
Tabelle 4: Für Warnungen vor Straßenarbeiten spezifische DENM-Elemente
|
Bezeichnung
|
Einsatz
|
Verwendung
|
|
Alacarte-Container
|
Optional
|
|
|
lanePosition [FahrstreifenPosition]
|
Optional
|
optional
|
|
closedLanes [gesperrteFahrstreifen]
|
Optional
|
Die Fahrstreifen werden von der Innenkante der Straße aus gezählt; der Standstreifen wird nicht eingeschlossen.
Dieses Datenfeld besteht aus drivingLaneStatus [FahrspurStatus] und hardShoulderStatus [StandStreifenstatus].
|
|
speedLimit [GeschwindigkeitsBegrenzung]
|
Optional
|
optional
|
|
recommendedPath [empfohleneStrecle]
|
Optional
|
optional
|
|
startingPointSpeedLimit [Anfangspunkt GeschwindigkeitsBegrenzung]
|
Optional
|
optional
|
|
trafficFlowRule [VerkehrsFlussRegel]
|
Optional
|
optional
NachRechtsWechseln(2) oder nachLinksWechseln(3) werden im Allgemeinen in allen Szenarien für C-ITS-Dienste unterstützt.
|
|
referenceDenms [ReferenzDENM]
|
Optional
|
DENM mit Warnungen vor Straßenarbeiten, die der gleichen, Straßenarbeiten betreffenden Situation zuzuordnen sind, werden in der zentralen C-ITS-Station miteinander verknüpft, indem alle zusammengehörenden MaßnahmenIDs im Datenelement ReferenzDEMN jeder Meldung in einer Liste erfasst werden.
|
3.7.2.IVI-Dienst (Infrastruktur-zu-Fahrzeug-Information)
Der IVI-Dienst nutzt zur Verbreitung von IVIM [Meldungen der Infrastruktur an Fahrzeuge] die von den Protokolleinheiten der ITS-Vernetzungs- und Beförderungsebene bereitgestellten Dienste.
Eine IVIM unterstützt Verkehrszeichen mit Verboten und Geboten wie kontextbezogene Geschwindigkeiten und Warnungen vor Straßenarbeiten. IVIM übermitteln Informationen über physische Verkehrszeichen wie statischen oder veränderlichen Verkehrszeichen, virtuellen Verkehrszeichen oder Straßenarbeiten.
Der in einer C-ITS-Station eingerichtete (instanziierte) IVI-Dienst stellt entweder den Übertragungs- oder den Empfangsdienst bereit.
Der IVI-Dienst generiert vier Arten von IVIM (Infrastruktur-zu-Fahrzeug-Meldungen):
·Neu-IVIM,
·Aktualisierungs-IVIM,
·Löschungs-IVIM,
·Verneinungs-IVIM.
(159)Der IVIM-Kopfsatz entspricht der Spezifikation in [TS 102 894-2].
(160)Die Datenelemente der IVIM-Meldungsnutzlast werden in der [ISO/TS 19321] definiert.
(161)Datenelemente, Datenrahmen und Dienstparameter von IVIM werden der Tabelle 5 entsprechend festgesetzt.
Tabelle 5
|
Bezeichnung
|
Einsatz
|
Verwendung
|
|
IVI-Managementcontainer [Information der Infrastruktur an Fahrzeuge]
|
Obligatorisch
|
|
|
serviceProviderId [DiensteAnbieterID]
|
Obligatorisch
|
Die DiensteAnbieterID besteht aus den Datenelementen „countryCode“ (LänderCode) und „providerIdentifier“ (DiensteanbieterKennung).
Der LänderCode ist eine [ISO 3166-1] entsprechende Bitfolge. Für Österreich steht die Bitfolge beispielsweise für „AT“ (Code der Bitfolge: A (11000) und T (00001) 1100000001, gemäß [ISO 14 816]).
Zusammen mit der iviIdentificationNumber (iviIdentifizierungsNummer) bildet dies die eindeutige Kennung von Meldungen für die empfangende fahrzeugseitige C-ITS-Station.
|
|
iviIdentificationNumber [iviIdentifizierungsNummer]
|
Obligatorisch
|
Dieses Datenelement ist die vom Diensteanbieter zugewiesene Kennung für die IVI-Struktur (Information der Infrastruktur an Fahrzeuge). Diese Komponente dient als ID von Meldungen der einzelnen DiensteAnbieter und kann von anderen, damit zusammenhängenden Meldungen als Referenz verwendet werden.
|
|
timestamp [Zeitstempel]
|
Obligatorisch
|
Dieses Datenelement ist der Zeitstempel, der die Uhrzeit darstellt, zu der die IVI-Meldung generiert oder der Inhalt der Meldungen zuletzt geändert wurde.
|
|
validFrom [gültigAb]
|
Obligatorisch
|
Diese Komponente kann die Zeit des Beginns des Geltungszeitraums der Meldung enthalten. Ist die Zeit des Beginns nicht relevant oder dem System nicht bekannt, ist gültigAb nicht vorhanden oder gleich dem Zeitstempel.
|
|
validTo [gültigBis]
|
Obligatorisch
|
Dieses Datenelement ist immer zu verwenden, damit die Gültigkeit bestimmt werden kann. Bevor die Meldung abläuft, wird eine Aktualisierung gesendet.
Wert: wird von der Anwendung festgesetzt.
Der Grundwert für den Geltungszeitraum wird vom Straßenbetreiber festgelegt.
|
|
connectedIviStructures (1..8) [angechlosseneIviStrukturen]
|
Nicht verwendet
|
Nicht verwendet.
|
|
iviStatus
|
Obligatorisch
|
Diese Komponente enthält den Status der IVI-Struktur (Information der Infrastruktur an Fahrzeuge). Sie kann auf neu(0), Aktualisierung(1), Löschung(2) oder Verneinung(3) gesetzt werden. Sie wird für die Handhabung von Meldungen eingesetzt.
|
|
Container für geografischen Standort (geographical location container, GLC)
|
Obligatorisch
|
|
|
referencePosition [ReferenzPosition]
|
Obligatorisch
|
Dieses Datenelement wird als Referenzpunkt für alle Zonen im GLC verwendet.
Der Referenzpunkt für IVI ist die Mitte der Fahrbahn an einer Signalbrücke; er bildet den ersten Punkt der Zonenabgrenzungen für Relevanzzonen und Erkennungszonen.
Die Höhe über NN kann auf „nicht verfügbar“ gesetzt werden, wenn sie nicht bekannt ist. Wird die Höhe über NN bereitgestellt, handelt es sich um die Höhe über NN der Straße.
Wert: wird von der Anwendung festgesetzt.
|
|
referencePositionTime [ReferenzPositionsZeit]
|
Nicht verwendet
|
Nicht verwendet.
|
|
referencePositionHeading [ReferenzPositionsKurs]
|
Nicht verwendet
|
Nicht verwendet
|
|
referencePositionSpeed [ReferenzPositionGeschwindigkeit]
|
Nicht verwendet
|
Nicht verwendet.
|
|
GlcPart (GLC-Teil)
|
Obligatorisch
|
Teile (1..16). In jedem Container für geografische Standorte (GLC) können bis zu 16 Teile definiert werden. Der GLC enthält mindestens zwei Zonen: eine für die Relevanz und eine für die Erkennung.
Wert: wird von der Anwendung festgesetzt.
|
|
zoneId [ZonenID]
|
Obligatorisch
|
Für jede Meldung werden mindestens eine Erkennungszone und eine Relevanzzone bereitgestellt.
|
|
laneNumber [FahrstreifenNummer]
|
Optional
|
Obligatorisch, wenn in diesem Standortcontainer einzelne Fahrstreifen beschrieben werden. Ein Grundwert ist nicht vorhanden (keine Fahrstreifeninformation).
|
|
zoneExtension [ZonenErweiterung]
|
Nicht verwendet
|
Nicht verwendet.
|
|
zoneHeading [ZonenKurs]
|
Obligatorisch
|
Obligatorisch
|
|
Zone
|
Obligatorisch
|
Abgrenzung einer Zone unter Verwendung des Datenfeldes „Zone“, das entweder aus einem gewählten Datenfeld „Segment“, einem Datenfeld „polygonalLine“ [polygonaleLinie] oder einem Datenfeld „computedSegment“ [berechnetesSegment] besteht.
Die Option „Segment“ wird mit polygonaleLinie als Linie (konstruiert mit der DeltaPosition wie bei DENM-Verfolgungsspuren) und optional mit der FahrstreifenBreite (wird nur verwendet, wenn innerhalb der Zone auf einen einzelnen Fahrstreifen Bezug genommen wird) verwendet.
|
|
IVI-Anwendungscontainer (Information der Infrastruktur an Fahrzeuge)
|
Obligatorisch
|
|
|
detectionZoneIds [ErkennungsZonenIDs]
|
Obligatorisch
|
Verzeichnis der Kennung(en) der Abgrenzung(en) der Erkennungszone(n), unter Verwendung des Datenelements Zid (1..8)
|
|
its-Rrid
|
Nicht verwendet
|
Nicht verwendet.
|
|
relevanceZoneIds [RelevanzZonenIDs]
|
Obligatorisch
|
Verzeichnis der Kennung(en) der Abgrenzung(en) der Relevanzzone(n), auf die sich der IVI-Container bezieht, unter Verwendung des Datenelements Zid (1..8)
|
|
direction [Richtung]
|
Obligatorisch
|
Richtung, die bezüglich der (implizit) unter Verwendung des Datenelements „Richtung “ durch die Zone abgegrenzten Richtung relevant ist. Wird immer auf sameDirection(0) [gleiche Richtung] gesetzt.
|
|
driverAwarnessZoneIds [FahrerAufklärungsZonenIDs]
|
Nicht verwendet
|
Nicht verwendet.
|
|
minimumAwarenessTime [MindestAufklärungsZeit]
|
Nicht verwendet
|
Nicht verwendet.
|
|
applicableLanes (1..8) [geltendeFahrstreifen]
|
Optional
|
Verzeichnis der Kennungen des/der Fahrstreifen, auf die sich der IVS-Container (Verkehrszeichen im Fahrzeug) bezieht, unter Verwendung des Datenelements FahrstreifenPosition (1..8).
|
|
iviType [Typ der Information der Infrastruktur an Fahrzeuge]
|
Obligatorisch
|
Übermittelt den Typ der IVI (z. B. Meldung über unmittelbare Gefahr, behördliche Meldung, Verkehrsinformationsmeldung), um die Klassifizierung und Priorisierung von IVI am der empfangenden C-ITS-Station zu ermöglichen.
|
|
iviPurpose [iviZweck]
|
Nicht verwendet
|
Nicht verwendet.
|
|
laneStatus [FahrstreifenStatus]
|
Optional
|
Zeigt den Fahrstreifenstatus (z. B. offen, gesperrt, links einfädeln, rechts einfädeln) der geltendenFahrstreifen an.
|
|
completeVehicleCharacteristics [vollständigeFahrzeugMerkmale]
|
Optional
|
„vollständigeFahrzeugMerkmale“ (completeVehicleCharacteristics) enthält die Definition der Merkmale der Fahrzeuge, für die ein Anwendungscontainer gilt. Die Komponente „Strang“ (sofern vorhanden) enthält die Merkmale, die für den gesamten Kraftübertragungsstrang des Fahrzeugs gelten.
|
|
driverVehicleCharacteristics [FahrerFahrzeugMerkmale]
|
Nicht verwendet
|
Nicht verwendet.
|
|
layoutId
|
Nicht verwendet
|
Nicht verwendet.
|
|
preStoredLayoutId
|
Nicht verwendet
|
Nicht verwendet.
|
|
roadSignCodes [VerkehrsZeichenKennungen]
|
Obligatorisch
|
Enthält die Definition der Verkehrszeichenkennung. Erlaub verschiedene Optionen, die auf verschiedene Piktogrammkataloge verweisen.
Diese Komponente spezifiziert, welche Verkehrszeichen für eine Relevanzzone gelten. Die Kennungen für Verkehrszeichen sind vom Klassifizierungsschema abhängig, auf das Bezug genommen wird.
Der Verkehrszeichenkennung können zusätzliche, in den Optionen vorgesehene Attribute hinzugefügt werden.
Verzeichnis von 1..4 des RSCode [VerkehrszeichenKennung]
|
|
RSCode [VerkehrszeichenKennung]
|
Obligatorisch
|
Enthält die ID der Layoutkomponente und eine Kennung.
|
|
layoutComponentId [LayoutKomponentenID]
|
Nicht verwendet
|
Dieser Datenrahmen kann dazu eingesetzt werden, eine Verkehrszeichenkennung mit der Layoutkomponente des Layouts, auf das Bezug genommen wird, zu verbinden.
|
|
Code
|
Obligatorisch
|
Für das Kodieren von Verkehrszeichen (Signcoding) ist [ISO/TS 14 823] zu verwenden.
|
|
ISO 14823Code
|
Obligatorisch
|
Für das Kodieren von Verkehrszeichen (Signcoding) ist [ISO/TS 14 823] zu verwenden.
Dieser Datenrahmen schließt mehrere Datenfelder und Datenelemente ein.
Er beinhaltet den pictogramCode [PiktogrammKennung] (LänderCode, DienstKategorieKennung und PiktogrammKategorieKennung - countryCode, serviceCategorycode und pictogramCategoryCode).
Die Attribute SET (Abschnitt) und NOL (Verkehrsstreifennummer) werden nicht unterstützt, weil sie Informationen duplizieren, die bereits im Anwendungscontainer unterstützt werden.
|
|
extraText ((1..4),...)
|
Optional
|
Verzeichnis von Textzeilen, die mit der georderten Liste von Verkehrszeichenkennungen verbunden sind. Jedes Stück enthält einen Sprachcode sowie zusätzlichen Text von begrenzter Länge in der gewählten Sprache; hierzu wird das Datenfeld Text verwendet.
Anmerkung: Dieses Datenfeld kann gefahrlos überladen werden, um mehr Textzeilen aufnehmen zu können.
|
3.7.3.Der Dienst Fahrstreifentopologie (Road Lane Topology, RLT)
Der RLT-Dienst nutzt zur Verbreitung von RLT [Meldungen zur Fahrstreifentopologie] die von den Protokolleinheiten der ITS-Vernetzungs- und Beförderungsebene bereitgestellten Dienste.
Er beinhaltet die Fahrstreifentopologie für Fahrzeuge, Fahrräder, Parken, öffentlichen Verkehr und die Strecken für Fußgängerüberwege sowie, beispielsweise, die zulässigen Manöver in einem Kreuzungsbereich oder Straßenabschnitt. In künftigen Leistungserweiterungen wird die digitale Landkarte weitere topologische Beschreibungen wie Kreisverkehre einschließen.
(162)Die MAPEM-Kopfsätze entsprechen der Spezifikation in [ETSI TS 102 894-2].
(163)Datenelemente, Datenrahmen und Dienstparameter von MAPEM werden der Tabelle 6 entsprechend festgesetzt.
Tabelle 6: MAPEM-Datenelemente
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
mapData [KartenDaten]
|
DF
|
Obligatorisch
|
|
|
**
|
timeStamp [ZeitStempel]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
msgIssue Revision
|
DE
|
Obligatorisch
|
Obligatorisch und auf 0 gesetzt. Gemäß der Definition in [ISO TS 19091].
|
|
**
|
layerType [EbenenTyp]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
layerID [EbenenID]
|
DE
|
Optional
|
Optional. Gemäß der Definition in [ISO TS 19091].
|
|
**
|
Kreuzungen
(1..32)
|
DF
|
Obligatorisch
|
IntersectionGeometryList::= SEQUENCE (SIZE(1..32)) OF IntersectionGeometry (siehe Tabelle 6.1) [KreuzungsGeometrieListe = SEQUENZ (GRÖSSE(1..32)) VON KreuzungsGeometrie]
Obligatorisch für Verkehrsampelmanöver (TLM)/RLT C-ITS Dienste.
|
|
**
|
roadSegments [StraßenSegmente]
(1..32)
|
DF
|
Nicht verwendet
|
Nicht verwendet. Die Datenelemente werden nicht weiter profiliert.
|
|
**
|
dataParameters [DatenParameter]
|
DF
|
Optional
|
Optional.
|
|
***
|
processMethod [ProzessMethode]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
***
|
processAgency [ProzessAgentur]
|
DE
|
Optional
|
Optional.
|
|
***
|
lastCheckedDate [DatumLetzteKontrolle]
|
DE
|
Optional
|
Optional, als JJJJ-MM-TT
|
|
***
|
geoidUsed [VerwendeteGeoID]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
restriction List [EinschränkungsListe]
(1..32)
|
DF
|
Optional
|
RestrictionClassList::= SEQUENCE (SIZE(1..254)) OF RestrictionClassAssignment (siehe Tabelle 6.3) [EinschränkungsKlassenListe=SEQUENZ (GRÖSSE(1..254)) VON EinschränkungsKlassenZuweisung].
Optional.
|
|
**
|
regional
|
DE
|
Nicht verwendet
|
REGION.Reg-MapData.
Nicht verwendet.
|
Tabelle 6.1: KreuzungsGeometrieListe -> KreuzungsGeometmrie
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
intersectionGeometry [KreuzungsGeometrie]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „Kreuzungen“ verwendet wird.
|
|
**
|
name [Bezeichnung]
|
DE
|
Optional
|
Optional. Üblicherweise für Menschen lesbar und für Straßenbehörden erkennbar.
|
|
**
|
id [ID]
|
DF
|
Obligatorisch
|
(IntersectionReferenceID) [KreuzungsReferenzID]
Obligatorisch. Muss die gleiche ID wie in der SPATEM sein. Die Kombination aus Region und ID muss innerhalb eines Landes eindeutig sein.
|
|
***
|
region
|
DE
|
Optional
|
Optional.
|
|
***
|
id [ID]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
Revision
|
DE
|
Obligatorisch
|
Obligatorisch. Die Revisionsnummer muss jedes Mal, wenn sich die KartenDaten dieser Kreuzung ändern, um eins erhöht werden. Die Revisionsnummern von SPATEM und MAPEM müssen gleich sein, damit zu erkennen ist, dass die richtige überarbeitete MAPEM-Fassung verwendet wird. Gemäß der Definition in [ISO TS 19091].
|
|
**
|
refPoint [ReferenzPunkt]
|
DF
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
lat [quer]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
long [längs]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
Höhe
|
DE
|
Nicht verwendet
|
Nicht verwendet. Ersetzt durch regionale RegPosition3D.
|
|
***
|
regional
|
DF
|
Optional
|
REGION.Reg-Position3D.
Optional. Wenn angegeben, stellt sie den Wert der Höhe über NN bereit.
|
|
****
|
altitude [Höhe über NN]
|
DF
|
Obligatorisch
|
Obligatorisch. Besteht aus WertHöheüberNN und StatistischeSicherheitHöheüberNN
|
|
*****
|
altitudeValue [WertHöheüberNN]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
*****
|
altitudeConfidence [StatistischeSicherheitHöheüberNN]
|
DE
|
Optional
|
Obligatorisch.; wird auf (15) = nicht verfügbar gesetzt, wenn sie nicht zur Verfügung steht.
|
|
**
|
laneWidth [FahrstreifenBreite]
|
DE
|
Optional
|
Optional.
|
|
**
|
speedLimits [GeschwindigkeitsBegrenzungen]
(1..9)
|
DF
|
Optional
|
SpeedLimitList::= SEQUENCE (SIZE(1..9)) OF RegulatorySpeedLimit (siehe Tabelle 6.2) [GeschwindigkeitsBegrenzungsListe = SEQUENZ (GRÖSSE(1..9)) VON BehördlicheGeschwindigkeitsBegrenzung.
Optional.
|
|
**
|
laneSet [FahrstreifenSatz]
(1..255)
|
DF
|
Obligatorisch
|
LaneList::= SEQUENCE (SIZE(1..255)) OF GenericLane (siehe Tabelle 6.4) FahrstreifenListe = SEQUENZ (GRÖSSE(1..255)) VON GenerischerFahrstreifen.
Obligatorisch.
|
|
**
|
preemptPriorityData [vorbelegtePrioritätsDaten]
(1..32)
|
DF
|
Nicht verwendet
|
Nicht verwendet. Die Datenelemente werden nicht weiter profiliert.
|
|
**
|
Regional
|
DF
|
Nicht verwendet
|
REGION.Reg- IntersectionGeometry) [KreuzungsGeometrie]. Nicht verwendet.
|
Tabelle 6.2: GeschwindigkeitsBegrenzungsListe -> BehördlicheGeschwindigkeitsBegrenzung
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
behördliche GeschwindigkeitsBegrenzung (SpeedLimit )
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „GeschwindigkeitsBegrenzungen“ verwendet wird.
|
|
**
|
type [Typ]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
speed [Geschwindigkeit]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
Tabelle 6.3: EinschränkungsKlassenListe -> EinschränkungsKlassenZuweisung
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
restriction ClassAssignment [EinschränkungsKlassenZuweisung]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn eine EinschränkungsListe verwendet wird.
|
|
**
|
id [ID]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
Verwender
|
DF
|
Obligatorisch
|
RestrictionUserTypeList::= SEQUENCE (SIZE(1..16)) OF RestrictionUserType [ListeEinschränkungNutzerTyp = SEQUENZ (GRÖSSE (1..16)) VON EinschränkungNutzerTyp]
Obligatorisch.
|
|
***
|
restrictionUserType [EinschränkungNutzerTyp]
|
DF
|
Obligatorisch
|
|
|
****
|
basicType [BasisTyp]
|
DE
|
Optional
|
In Verwendung.
|
|
****
|
regional
(1..4)
|
DF
|
Optional
|
REGION.Reg-RestrictionUserType-addGrpC [Reg.-EinschränkungNutzerTyp-zufügenGruppeC]. Optional, zur Bereitstellung von Emissionsbeschränkungen.
|
|
*****
|
emission
|
DE
|
Optional
|
Optional.
|
Tabelle 6.4: FahrstreifenListe -> GenerischerFahrstreifen
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
genericLane [generischerFahrstreifen]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „FahrstreifenSatz“ verwendet wird.
|
|
**
|
laneID [FahrstreifenID]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
name [Bezeichnung]
|
DE
|
Optional
|
Optional.
|
|
**
|
ingressApproach [Einfahrt]
|
DE
|
Optional
|
Optional. Wenn sie verwendet werden, haben Ein- und Ausfahrten desselben Straßenzweigs die gleiche ZufahrtID.
|
|
**
|
egressApproach [Ausfahrt]
|
DE
|
Optional
|
Optional. Wenn sie verwendet werden, haben Ein- und Ausfahrten desselben Straßenzweigs die gleiche ZufahrtID.
|
|
**
|
laneAttributes [FahrstreifenAttribute]
|
DF
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
directional Use [richtungsgebundene Nutzung]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
sharedWith [geteiltMit]
|
DE
|
Obligatorisch
|
Obligatorisch.
Wobei die Bits wie folgt definiert sind: overlappingLaneDescriptionProvided (0) multipleLanesTreatedAsOneLane(1) [überschneidendeFahrstreifenBeschreibungVorgesehen(0) mehrere FahrstreifenAlsEinFahrstreifenBehandelt(1)]
-- im Profil nicht zugelassen, da alle Fahrstreifen beschrieben werden müssen.
otherNonMotorizedTrafficTypes(2) [andereNichtMotorisierteVerkehrsArten(2)]
-- z. B. von Pferden gezogen
individualMotorizedVehicleTraffic(3) [IndividualKraftVerkehr(3)]
-- Personenkraftwagen
busVehicleTraffic(4) [BusVerkehr(4)]
taxiVehicleTraffic(5) [TaxiVerkehr(5)]
pedestriansTraffic(6) [FußgängerVerkehr(6)]
cyclistVehicleTraffic(7) [FahrradVerkehr(7)]
trackedVehicleTraffic(8) pedestrianTraffic(9) [SchienenFahrzeugVerkehr(8) Fußgängerverkehr(9)]
-- stattdessen 6 benutzen (Fehler)
|
|
***
|
laneType [FahrstreifenTyp]
|
DF
|
Obligatorisch
|
Obligatorisch. In diesem Profil wird verwendet:
Fahrzeug
Fußgängerüberweg
FahrradSpur
SchienenFahrzeug
-- Beispiele für Fußgängerüberwege sind der Norm [ISO TS 19091] zu entnehmen.
|
|
****
|
Vehicle [Fahrzeug]
|
DE
|
Optional
|
Optional (Wahl).
|
|
****
|
crosswalk [Fußgängerüberweg]
|
DE
|
Optional
|
Optional (Wahl).
|
|
****
|
bikeLane [FahrradSpur]
|
DE
|
Optional
|
Optional (Wahl).
|
|
****
|
sidewalk [Gehsteig]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
median [Mittelstreifen]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
striping [Markierungsstreifen]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
trackedVehicle [SchienenFahrzeug]
|
DE
|
Optional
|
Optional (Wahl).
|
|
****
|
parking [Parkplätze]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
***
|
regional
|
DF
|
Nicht verwendet
|
Reg-laneAttributes [Reg-FahrstreifenAttribute]. Nicht verwendet.
|
|
**
|
maneuvers [Manöver]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
nodeList [KnotenpunktListe]
|
DF
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
nodes [Knotenpunkte]
(2..63)
|
DF
|
Obligatorisch
|
NodeSetXY::= SEQUENCE (SIZE(2..63)) OF NodeXY (siehe Tabelle 6.5) [KnotenpunktSatzXY = SEQUENZ (GRÖSSE(2..63)) VON KnotenpunktXY]
Obligatorisch, wenn „KnotenpunktListe“ verwendet wird.
Die empfohlene Nutzung für kurvige Fahrstreifen besteht darin, einen zusätzlichen Knotenpunkt hinzuzufügen, wenn die Mittellinie des generischen Fahrstreifens um mehr als 0,5 m von der tatsächlichen Mittellinie abweicht.
|
|
***
|
computed [berechnet]
|
DF
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
connectsTo [verbindetMit]
(1..16)
|
DF
|
Optional
|
ConnectsToList::= SEQUENCE (SIZE(1..16)) OF Connection (siehe Tabelle 6.6) [VerbindetMitListe = SEQUENZ (GRÖSSE (1..16)) VON Verbindung].
Optional. Ausfahrtstreifen, die nicht durch eine Verkehrsampel geregelt werden.
|
|
**
|
overlays [Überlagerungen]
|
DF
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
regional
|
DF
|
Nicht verwendet
|
REGION-Reg-GenericLane [GenerischerFahrstreifen]. Nicht verwendet (bis zur anstehenden Veröffentlichung von [ISO TS 19091]). Zur Bereitstellung von ConnectionTrajectory-addGrpC [VerbindungsProfil-zufügenGruppeC]. Relevant für das Nutzungsszenario sicheres Kreuzungsmanöver.
|
Tabelle 6.5: KnotenpunktSatzXY -> KnotenpunktXY
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
nodeXY [KnotenpunktXY]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „Knotenpunkte“ verwendet werden.
|
|
**
|
Delta
|
DF
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
node-XY1 [Knotenpunkt-XY1]
|
DF
|
Optional
|
Optional (Wahl).
Datenfeld setzt sich aus X und Y zusammen, beide obligatorisch.
|
|
***
|
node-XY2 [Knotenpunkt-XY2]
|
DF
|
Optional
|
Optional (Wahl).
Datenfeld setzt sich aus X und Y zusammen, beide obligatorisch.
|
|
***
|
node-XY3 [Knotenpunkt-XY3]
|
DF
|
Optional
|
Optional (Wahl).
Datenfeld setzt sich aus X und Y zusammen, beide obligatorisch.
|
|
***
|
node-XY4 [Knotenpunkt-XY4]
|
DF
|
Optional
|
Optional (Wahl).
Datenfeld setzt sich aus X und Y zusammen, beide obligatorisch.
|
|
***
|
node-XY5 [Knotenpunkt-XY5]
|
DF
|
Optional
|
Optional (Wahl).
Datenfeld setzt sich aus X und Y zusammen, beide obligatorisch.
|
|
***
|
node-XY6 [Knotenpunkt-XY6]
|
DF
|
Optional
|
Optional (Wahl).
Datenfeld setzt sich aus X und Y zusammen, beide obligatorisch.
|
|
***
|
node-LatLon [Knotenpunkt-QuerLein]
|
DF
|
Nicht verwendet
|
Wird nicht für Kreuzungen verwendet. Die Verwendung z.B. für Autobahnen ist akzeptabel.
|
|
***
|
regional
|
DF
|
Nicht verwendet
|
REGION.Reg-NodeOffsetPointXY [KnotenpunktVerschiebungPunktXY].
Nicht verwendet.
|
|
**
|
Attribute
|
DF
|
Optional
|
Dieses DE stellt optionale Attribute bereit, die benötigt werden. Dies schließt Änderungen an der aktuellen Fahrstreifenbreite und der Höhe ein. Alle Attribute werden in der Reihenfolge der Knotenpunkte (im Gegensatz zur Fahrtrichtung) übermittelt. Auch Angaben zu links/rechts in den Attributen müssen auf der Grundlage der Reihenfolge der Knotenpunkte interpretiert werden.
|
|
***
|
localNode [lokalerKnotenpunkt]
(1..8)
|
DF
|
Optional
|
NodeAttributeXYList::= [KnotenpunktAttributXYListe =]
SEQUENCE (SIZE(1..8)) OF [SEQUENZ (GRÖSSE (1..8)) VON]
NodeAttributeXY [KnotenpunktAttributXY]
Optional. Fallabhängig. „Haltelinie“ ist obligatorisch, wenn sie im Feld vorhanden ist.
|
|
****
|
nodeAttributeXY [KnotenpunktAttributXY]
|
DE
|
Obligatorisch
|
Obligatorisch wenn lokalerVerkehrsknoten verwendet wird.
|
|
***
|
disabled [deaktiviert]
(1..8)
|
DF
|
Optional
|
SegmentAttributeXYList::= [SegmentAttributXYListe =]
SEQUENCE (SIZE(1..8)) OF [SEQUENZ (GRÖSSE (1..8)) VON]
SegmentAttributeXY [SementAttributXY]
Optional. Fallabhängig.
|
|
****
|
SegmentAttributeXY [SementAttributXY]
|
DE
|
Obligatorisch
|
Obligatorisch, wenn „deaktiviert“ verwendet wird.
|
|
***
|
enabled [aktiviert]
(1..8)
|
DF
|
Optional
|
SegmentAttributeXYList::= [SegmentAttributXYListe =]
SEQUENCE (SIZE(1..8)) OF [SEQUENZ (GRÖSSE (1..8)) VON]
SegmentAttributeXY [SementAttributXY]
Optional. Fallabhängig.
|
|
****
|
SegmentAttributeXY [SementAttributXY]
|
DE
|
Obligatorisch
|
Obligatorisch, wenn „aktiviert“ verwendet wird.
|
|
***
|
data [Daten]
|
DF
|
Optional
|
Optional.
|
|
****
|
pathEndPointAngle [StreckenEndPunktWinkel]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
pathEndPointAngle [StreckenEndPunktWinkel]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
laneCrownPointCenter [FahrspurScheitelPunktMitte]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
laneCrownPointLeft [FahrspurScheitelPunktLinks]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
laneCrownPointRight [FahrspurScheitelPunktRechts]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
laneAngle [FahrspurWinkel]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
****
|
speedLimits (1..9) [GeschwindigkeitsBegrenzungen]
|
DE
|
Optional
|
SpeedLimitList::= SEQUENCE [GeschwindigkeitsBegrenzungsListe = SEQUENZ]
(SIZE(1..9)) OF [GRÖSSE 1..9) VON]
RegulatorySpeedLimit [BehördlicheGeschwindigkeitsBegrenzung]
(siehe Tabelle 6.2).
Optional (Wahl).
|
|
****
|
regional
|
DF
|
Nicht verwendet
|
REGION.Reg-
LaneDataAttribute [FahrspurDatenAttribut].
Nicht verwendet.
|
|
***
|
dWidth [Breite]
|
DE
|
Optional
|
Optional.
|
|
***
|
dElevation [Höhe]
|
DE
|
Optional
|
Optional.
|
|
***
|
regional
|
DF
|
Nicht verwendet
|
REGION.Reg-NodeAttributeSetXY [KnotenpunktAttributeSatzXY].
Nicht verwendet.
|
Tabelle 6.6: VerbindetMitListe -> Verbindung
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
Anschluss
|
DF
|
Optional
|
Obligatorisch, wenn „verbindetMit“ verwendet wird.
|
|
**
|
connectingLane [AnschlussFahrspur]
|
DF
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
lane [Fahrspur]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
***
|
maneuvers [Manöver]
|
DE
|
Optional
|
Optional.
|
|
**
|
remoteIntersection [entfernteKreuzung]
|
DF
|
Optional
|
Optional. Wird nur verwendet, wenn die Kreuzung, auf die Bezug genommen wird, Teil der gleichen MAPEM ist.
|
|
***
|
Region
|
DE
|
Optional
|
Optional.
|
|
***
|
Id
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
signalGroup [AmpelGruppe]
|
DE
|
Optional
|
Optional, weil eventuell nicht alle Verbindungen über miteinander zusammenhängende Ampelgruppen verfügen. Bei Verbindungen, die durch eine Verkehrsampel gesteuert werden, muss „Ampelgruppe“ jedoch eingestellt werden.
|
|
**
|
userClass [NutzerKlasse]
|
DE
|
Optional
|
Optional.
|
|
**
|
connectionID [VerbindungsID]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
3.7.4.TLM-Dienst
Der TLM-Dienst nutzt zur Verbreitung von TLM [Verkehrsampelmanöver] die von den Protokolleinheiten der ITS-Vernetzungs- und Beförderungsebene bereitgestellten Dienste.
Er schließt sicherheitstechnische Informationen ein, um Verkehrsteilnehmern (Fahrzeugen, Fußgängern usw.) Hilfestellung bei der Durchführung sicherer Manöver in einem Kreuzungsbereich zu leisten. Das Ziel besteht darin, kontrolliert in den „Konfliktbereich“ Kreuzung hineinzukommen und ihn ebenso wieder zu verlassen. Der TLM-Dienst stellt in Echtzeit Informationen über die Betriebszustände der Verkehrsampelsteuerung, den aktuellen Status der Ampel, die verbleibende Dauer des Status vor dem Wechsel in den nächsten Status und die zulässigen Manöver bereit; außerdem hilft er beim Überqueren der Straße.
(164)Die SPATEM-Kopfsätze müssen der Spezifikation in [TS 102 894-2] entsprechen.
(165)Datenelemente, Datenrahmen und Dienstparameter von SPATEM werden gemäß Tabelle 7 festgesetzt.
Tabelle 7: SPATEM-Datenelemente
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
Spat [Ampelphase und Timing]
|
DF
|
Obligatorisch
|
|
|
**
|
timeStamp [ZeitStempel]
|
DE
|
Optional
|
Nicht verwendet, aber optional aufrechterhalten.
|
|
**
|
name [Bezeichnung]
|
DE
|
Optional
|
Nicht verwendet, aber optional aufrechterhalten.
|
|
**
|
Intersections [Kreuzungen]
(1..32)
|
DF
|
Obligatorisch
|
IntersectionStateList::= SEQUENCE (SIZE(1..32)) OF IntersectionState (siehe Tabelle 7.1) [KreuzungsStatusListe = SEQUENZ (GRÖSSE(1..32)) VON KreuzungsStatus].
Obligatorisch
|
|
**
|
regional (1..4)
|
DF
|
Nicht verwendet
|
REGION.Reg-SPAT.
Nicht verwendet.
|
Tabelle 7.1: KreuzungsStatusListe -> KreuzungsStatus
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
intersectionState [KreuzungsStatus]
|
DF
|
Obligatorisch
|
|
|
**
|
name [Bezeichnung]
|
DE
|
Optional
|
Verwendet, aber optional aufrechterhalten.
Auf der Grundlage eines von der Straßenbehörde verwendeten Nummerierungsplans.
|
|
**
|
id [ID]
|
DF
|
Obligatorisch
|
(IntersectionReferenceID) [KreuzungsReferenzID]
Obligatorisch. Muss die gleiche ID wie in der MAPEM sein. Die Kombination aus Region und ID muss innerhalb eines Landes eindeutig sein.
|
|
***
|
region
|
DE
|
Optional
|
Optional.
|
|
***
|
id [ID]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
Revision
|
DE
|
Obligatorisch
|
Obligatorisch. Die Revisionsnummer muss jedes Mal, wenn sich die KartenDaten dieser Kreuzung ändern, um eins erhöht werden. Die Revisionsnummern von SPATEM und MAPEM müssen gleich sein, damit zu erkennen ist, dass die richtige überarbeitete MAPEM-Fassung verwendet wird. Gemäß der Definition in [ISO TS 19091].
|
|
**
|
Status
|
DE
|
Obligatorisch
|
Obligatorisch. Üblicherweise wird auf der Grundlage von EN 12675 Folgendes verwendet:
•manualControlIsEnabled(0) [manuelleSteuerungenAktiviert];
•fixedTimeOperation(5) [FestZeitBetrieb];
•trafficDependentOperation(6) [VerkehrsAbhängigerBetrieb];
•standbyOperation(7) [StandbyBetrieb];
•failureMode(8) [AusfallModus].
|
|
**
|
moy
|
DE
|
Obligatorisch
|
Obligatorisch. Wird auch zur Validierung der Referenzzeit der ZeitMarken verwendet.
|
|
**
|
timeStamp [ZeitStempel]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
enabledLanes [aktivierteFahrstreifen]
|
DF
|
Optional
|
Obligatorisch, wenn in einer Fahrstreifenbeschreibung das Bit „widerrufbarer Fahrstreifen“ verwendet wird. Andernfalls wird es nicht verwendet.
|
|
**
|
states [Stati]
(1..16)
|
DF
|
Obligatorisch
|
MovementList::= SEQUENCE (SIZE(1..255)) OF MovementState (siehe Tabelle 7.2) BewegungsListe = SEQUENZ (GRÖSSE(1..255)) VON BewegungsStatus.
Obligatorisch.
|
|
**
|
maneuverAssistList [ManöverAssistenzListe]
(1..16)
|
DF
|
Nicht verwendet
|
ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (siehe Tabelle 7.5) [ManöverAssistenzListe = SEQUENZ (GRÖSSE(1..16) VON VerbindungsManöverAssistenz].
Nicht verwendet, daher keine weitere Profilbeschreibung auf dieser Ebene.
|
|
**
|
Regional (1..4)
|
DF
|
Optional
|
REGION.Reg-IntersectionState [KreuzungsStatus].
Optional, zur Sicherstellung der Interoperabilität mit Systemen zur Priorisierung des öffentlichen Verkehrs.
|
Tabelle 7.2: BewegungsListe -> BewegungsStatus
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
movementState [BewegungsStatus]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „Stati“ verwendet wird.
|
|
**
|
movementName [BewegungsBezeichnung]
|
DE
|
Optional
|
Optional.
|
|
**
|
signalGroup [AmpelGruppe]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
state-time- speed [Status-Zeit-Geschwindigkeit]
|
DF
|
Obligatorisch
|
MovementEventList::= SEQUENCE (SIZE(1..16)) OF MovementEvent. [BewegungsEreignisListe = SEQUENZ (GRÖSSE(1..16)) VON BewegungsEreignis].
Obligatorisch (1-16).
(siehe Tabelle 7.3).
|
|
**
|
maneuverAssistList [ManöverAssistenzListe]
(1..16)
|
DF
|
Optional
|
ManeuverAssistList::= SEQUENCE (SIZE(1..16)) OF ConnectionManeuverAssist (siehe Tabelle 7.5) [ManöverAssistenzListe = SEQUENZ (GRÖSSE(1..16) VON VerbindungsManöverAssistenz].
Optional.
|
|
**
|
regional
(1..4)
|
DF
|
Nicht verwendet
|
REGION.Reg-MovementState [Bewegungsstatus].
Nicht verwendet.
|
Tabelle 7.3: BewegungsEreignisListe -> BewegungsEreignis
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
movementEvent [BewegungsEreignis]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „Status-Zeit-Geschwindigkeit“ verwendet wird.
|
|
**
|
eventState [EreignisStatus]
|
DE
|
Obligatorisch
|
Obligatorisch und wie folgt definiert:
(0)nicht verfügbar (unbekannt oder Fehler);
(1)dunkel (in der EU nicht verwendet);
(2)Anhalten-dann-Weiterfahren (z. B. rote Ampel, kombiniert mit Verkehrszeichen „grüner Pfeil“ für Abbiegebewegung);
(3)Anhalten-und-Stehenbleiben (z. B. rote Ampel);
(4)Vor-Bewegung (z. B. rot/gelb, wie es in einigen EU-Ländern vor dem grünen Signal verwendet wird);
(5)zulässige-Bewegung-Erlaubt (z. B. „volles grünes Licht“, mit möglicherweise kollidierendem Verkehr, insbesondere beim Abbiegen);
(6)geschützte-Bewegung-Erlaubt (z. B. Ampelanzeige mit grünem Pfeil ohne kollidierenden Fahrzeug- oder Fußgängerverkehr beim Durchqueren des Konfliktbereichs);
(7)zulässiges Räumen (z. B. „volles gelbes Licht“ der Ampel, auf Anhalten vorbereiten. Wird nach einen Ampelstatus „grün“ eingesetzt);
(8)geschütztes Räumen (z. B. Ampelanzeige mit „gelbem Pfeil“, auf Anhalten für eine bestimmte Richtung vorbereiten. Wird nach einen Ampelstatus „grüner Pfeil“ eingesetzt);
(9)Achtung-Kollidierender-Verkehr (z. B. blinkendes gelbes Ampellicht; vorsichtig weiterfahren, im Konfliktbereich der Kreuzung kann sich kollidierender Verkehr befinden).
|
|
**
|
timing
|
DF
|
Optional
|
Optional. Daten zum Timing können beispielsweise nicht verfügbar sein, wenn der „Status“ 0, 1 oder 9 ist.
Alle ZeitMarken werden als Verschiebung gegenüber der vollen Stunde UTC [koordinierte Weltzeit] definiert (siehe ISO TS 19091) und stehen nicht zur Funktionssicherheit, sondern zur Information mit dem AmpelTiming in Beziehung. Die wahrscheinlicheZeit mit statistischer Sicherheit oder die minEndZeit mit maxEndZeit sind beides Maße für die Wahrscheinlichkeit und können, vorbehaltlich ihrer Verfügbarkeit, miteinander austauschbar eingesetzt werden.
|
|
***
|
startTime [StartZeit]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
***
|
minEndTime [minEndZeit]
|
DE
|
Obligatorisch
|
Obligatorisch. Vorkonfigurierter oder berechneter Wert mit hoher Wahrscheinlichkeit, aber mitunter nicht verfügbar (36001). Bei fester Zeitsteuerung beispielsweise ist er mit der maxEndZeit identisch; dies zeigt eine hohe Wahrscheinlichkeit an.
|
|
***
|
maxEndTime [maxEndZeit]
|
DE
|
Obligatorisch
|
Obligatorisch. Vorkonfigurierter oder berechneter Wert mit hoher Wahrscheinlichkeit, aber mitunter nicht verfügbar (36001). Bei fester Zeitsteuerung beispielsweise ist er mit der minEndZeit identisch; dies zeigt eine hohe Wahrscheinlichkeit an.
|
|
***
|
likelyTime [wahrscheinlicheZeit]
|
DE
|
Optional
|
Optional.
|
|
***
|
confidence [statistische Sicherheit]
|
DE
|
Optional
|
Obligatorisch, wenn wahrscheinlicheZeit vorgesehen ist.
Die Definition von „statistischer Sicherheit“ in der Grundnorm ist nicht verwendbar. Stattdessen wird statistische Sicherheit durch die Standardabweichung (Sigma) der wahrscheinlichenZeit in Sekunden definiert. Der zwischen 0 und 15 liegende, von diesem Datenelement bereitgestellte Wert stellt 1 Sigma (gerundet) dar. 15 = unbekannt. Daher wird die Umrechnungstabelle mit Wahrscheinlichkeitswerten, wie sie in SAE J2735 bereitgestellt wird, nicht genutzt.
Nimmt man eine Normalverteilung und eine Standardabweichung von 3,6 Sekunden an, liegt die wahrscheinlicheZeit:
•innerhalb von 26 und 34 Sekunden (1 Sigma) mit 68,27 % Wahrscheinlichkeit;
•innerhalb von 22 und 38 Sekunden (2 Sigma) mit 95,44 % Wahrscheinlichkeit;
•innerhalb von 18 und 42 Sekunden (3 Sigma) mit 99,73 % Wahrscheinlichkeit.
|
|
***
|
nextTime [nächsteZeit]
|
DE
|
Optional
|
Optional.
|
|
**
|
speeds [Geschwindigkeiten]
(1..16)
|
DF
|
Optional
|
AdvisorySpeedList::= SEQUENCE (SIZE(1..16)) OF AdvisorySpeed (siehe Tabelle 7.4) [RichtgeschwindigkeitsListe = SEQUENZ (GRÖSSE(1..16)) VON Richtgeschwindigkeit].
Optional.
|
|
**
|
regional
(1..4)
|
DF
|
Optional
|
REGION.Reg-MovementEvent, Optional. [BewegungsEreignis].
|
Tabelle 7.4: RichtgeschwindigkeitsListe -> Richtgeschwindigkeit
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
advisorySpeed [Richtgeschwindigkeit]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „Geschwindigkeiten“ verwendet wird.
|
|
**
|
type [Typ]
|
DE
|
Obligatorisch
|
Obligatorisch.
Grüne Welle(1) = Geschwindigkeit für eine Sequenz koordinierter Kreuzungen (an jeder Kreuzung wiederholt).
ecoDrive(2) = Geschwindigkeit für die aktuelle Kreuzung.
transit(3) = auf einen bestimmten Fahrzeugtyp beschränkt.
|
|
**
|
speed [Geschwindigkeit]
|
DE
|
Optional
|
Optional.
|
|
**
|
confidence [statistische Sicherheit]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
distance [Entfernung]
|
DE
|
Optional
|
Optional.
Wird nicht für Grüne Welle (1) verwendet. In anderen Fällen wird die Entfernung in Vorwärtsrichtung ab der Haltelinie entlang des hinzukommenden Fahrstreifens (Einfahrt) spezifiziert.
|
|
**
|
class [Klasse]
|
DE
|
Optional
|
Optional.
|
|
**
|
regional
(1..4)
|
DF
|
Nicht verwendet
|
REGION.Reg-AdvisorySpeed [Richtgeschwindigkeit].
Nicht verwendet.
|
Tabelle 7.5: ManöverAssistenzListe -> VerbindungsManöverAssistenz
|
Ebene
|
Bezeichnung
|
Typ
|
Einsatz
|
Verwendung
|
|
*
|
connection ManeuverAssist [VerbindungsManöverAssistenz]
|
DF
|
Obligatorisch
|
Obligatorisch, wenn „ManöverAssistenzListe“ verwendet wird.
|
|
**
|
connectionID [VerbindungsID]
|
DE
|
Obligatorisch
|
Obligatorisch.
|
|
**
|
queueLength [SchlangenLänge]
|
DE
|
Optional
|
Optional.
|
|
**
|
availableStorageLength [verfügbareSpeicherLänge]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
waitOnStop [beiHaltwarten]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
pedBicycleDetect [FußgängerFahrradErkennung]
|
DE
|
Nicht verwendet
|
Nicht verwendet.
|
|
**
|
regional
(1..4)
|
DF
|
Nicht verwendet
|
REGION.Reg-ConnectionManeuverAssist [VerbindungsManöverAssistenz].
Nicht verwendet.
|
INHALTSVERZEICHNIS
1.Einleitung9
1.1.Überblick und Anwendungsbereich der Certificate Policy9
1.2.Begriffsbestimmungen und Abkürzungen11
1.3.PKI-Teilnehmer13
1.3.1.Einleitung13
1.3.2.Für die C-ITS Certificate Policy zuständige Stelle16
1.3.3.Trust List Manager17
1.3.4.Akkreditierter PKI-Prüfer17
1.3.5.C-ITS-Kontaktstelle (CPOC)17
1.3.6.Betriebliche Funktionen18
1.4.Verwendung von Zertifikaten18
1.4.1.Anwendbare Verwendungsbereiche18
1.4.2.Zuständigkeitsgrenzen19
1.5.Verwaltung der Certificate Policy19
1.5.1.Aktualisierung der CPS der in der ECTL aufgeführten CA19
1.5.2.Verfahren zur Genehmigung von CPS20
2.Verantwortlichkeiten für Veröffentlichung und Datenablage (Repository)20
2.1.Methoden für die Veröffentlichung von Informationen über Zertifikate20
2.2.Zeitpunkt oder Häufigkeit der Veröffentlichung21
2.3.Datenablagen21
2.4.Zugangskontrollen für Datenablagen (Repositories)21
2.5.Veröffentlichung von Informationen über Zertifikate22
2.5.1.Veröffentlichung von Informationen über das Zertifikat durch den TLM22
2.5.2.Veröffentlichung von Informationen über Zertifikate durch CA22
3.Identifizierung und Authentifizierung23
3.1.Namen23
3.1.1.Arten von Namen23
3.1.1.1.Namen für TLM, Root-CA, EA, AA23
3.1.1.2.Namen für Endteilnehmer23
3.1.1.3.Identifizierung der Zertifikate23
3.1.2.Notwendigkeit der Aussagekraft von Namen23
3.1.3.Anonymität und Pseudonymität von Endteilnehmern23
3.1.4.Regeln für die Auslegung verschiedener Namensformen23
3.1.5.Eindeutigkeit von Namen24
3.2.Erstmalige Validierung der Identität24
3.2.1.Methode zum Nachweis des Besitzes des privaten Schlüssels24
3.2.2.Authentifizierung der Organisationsidentität24
3.2.2.1.Authentifizierung der Organisationsidentität der Root-CA24
3.2.2.2.Authentifizierung der Identität der TLM-Organisation25
3.2.2.3.Authentifizierung der Identität von Sub-CA-Organisationen25
3.2.2.4.Authentifizierung der Abonnentenorganisation von Endteilnehmern26
3.2.3.Authentifizierung einzelner Teilnehmer26
3.2.3.1.Authentifizierung des einzelnen TLM/CA-Teilnehmers26
3.2.3.2.Authentifizierung der Abonnentenidentität von C-ITS-Stationen27
3.2.3.3.Authentifizierung der Identität von C-ITS-Stationen27
3.2.4.Nicht verifizierte Angaben zu Abonnenten27
3.2.5.Validierung der Zertifizierungsstelle27
3.2.5.1.Validierung von TLM, Root-CA, EA, AA27
3.2.5.2.Validierung der C-ITS-Stationsabonnenten28
3.2.5.3.Validierung von C-ITS-Stationen28
3.2.6.Kriterien für die Interoperabilität28
3.3.Identifizierung und Authentifizierung von Schlüsselerneuerungsanträgen (Re-Key)28
3.3.1.Identifizierung und Authentifizierung für routinemäßige Schlüsselerneuerungsanträge28
3.3.1.1.TLM-Zertifikate28
3.3.1.2.Root-CA-Zertifikate28
3.3.1.3.EA/AA-Zertifikatserneuerung oder Schlüsselerneuerung28
3.3.1.4.Berechtigungsnachweise von Endteilnehmern für das Enrollment (Anmeldung)29
3.3.1.5.Berechtigungstickets von Endteilnehmern29
3.3.2.Identifizierung und Authentifizierung bei Schlüsselerneuerungsanträgen nach Zertifikatssperrung29
3.3.2.1.CA-Zertifikate29
3.3.2.2.Berechtigungsnachweise von Endteilnehmern für das Enrollment (Anmeldung)29
3.3.2.3.Berechtigungsanträge von Endteilnehmern29
3.4.Identifizierung und Authentisierung für Sperrungsantrag29
3.4.1.Root-CA/EA/AA-Zertifikate29
3.4.2.Enrollment-Berechtigungsnachweise von C-ITS-Stationen30
3.4.3.Berechtigungstickets von C-ITS-Stationen30
4.Betriebliche Anforderungen im Lebenszyklus von Zertifikaten30
4.1.Zertifikatantrag30
4.1.1.Wer kann einen Zertifikatantrag einreichen?30
4.1.1.1.Root-CA30
4.1.1.2.TLM31
4.1.1.3.EA und AA31
4.1.1.4.C-ITS-Station31
4.1.2.Enrollment-Prozess und Verantwortlichkeiten31
4.1.2.1.Root-CA31
4.1.2.2.TLM32
4.1.2.3.EA und AA32
4.1.2.4.C-ITS-Station32
4.2.Bearbeitung von Zertifikatanträgen33
4.2.1.Durchführung von Identifikations- und Authentifizierungsaufgaben33
4.2.1.1.Identifizierung und Authentifizierung von Root-CA33
4.2.1.2.Identifizierung und Authentifizierung des TLM33
4.2.1.3.Identifizierung und Authentifizierung von EA und AA33
4.2.1.4.Identifizierung und Authentifizierung des EE-Abonnenten34
4.2.1.5.Berechtigungstickets34
4.2.2.Genehmigung oder Ablehnung von Zertifikatanträgen34
4.2.2.1.Genehmigung oder Ablehnung von Root-CA-Zertifikaten34
4.2.2.2.Genehmigung oder Ablehnung von TLM-Zertifikaten34
4.2.2.3.Genehmigung oder Ablehnung von EA- und AA-Zertifikaten34
4.2.2.4.Genehmigung oder Ablehnung von EC34
4.2.2.5.Genehmigung oder Ablehnung von AT35
4.2.3.Bearbeitungsdauer von Zertifikatanträgen35
4.2.3.1.Antrag auf Root-CA-Zertifikat35
4.2.3.2.Antrag auf TLM-Zertifikat35
4.2.3.3.Antrag auf EA- und AA-Zertifikate35
4.2.3.4.EC-Antrag35
4.2.3.5.AT-Antrag35
4.3.Zertifikatsausstellung35
4.3.1.Maßnahmen der Wurzelzertifizierungsstelle während der Ausstellung von Zertifikaten35
4.3.1.1.Ausstellung von Zertifikaten für die Root-CA35
4.3.1.2.Ausstellung von TLM Zertifikaten36
4.3.1.3.Ausstellung von EA- und AA-Zertifikaten36
4.3.1.4.Ausstellung von EC36
4.3.1.5.Ausstellung von AT36
4.3.2.Benachrichtigung des Abonnenten über die Ausstellung von Zertifikaten durch die Zertifizierungsstelle36
4.4.Annahme der Zertifikate37
4.4.1.Durchführung der Annahme von Zertifikaten37
4.4.1.1.Root-CA37
4.4.1.2.TLM37
4.4.1.3.EA und AA37
4.4.1.4.C-ITS-Station37
4.4.2.Veröffentlichung des Zertifikats37
4.4.3.Benachrichtigung über die Zertifikatsausstellung37
4.5.Verwendung des Schlüsselpaars und des Zertifikats37
4.5.1.Nutzung des privaten Schlüssels und des Zertifikats37
4.5.1.1.Nutzung privater Schlüssel und Zertifikate für TLM37
4.5.1.2.Nutzung privater Schlüssel und Zertifikate für Root-CA37
4.5.1.3.Nutzung privater Schlüssel und Zertifikats für EA und AA37
4.5.1.4.Nutzung privater Schlüssel und Zertifikate für Endteilnehmer38
4.5.2.Nutzung öffentlicher Schlüssel und Zertifikate durch Vertrauende Dritte38
4.6.Zertifikatserneuerung38
4.7.Schlüsselerneuerung von Zertifikaten (Re-Key)38
4.7.1.Umstände für eine Schlüsselerneuerung38
4.7.2.Wer darf eine Schlüsselerneuerung beantragen?38
4.7.2.1.Root-CA38
4.7.2.2.TLM38
4.7.2.3.EA und AA38
4.7.2.4.C-ITS-Station39
4.7.3.Schlüsselerneuerungsprozess39
4.7.3.1.TLM-Zertifikat39
4.7.3.2.Root-CA-Zertifikat39
4.7.3.3.EA- und AA-Zertifikate39
4.7.3.4.C-ITS-Stationszertifikate40
4.8.Änderung von Zertifikaten40
4.9.Sperrung und Suspendierung von Zertifikaten40
4.10.Statusauskunftsdienste von Zertifikaten40
4.10.1.Betriebseigenschaften40
4.10.2.Verfügbarkeit des Dienstes40
4.10.3.Optionale Funktionen40
4.11.Beendigung des Vertragsverhältnisses40
4.12.Schlüsselhinterlegung und Wiederherstellung40
4.12.1.Teilnehmer40
4.12.1.1.Welches Schlüsselpaar kann hinterlegt werden?40
4.12.1.2.Wer kann einen Wiederherstellungsantrag stellen?40
4.12.1.3.Wiederherstellungsprozess und Verantwortlichkeiten40
4.12.1.4.Identifizierung und Authentifizierung40
4.12.1.5.Genehmigung oder Ablehnung von Wiederherstellungsanträgen40
4.12.1.6.KEA und KRA bei der Wiederherstellung von Schlüsselpaaren41
4.12.1.7.Verfügbarkeit von KEA und KRA41
4.12.2.Sitzungsschlüsselkapselung und Richtlinien und Praktiken für die Wiederherstellung41
5.Einrichtungs-, Verwaltungs- und Betriebskontrollen41
5.1.Physische Kontrollen41
5.1.1.Standort und Bauweise41
5.1.1.1.Root-CA, CPOC, TLM41
5.1.1.2.EA/AA42
5.1.2.Physischer Zugang42
5.1.2.1.Root-CA, CPOC, TLM42
5.1.2.2.EA/AA43
5.1.3.Stromversorgung und Klimatisierung43
5.1.4.Gefährdungen durch Wasser43
5.1.5.Brandschutz44
5.1.6.Medienmanagement44
5.1.7.Abfallentsorgung44
5.1.8.Externe Sicherung44
5.1.8.1.Root-CA, CPOC und TLM44
5.1.8.2.EA/AA45
5.2.Verfahrenskontrollen45
5.2.1.Vertrauensfunktionen45
5.2.2.Anzahl der pro Aufgabe erforderlichen Personen45
5.2.3.Identifizierung und Authentifizierung der einzelnen Funktionen46
5.2.4.Funktionen, die eine Aufgabentrennung erfordern46
5.3.Personalkontrollen47
5.3.1.Anforderungen an Qualifikation, Erfahrung und Sicherheitsüberprüfung47
5.3.2.Verfahren zur Zuverlässigkeitsüberprüfung47
5.3.3.Schulungsanforderungen48
5.3.4.Nachschulungsintervalle und -anforderungen48
5.3.5.Häufigkeit und Abfolge der Arbeitsplatzrotation48
5.3.6.Sanktionen bei unbefugten Handlungen48
5.3.7.Anforderungen an unabhängige Auftragnehmer49
5.3.8.Dem Personal bereitgestellte Dokumentation49
5.4.Verfahren für die Protokollierung von Audits49
5.4.1.Von jeder CA aufzuzeichnende und zu meldende Ereignisarten49
5.4.2.Häufigkeit der Bearbeitung von Protokollen50
5.4.3.Aufbewahrungszeitraum für Audit-Protokolle50
5.4.4.Schutz der Audit-Protokolle51
5.4.5.Sicherungsverfahren für Audit-Protokolle51
5.4.6.Audit-Erfassungssystem (intern oder extern)51
5.4.7.Benachrichtigung des ereignisauslösenden Subjekts51
5.4.8.Schwachstellenbewertung51
5.5.Archivierung von Aufzeichnungen52
5.5.1.Art der archivierten Aufzeichnungen52
5.5.2.Aufbewahrungszeitraum für Archive53
5.5.3.Schutz von Archiven53
5.5.4.Systemarchiv und Speicherung53
5.5.5.Anforderungen an Zeitstempel von Aufzeichnungen54
5.5.6.Archiverfassungssystem (intern oder extern)54
5.5.7.Verfahren zur Beschaffung und Verifizierung von Archivinformationen54
5.6.Schlüsselwechsel für Elemente des C-ITS Trust Models54
5.6.1.TLM54
5.6.2.Root-CA54
5.6.3.EA/AA-Zertifikat54
5.6.4.Prüfer55
5.7.Kompromittierung und Datenwiederherstellung im Falle eines Systemabsturzes (Disaster Recovery)55
5.7.1.Umgang mit Störungen und Kompromittierungen55
5.7.2.Beschädigung von Rechnerressourcen, Software und/oder Daten56
5.7.3.Verfahren bei der Kompromittierung von privaten Schlüsseln56
5.7.4.Fähigkeiten zur Aufrechterhaltung des Geschäftsbetriebs nach einem Systemabsturz56
5.8.Beendigung und Übertragung57
5.8.1.TLM57
5.8.2.Root-CA57
5.8.3.EA/AA58
6.Technische Sicherheitskontrollen58
6.1.Generierung und Installation von Schlüsselpaaren58
6.1.1.TLM, Root-CA, EA, AA58
6.1.2.EE – mobile C-ITS-Station58
6.1.3.EE – ortsfeste C-ITS-Station59
6.1.4.Kryptografische Anforderungen59
6.1.4.1.Algorithmus und Schlüssellänge – Signaturalgorithmen59
6.1.4.2.Algorithmus und Schlüssellänge – Verschlüsselungsalgorithmen für Enrollment und Berechtigung60
6.1.4.3.Krypto-Agilität61
6.1.5.Sichere Speicherung privater Schlüssel61
6.1.5.1.Root-CA-, Sub-CA- und TLM-Ebene61
6.1.5.2.Endteilnehmer62
6.1.6.Backup von privaten Schlüsseln63
6.1.7.Vernichtung privater Schlüssel63
6.2.Aktivierungsdaten63
6.3.Computer-Sicherheitskontrollen63
6.4.Lebenslange technische Kontrollen63
6.5.Kontrollen der Netzsicherheit63
7.Zertifikatprofile, CRL und CTL63
7.1.Zertifikatprofil63
7.2.Gültigkeit von Zertifikaten64
7.2.1.Pseudonym-Zertifikate65
7.2.2.Berechtigungstickets für ortsfeste C-ITS-Stationen65
7.3.Sperrung von Zertifikaten65
7.3.1.Sperrung von CA-, EA- und AA-Zertifikaten65
7.3.2.Sperrung von Enrollment-Berechtigungsnachweisen66
7.3.3.Sperrung von Berechtigungsnachweisen66
7.4.Zertifikatssperrliste66
7.5.European Certificate Trust List (Liste vertrauenswürdiger europäischer Zertifikate)66
8.Compliance-Audits und andere Bewertungen66
8.1.Audit-Themen und Audit-Grundlage66
8.2.Häufigkeit der Audits67
8.3.Identität/Qualifikation des Prüfers67
8.4.Beziehung des Prüfers zur geprüften Stelle67
8.5.Aufgrund von Mängeln getroffene Maßnahmen68
8.6.Mitteilung der Ergebnisse68
9.Sonstige Bestimmungen68
9.1.Gebühren68
9.2.Finanzielle Verantwortlichkeiten69
9.3.Vertraulichkeit von Geschäftsinformationen69
9.4.Datenschutzplan69
10.Referenzdokumente69
ANHANG III
1.Einleitung
1.1.Überblick und Anwendungsbereich der Certificate Policy
In der vorliegenden Certificate Policy wird das europäische C-ITS Trust Model auf der Grundlage einer Public Key Infrastruktur (PKI) definiert, das in den Anwendungsbereich des Systems für das Management von Sicherheitsberechtigungsnachweisen von C-ITS-Diensten in der EU (EU C-ITS security credential management system, EU-CCMS) fällt. Festgelegt werden Anforderungen für das Management von Anträgen auf Public-Key-Zertifikate durch ausstellende Teilnehmer und deren Nutzung durch Endteilnehmer in Europa. Auf ihrer höchsten Ebene setzt sich eine PKI aus einer Reihe von Root-CA zusammen, die „aktiviert“ wurden, nachdem sie vom Trust List Manager (Manager der Liste vertrauenswürdiger Zertifikate, TLM) auf eine European Certificate Trust List (europäische Liste vertrauenswürdiger Zertifikate, ECTL) gesetzt wurden; diese Liste wird vom TLM der zentralen Teilnehmerstelle herausgegeben und veröffentlicht (siehe die Abschnitte 1.2 und 1.3).
Diese Certificate Policy ist für alle Teilnehmer verbindlich, die an dem vertrauenswürdigen C-ITS-System in Europa beteiligt sind. Sie hilft bei der Bewertung des Niveaus an Vertrauen, das Empfänger von durch ein Endteilnehmerzertifikat der PKI authentifizierten Nachrichten in die empfangenen Informationen setzen können. Um eine Bewertung der Vertrauenswürdigkeit der vom EU-CCMS zur Verfügung gestellten Zertifikate zu ermöglichen, legt die Certificate Policy verbindliche Anforderungen für den Betrieb des TLM der zentralen Teilnehmerstelle sowie für die Erstellung und Verwaltung der ECTL fest. Dementsprechend werden in diesem Dokument folgende Aspekte im Zusammenhang mit der ECTL behandelt:
·Identifizierung und Authentifizierung von Vollmachtgebern, die PKI-Funktionen für den TLM übernehmen, einschließlich der Erklärungen über die jeder Rolle zugewiesenen Rechte;
·Mindestanforderungen an die lokale Sicherheitspraxis für den TLM, einschließlich physischer, personeller und verfahrenstechnischer Kontrollen;
·Mindestanforderungen an die technische Sicherheitspraxis des TLM, einschließlich der Computersicherheit, der Netzsicherheit und der kryptografischen Module für die technischen Kontrollen;
·Mindestanforderungen für die betriebliche Praxis des TLM, einschließlich der Registrierung neuer Root-CA-Zertifikate, der vorübergehenden oder ständigen Abmeldung bestehender, eingeschlossener CA und der Veröffentlichung und Verbreitung von ECTL-Aktualisierungen;
·ein ECTL-Profil, einschließlich aller obligatorischen und optionalen Datenfelder der ECTL, der zu verwendenden kryptografischen Algorithmen, des genauen ECTL-Formats und der Empfehlungen für die Verarbeitung der ECTL;
·das Lebenszyklusmanagement von ECTL-Zertifikaten, einschließlich Verteilung, Aktivierung, Ablauf und Sperrung von ECTL-Zertifikaten;
·gegebenenfalls die Verwaltung von vertrauensbezogenen Sperrungen von Root-CA.
Da die Vertrauenswürdigkeit der ECTL nicht allein von der ECTL selbst abhängt, sondern weitgehend auch von den Root-CA und Sub-CA, aus denen sich die PKI zusammensetzt, werden in der vorliegenden Certificate Policy auch für alle teilnehmenden CA (Root-CA und Sub-CA) obligatorische Mindestanforderungen festgelegt. Es handelt sich um folgende Anforderungsgebiete:
·Identifizierung und Authentifizierung von Vollmachtgebern, die PKI-Funktionen für den TLM übernehmen (z. B. Sicherheitsbeauftragte, Datenschutzbeauftragte, Sicherheitsadministratoren, Verzeichnisadministratoren und Endnutzer), einschließlich einer Erklärung der Pflichten, Verantwortlichkeiten, Haftungen und Rechten, die mit den einzelnen Funktionen verbunden sind;
·Schlüsselmanagement einschließlich akzeptabler, obligatorischer Algorithmen für die Signatur von Zertifikaten, die Signatur von Daten und Gültigkeitszeiträume von Zertifikaten;
·Mindestanforderungen an lokale Sicherheitspraktiken, einschließlich physischer, personeller und verfahrenstechnischer Kontrollen;
·Mindestanforderungen an technische Sicherheitspraktiken wie Computersicherheit, Netzsicherheit und technische Kontrollen im Bereich der kryptografischen Module;
·Mindestanforderungen für die betriebliche Praxis der CA, EA, AA und Endteilnehmer, unter Einschluss von Aspekten der Registrierung, der Abmeldung (d. h. Streichung aus der Liste), Sperrung, Kompromittierung von Schlüsseln, Kündigung aus wichtigem Grund, Aktualisierung von Zertifikaten, Auditpraktiken und Nichtoffenlegung datenschutzbezogener Informationen;
·Zertifikat und CRL-Profil, unter Einschluss von Formaten, akzeptablen Algorithmen, obligatorischen und optionalen Datenfeldern sowie deren gültige Wertebereiche, sowie Angaben dazu, wie die Prüfer die Zertifikate bearbeiten sollen;
·regelmäßige Überwachung, Meldung, Warnung und Wiederherstellung der Aufgaben der Teilnehmer des C-ITS Trust Models, um auch im Fall von Fehlverhalten einen sicheren Betrieb zu gewährleisten.
Zusätzlich zu diesen Mindestanforderungen können die Stellen, die die Root-CA und Sub-CA betreiben, ihre eigenen, zusätzlichen Anforderungen beschließen und in den maßgeblichen Erklärungen zum Zertifizierungsbetrieb (CPS) darlegen, sofern diese nicht den in der Certificate Policy festgelegten Anforderungen widersprechen. Einzelheiten dazu, wie Erklärungen zum Zertifizierungsbetrieb geprüft und veröffentlicht werden, sind Abschnitt 1.5 zu entnehmen.
In der Certificate Policy werden auch die Zwecke genannt, zu denen die Root-CA, Sub-CA und deren herausgegebene Zertifikate eingesetzt werden können. Darin sind die Haftungen aufgeführt, die von folgenden Stellen übernommen werden:
·dem TLM;
·jeder Root-CA, deren Zertifikate in der ECTL aufgeführt sind;
·den SubCA der Root-CA (EA und AA);
·alle Mitglieder oder Organisationen, die für einen der Teilnehmer des C-ITS Trust Models verantwortlich sind oder diesen betreiben.
In der Certificate Policy sind auch verbindliche Verpflichtungen festgelegt, die für Folgendes gelten:
·den TLM;
·jeder Root-CA, deren Zertifikate in der ECTL aufgeführt sind;
·jede von einer Root-CA zertifizierte Sub-CA;
·alle Endteilnehmer;
·alle Mitgliedsorganisationen, die für einen der Teilnehmer des C-ITS Trust Models verantwortlich sind oder diesen betreiben.
Schließlich legt die Certificate Policy Anforderungen in Bezug auf die Dokumentation von Beschränkungen der Haftung und Verpflichtungen in der Erklärung zum Zertifizierungsbetrieb (CPS) jeder Root-CA fest, deren Zertifikate in der ECTL aufgeführt werden.
Die vorliegende Certificate Policy steht im Einklang mit dem von der Internet Engineering Task Force (IETF) angenommenen Rahmen für Zertifizierungsregeln und Zertifizierungsverfahren [3].
1.2.Begriffsbestimmungen und Abkürzungen
Es gelten die Begriffsbestimmungen in [2], [3] und [4].
|
AA
|
authorisation authority (Genehmigungsstelle)
|
|
AT
|
authorisation ticket (Berechtigungsticket)
|
|
CA
|
certification authority (Zertifizierungsstelle]
|
|
CP
|
Certificate Policy
|
|
CPA
|
C-ITS certificate policy authority (für die C-ITS Certificate Policy zuständige Stelle)
|
|
CPOC
|
C-ITS point of contact (C-ITS-Kontaktstelle)
|
|
CPS
|
certificate practice statement (Erklärung zum Zertifizierungsbetrieb)
|
|
CRL
|
certificate revocation list (Zertifikatssperrliste)
|
|
EA
|
enrolment authority (Enrollmentstelle)
|
|
EC
|
enrolment credential (Enrollment-Berechtigungsnachweis)
|
|
ECIES
|
elliptic curve integrated encryption scheme (Verschlüsselungsverfahren, dem elliptische Kurven zugrunde liegen)
|
|
EE
|
end-entity (Endteilnehmer (d.h. C-ITS-Station)
|
|
ECTL
|
European Certificate Trust List (Liste vertrauenswürdiger europäischer Zertifikate)
|
|
EU-CCMS
|
EU C-ITS security credential management system (EU-weites Managementsystem für Sicherheitsberechtigungsnachweise von C-ITS)
|
|
DSGVO
|
Datenschutz-Grundverordnung
|
|
HSM
|
Hardware-Sicherheitsmodul
|
|
PKI
|
Public-Key-Infrastruktur
|
|
RA
|
registration authority (Registrierungsstelle)
|
|
SubCA
|
EA und AA
|
|
TLM
|
Trust List Manager (Manager der Liste vertrauenswürdiger Zertifikate)
|
Glossar
|
Antragsteller
|
Die natürliche oder juristische Person, die ein Zertifikat (oder dessen Erneuerung) beantragt. Ist das Zertifikat einmal ausgestellt (Initialisierung), wird der Antragsteller als Abonnent bezeichnet.
Bei für Geräte ausgestellten Zertifikaten ist der Abonnent (Antragsteller) die Stelle, die über den Endteilnehmer, an den das Zertifikat ausgestellt wird, Kontrolle ausübt bzw. ihn betreibt, auch wenn der Endteilnehmer den eigentlichen Antrag auf das Zertifikat sendet.
|
|
authorisation authority (Genehmigungsstelle)
|
In diesem Dokument bezieht sich der Begriff „Genehmigungsstelle“ (AA) nicht nur auf die spezifische Funktion der AA, sondern auch auf die juristische und/oder operative Stelle, die sie verwaltet.
|
|
certification authority (Zertifizierungsstelle)
|
Die Wurzelzertifizierungsstelle, die Enrollmentstelle und die Genehmigungsstelle werden zusammen als Zertifizierungsstelle (CA) bezeichnet.
|
|
C-ITS-Trust Model
|
Für die Herstellung eines Vertrauensverhältnisses zwischen C-ITS-Stationen ist das C-ITS Trust Model verantwortlich. Es wird durch die Verwendung einer PKI umgesetzt, die sich aus Root-CA, CPOC, TLM, EA, AA und einem sicheren Netz zusammensetzt.
|
|
Krypto-Agilität
|
Die Fähigkeit der Teilnehmer am C-ITS Trust Modell, die Certificate Policy an sich wandelnde Umfelder oder neue künftige Anforderungen anzupassen, beispielsweise durch im Laufe der Zeit vorgenommene Änderungen der kryptografischen Algorithmen und der Schlüssellänge.
|
|
kryptografisches Modul
|
Ein sicheres, auf Hardware basierenden Element, in dem Schlüssel generiert und/oder gespeichert, Zufallszahlen generiert und Daten signiert oder verschlüsselt werden.
|
|
enrolment authority (Enrollmentstelle)
|
In diesem Dokument bezieht sich der Begriff „Enrollmentstelle“ (EA) nicht nur auf die spezifische Funktion der EA, sondern auch auf die juristische und/oder operative Einrichtung, die sie verwaltet.
|
|
PKI-Teilnehmer
|
Die Teilnehmer des C-ITS Trust Models, d. h. der TLM, die Root-CA, EA, AA und die C-ITS-Stationen.
|
|
Schlüsselerneuerung
|
|
|
Datenablage
|
Die Datenablage, die für die Speicherung der Zertifikate und der von den Teilnehmern des C-ITS Trust Models bereitgestellten Informationen über Zertifikate gemäß Definition in Abschnitt 2.3 genutzt wird.
|
|
Wurzelzertifizierungsstelle
|
In diesem Dokument bezieht sich der Begriff „Wurzelzertifizierungsstelle“(CA) nicht nur auf die spezifische Funktion der Zertifizierungsstelle, sondern auch auf die juristische und/oder operative Einrichtung, die sie verwaltet.
|
|
Subjekt
|
Die natürliche Person, das Gerät, das System, die Einheit oder die Rechtsperson, die bzw. das in einem Zertifikat als Subjekt genannt wird, d. h. entweder der Abonnent oder ein Gerät, das vom Abonnenten kontrolliert oder betrieben wird.
|
|
Abonnent
|
Eine natürliche oder juristische Person, der ein Zertifikat ausgestellt wird und die rechtlich an einen Abonnentenvertrag oder eine Vereinbarung über Nutzungsbedingungen gebunden ist.
|
|
Abonnentenvertrag
|
Ein Vertrag zwischen Wurzelzertifizierungsstelle und Antragsteller/Abonnent, in dem die Rechte und Verantwortlichkeiten der Vertragsparteien festgelegt werden.
|
1.3.PKI-Teilnehmer
1.3.1.Einleitung
Die PKI-Teilnehmer spielen in der durch die vorliegende Certificate Policy festgelegten PKI eine Rolle. Sofern dies nicht ausdrücklich untersagt ist, kann ein Teilnehmer gleichzeitig mehrere Funktionen übernehmen. Es kann ihm untersagt werden, bestimmte Funktionen gleichzeitig zu übernehmen, um Interessenkonflikte zu vermeiden oder eine Aufgabentrennung zu gewährleisten.
Im Rahmen eines Dienstleistungsvertrags können die Teilnehmer auch andere Teile ihrer Funktionen an andere Stellen übertragen. Wenn beispielsweise Angaben zum Sperrstatus mit Hilfe von CRL zur Verfügung gestellt werden, ist die Wurzelzertifizierungsstelle (CA) auch Herausgeberin der CRL, kann aber die Zuständigkeit für die Ausstellung der CRL an einen anderen Teilnehmer delegieren.
Bei PKI-Funktionen handelt es sich um:
·maßgebliche Funktionen, d. h. jede Funktion wird eindeutig instanziiert;
·betriebliche Funktionen, d. h. Funktionen, die bei einem oder mehreren Teilnehmern instanziiert werden können.
So kann eine Root-CA beispielsweise von einem gewerblichen Teilnehmer, einer gemeinsamen Interessengruppe, einer nationalen Organisation und/oder einer europäischen Organisation implementiert werden.
Abbildung 1 zeigt die Architektur des C-ITS Trust Models auf der Grundlage von [2]. Die Architektur wird an dieser Stelle kurz beschrieben, die Hauptelemente werden jedoch in den Abschnitten 1.3.2 bis 1.3.6 ausführlicher beschrieben.
Die CPA ernennt den TLM, der daher für alle PKI-Teilnehmer ein vertrauenswürdiger Teilnehmer ist. Die CPA genehmigt den Betrieb der Root-CA und bestätigt, dass der TLM der/den Root-CA vertrauen kann. Der TLM stellt die ECTL aus, die allen PKI-Teilnehmern Vertrauen in die genehmigten Root-CA vermittelt. Die Root-CA stellt der EA und AA Zertifikate aus und vermittelt so Vertrauen in deren Betrieb. Die EA stellt Enrollment-Zertifikate an die sendenden und weiterleitenden C-ITS-Stationen (als Endteilnehmern) aus und vermittelt so Vertrauen in deren Betrieb. Die AA stellt den C-ITS-Stationen auf der Grundlage des Vertrauens in die EA Berechtigungstickets (AT) aus.
Die empfangende und weiterleitende C-ITS-Station (als weiterleitende Partei) kann anderen C-ITS-Stationen vertrauen, weil die Berechtigungstickets (AT) von einer AA ausgestellt werden, der eine Root-CA vertraut, der wiederum TLM und CPA vertrauen.
Beachten Sie bitte, dass Abbildung 1 nur die Ebene der Root-CA im C-ITS Trust Model darstellt. Einzelheiten zu den unteren Ebenen werden in den nachfolgenden Abschnitten dieser Certificate Policy oder der Erklärung zum Zertifizierungsbetrieb (CPS) der spezifischen Root-CA aufgeführt.
Abbildung 2 vermittelt einen Überblick über die Informationsflüsse zwischen PKI-Teilnehmern. Die grünen Punkte zeigen Informationsflüsse, die eine Kommunikation von Maschine zu Maschine erfordern. Für die Informationsflüsse in Rot bestehen festgelegte Sicherheitsanforderungen.
Das C-ITS Trust Model basiert auf einer multiplen Root-CA-Architektur, bei der die Root-CA-Zertifikate regelmäßig (wie im Folgenden beschrieben) der zentralen Kontaktstelle (CPOC) durch ein sicheres, von der CPOC festgelegtes Protokoll (z. B. Link-Zertifikate) übertragen werden.
Eine Root-CA kann von einer staatlichen oder privaten Stelle betrieben werden. Die Architektur für das C-ITS Trust Model enthält mindestens eine Root-CA (die EU Root-CA mit der gleichen Ebene wie die anderen Root-CA). Die EU Root-CA wird von allen am C-ITS Trust Model beteiligten Stellen, die nicht ihre eigene Root-CA gründen wollen, delegiert. Die zentrale Kontaktstelle (CPOC) übermittelt die empfangenen Root-CA-Zertifikate an den TLM, der dafür zuständig ist, die Liste der Root-CA-Zertifikate zu erfassen und zu signieren und sie an die CPOC zurückzusenden, die sie dann für alle öffentlich zugänglich macht (siehe unten).
Die Vertrauensbeziehungen zwischen den Teilnehmern am C-ITS Trust Model werden in den folgenden Abbildungen, Tabellen und Abschnitten beschrieben.
Abbildung 1: Architektur des C-ITS Trust Models
Abbildung 2: Informationsflüsse im C-ITS Trust Model
|
ID, Ablauf
|
Von
|
Zu
|
Inhalt
|
Referenz
|
|
(1).
|
CPA
|
TLM
|
Genehmigung des Root-CA-Antrags
|
8
|
|
(2).
|
CPA
|
TLM
|
Informationen über die Sperrung der Root-CA
|
8.5
|
|
(3).
|
CPA
|
Root-CA
|
Aktualisierungen der Certificate Policy
|
1.5
|
|
(4).
|
CPA
|
Root-CA
|
Genehmigung/Ablehnung des Antragsformulars der Root-CA oder des CPS-Änderungsantrags oder des Auditverfahrens
|
8.5, 8.6
|
|
(5).
|
TLM
|
CPA
|
Mitteilung einer ECTL-Änderung
|
4, 5.8.1
|
|
(6).
|
TLM
|
CPOC
|
TLM-Zertifikat
|
4.4.2
|
|
(7).
|
TLM
|
CPOC
|
ECTL
|
4.4.2
|
|
(8).
|
CPOC
|
TLM
|
Angaben zum Root-CA-Zertifikat
|
4.3.1.1
|
|
(9).
|
CPOC
|
TLM
|
Sperrung des Root-CA-Zertifikats
|
7.3
|
|
(10).
|
CPOC
|
alle Endteilnehmer
|
TLM-Zertifikat
|
4.4.2
|
|
(11).
|
Root-CA
|
CPOC
|
Angaben zum Root-CA-Zertifikat
|
4.3.1.1
|
|
(12).
|
Root-CA
|
CPOC
|
Sperrung des Root-CA-Zertifikats
|
7.3
|
|
(13).
|
Root-CA
|
Prüfer
|
Prüfungsanordnung
|
8
|
|
(14).
|
Root-CA
|
CPA
|
Antragsformular für die Root-CA – Erstantrag
|
4.1.2.1
|
|
(15).
|
Root-CA
|
CPA
|
Antragsformular für Root-CA – CPS-Änderungen
|
1.5.1
|
|
(16).
|
Root-CA
|
CPA
|
Antragsformular für Root-CA – Auditbericht
|
8.6
|
|
(17).
|
Root-CA
|
CPA
|
Root-CA Störungsmeldungen, einschließlich Sperrung einer Sub-CA (EA, AA)
|
Anhang III, 7.3.1
|
|
(18).
|
Root-CA
|
EA
|
Antwort, EA-Zertifikat
|
4.2.2.3
|
|
(19).
|
Root-CA
|
AA
|
Antwort, AA-Zertifikat
|
4.2.2.3
|
|
(20).
|
Root-CA
|
Alle
|
EA/AA Zertifikat, CRL
|
4.4.2
|
|
(21).
|
EA
|
Root-CA
|
Antrag auf EA-Zertifikat
|
4.2.2.3
|
|
(22).
|
EA
|
C-ITS-Station
|
Antwort, Enrollment-Berechtigungsnachweis
|
4.3.1.4
|
|
(23).
|
EA
|
AA
|
Antwort, Genehmigung
|
4.2.2.5
|
|
(24).
|
AA
|
Root-CA
|
Antrag auf AA-Zertifikat
|
4.2.2.3
|
|
(25).
|
AA
|
EA
|
Antrag auf Genehmigung
|
4.2.2.5
|
|
(26).
|
AA
|
C-ITS-Station
|
Antwort, Berechtigungsticket
|
4.3.1.5
|
|
(27).
|
EA
|
Root-CA
|
Einreichung des Antrags
|
4.1.2.3
|
|
(28).
|
AA
|
Root-CA
|
Einreichung des Antrags
|
4.1.2.3
|
|
(29).
|
Root-CA
|
EA
|
Antwort
|
4.12 und 4.2.1
|
|
(30).
|
Root-CA
|
AA
|
Antwort
|
4.12 und 4.2.1
|
|
(31).
|
C-ITS-Station
|
EA
|
Antrag auf Enrollment-Berechtigungsnachweis
|
4.2.2.4
|
|
(32).
|
C-ITS-Station
|
AA
|
Antrag auf Berechtigungsticket
|
4.2.2.5
|
|
(33).
|
Hersteller/Betreiber
|
EA
|
Registrierung
|
4.2.1.4
|
|
(34).
|
Hersteller / Betreiber
|
EA
|
Deaktivierung
|
7.3
|
|
(35).
|
EA
|
Hersteller / Betreiber
|
Antwort
|
4.2.1.4
|
|
(36).
|
Prüfer
|
Root-CA
|
Bericht
|
8.1
|
|
(37).
|
alle
|
CPA
|
Anträge auf Änderungen der CP
|
1.5
|
|
(38).
|
TLM
|
CPA
|
Antragsformular
|
4.1.2.2
|
|
(39).
|
CPA
|
TLM
|
Annahme/Ablehnung
|
4.1.2.2
|
|
(40).
|
TLM
|
CPA
|
Auditbericht
|
4.1.2.2
|
Tabelle 1:
Ausführliche Beschreibung der Informationsflüsse im C-ITS Trust Model
1.3.2.Für die C-ITS Certificate Policy zuständige Stelle
(1)Die für die C-ITS Certificate Policy zuständige Stelle (CPA) setzt sich aus Vertretern öffentlicher und privater Interessenträger (z. B. Mitgliedstaaten, Fahrzeughersteller usw.) zusammen, die am C-ITS Trust Model beteiligt sind. Die Stelle ist für zwei nachgeordnete Funktionen zuständig:
(1)Verwaltung der Certificate Policy, einschließlich:
·Genehmigung der vorliegenden Certificate Policy und künftiger Anträge auf Änderungen der Certificate Policy;
·Entscheidung über die Überprüfung von Änderungsanträgen und Empfehlungen, die von anderen PKI-Teilnehmern oder Organisationen eingereicht wurden;
·Entscheidung über die Freigabe neuer Fassungen der Certificate Policy;
(2)PKI-Bevollmächtigungsmanagement, einschließlich:
·Festlegung, Entscheidung und Veröffentlichung von Genehmigungen für Erklärungen zum Zertifizierungsbetrieb (CPS) und CA-Auditverfahren (im Folgenden zusammen als „CA-Genehmigungsverfahren“ bezeichnet);
·Ermächtigung der CPOC, regelmäßig tätig zu werden und darüber Bericht zu erstatten;
·Ermächtigung des TLM, regelmäßig tätig zu werden und Bericht zu erstatten;
·Genehmigung der CPS von Root-CA, wenn sie mit der gemeinsamen, gültigen Certificate Policy (CP) in Einklang stehen;
·Prüfung der Auditberichte des akkreditierten PKI-Prüfers für alle Root-CA;
·Benachrichtigung des TLM über die Liste genehmigter oder nicht genehmigter Root-CA und der zugehörigen Zertifikate auf der Grundlage eingegangener Genehmigungsberichte der Root-CA und regelmäßiger betrieblicher Berichte.
(2)Der Bevollmächtigte der CPA ist für die Authentifizierung des Bevollmächtigen des TLM und die Genehmigung des Antragsformulars für den TLM-Enrollment-Prozess zuständig. Die CPA ist dafür zuständig, das TLM zu bevollmächtigen, den Angaben in diesem Abschnitt entsprechend zu handeln.
1.3.3.Trust List Manager
(3)Der TLM ist eine von der CPA benannte einzige Stelle.
(4)Der TLM ist zuständig für:
·den Betrieb der ECTL im Einklang mit der gemeinsamen, gültigen Certificate Policy und die regelmäßige Übermittlung von Tätigkeitsberichten an die für die Certificate Policy zuständige Stelle (CPA), damit der Betrieb des C-ITS Trust Models insgesamt sicher verläuft;
·Empfang der CA-Zertifikate von der CPOC;
·Ein- oder Ausschluss von Root-CA-Zertifikaten in der ECTL nach entsprechender Benachrichtigung durch die CPA;
·Signieren der ECTL;
·die regelmäßige und rechtzeitige Übermittlung der ECTL an die CPOC.
1.3.4.Akkreditierter PKI-Prüfer
(5)Der akkreditierte PKI-Prüfer ist zuständig für:
·die Durchführung oder Organisation von Audits von Root-CA, TLM und Sub-CA;
·Weitergabe des Auditberichts (über einen erstmaligen oder regelmäßigen Audit) an die CPA im Einklang mit den Anforderungen in Abschnitt 8. Der Auditbericht muss Empfehlungen des akkreditierten PKI-Prüfers enthalten;
·Benachrichtigung der die Root-CA verwaltenden Stelle über die erfolgreiche oder nicht erfolgreiche Durchführung eines erstmaligen oder regelmäßigen Audits der Sub-CA;
·Bewertung der Konformität der Erklärungen zum Zertifizierungsbetrieb (CPS) mit der vorliegenden Certificate Policy.
1.3.5.C-ITS-Kontaktstelle (CPOC)
(6)Die CPOC ist eine von der CPA ernannte einzige Stelle. Der Bevollmächtigte der CPA ist für die Authentifizierung des Bevollmächtigten der CPOC und die Genehmigung des Antragsformulars für den CPOC-Enrollment-Prozess zuständig. Die CPA ist dafür zuständig, die CPOC zu bevollmächtigen, den Angaben in diesem Abschnitt entsprechend zu handeln.
(7)Die CPOC ist zuständig für:
·Aufbau eines sicheren Kommunikationsaustausches zwischen allen Teilnehmern des C-ITS Trust Models auf effiziente, schnelle Art und Weise und die Leistung von Beiträgen hierzu;
·Überprüfung von Änderungsanträgen und Empfehlungen, die von anderen Teilnehmern des Trust Models (z. B. Root-CA) eingereicht wurden;
·Übermittlung von Root-CA-Zertifikaten an das TLM;
·Veröffentlichung des gemeinsamen Vertrauensankers (aktueller öffentlicher Schlüssel und Link-Zertifikat des TLM);
·Veröffentlichung der ECTL.
Die vollständigen Angaben zur ECTL sind in Abschnitt 7 zu finden.
1.3.6.Betriebliche Funktionen
(8)Die folgenden, in [2] definierten Stellen üben gemäß Festlegung in RFC 3647 eine betriebliche Funktion aus:
|
Funktionselement
|
Funktion der PKI ([3] und [4])
|
Funktion im Einzelnen ([2])
|
|
Wurzelzertifizierungsstelle
|
CA/RA (Registrierungsstelle)
|
Übermittelt EA und AA den Nachweis, dass sie EC oder AT ausstellen darf
|
|
Enrollmentstelle
|
Abonnent bei der Root-CA/Subjekt des EA-Zertifikats
CA/RA
|
Authentifiziert eine C-ITS-Station und gewährt ihr Zugang zur ITS-Kommunikation
|
|
Genehmigungsstelle
|
Abonnent bei der Root-CA/Subjekt des AA-Zertifikats
CA/RA
|
Übermittelt einer C-ITS-Station verlässliche Nachweise dafür, dass sie bestimmte ITS-Dienste nutzen darf
|
|
Sendende C-ITS-Station
|
Subjekt des Endteilnehmer (EE)-Zertifikats (EC)
|
Erwirbt von der EA Zugangsrechte zu ITS-Kommunikationen
Erwirbt von der AA Rechte, ITS-Dienste aufzurufen
Sendet Meldungen in Einzeletappen und weitergeleitete Funkmeldungen
|
|
Weiterleitende (Weiterleitung) C-ITS-Station
|
Weiterleitende Partei/ Subjekt des EE-Zertifikats
|
Empfängt Funkmeldungen von der sendenden C-ITS-Station und leitet sie erforderlichenfalls an die empfangende C-ITS-Station weiter
|
|
empfangende C-ITS-Station
|
weiterleitende Partei
|
Empfängt Funkmeldungen von einer sendenden oder weiterleitenden C-ITS-Station
|
|
Hersteller
|
Abonnent an die EA
|
Installiert während der Herstellung die erforderlichen Informationen für das Sicherheitsmanagement in der C-ITS-Station
|
|
Betreiber
|
Abonnent bei EA/AA
|
Installiert und aktualisiert während des Betriebs die erforderlichen Informationen für das Sicherheitsmanagement in der C-ITS-Station
|
Tabelle 2: Betriebliche Funktionen
Anmerkung: Im Einklang mit [4] werden in der vorliegenden Certification Policy unterschiedliche Begriffe für den „Abonnenten“, der mit der CA einen Vertrag über die Ausstellung von Zertifikaten schließt, und das „Subjekt“, auf das sich das Zertifikat bezieht, verwendet. Abonnenten sind stets Teilnehmer, die eine vertragliche Beziehung mit einer CA haben, Subjekte sind Teilnehmer, für die das Zertifikat gilt. EA/AA sind Abonnenten und Subjekte der Root-CA und können EA/AA-Zertifikate anfordern. C-ITS-Stationen sind Subjekte und können Endteilnehmer-Zertifikate anfordern.
(9)Registrierungsstellen:
Die EA hat die Aufgabe, die Funktion einer Registrierungsstelle für Endteilnehmer zu übernehmen. Nur authentifizierte und berechtigte Abonnenten können neue Endteilnehmer (C-ITS-Stationen) in einer Enrollment-Stelle (EA) registrieren lassen. Die maßgeblichen Root-CA haben die Funktion von Registrierungsstellen für EA und A zu erfüllen.
1.4.Verwendung von Zertifikaten
1.4.1.Anwendbare Verwendungsbereiche
(10)Im Rahmen der vorliegenden Certification Policy ausgestellte Zertifikate sind für die Validierung digitaler Signaturen im Kontext der kooperativen ITS-Kommunikation vorgesehen, wobei die Referenzarchitektur von [2] einzuhalten ist.
(11)In den Zertifikatprofilen in [5] wird die Verwendung von Zertifikaten für TLM, Root-CA, EA, AA und Endteilnehmer bestimmt.
1.4.2.Zuständigkeitsgrenzen
(12)Zertifikate sind für folgende Verwendungszwecke weder bestimmt noch zulässig:
·Umstände, die geltendes Recht, Verordnungen (z. B. die DSGVO), Erlässe oder behördliche Anordnungen verletzen, gegen sie verstoßen oder ihnen zuwiderlaufen;
·Umstände, die gegen die Rechte Dritter verstoßen, ihnen zuwiderlaufen oder sie verletzen;
·Verstoß gegen die vorliegende Certificate Policy oder den maßgeblichen Abonnentenvertrag;
·Umstände, unter denen ihre Verwendung unmittelbar zu Todesfällen, Körperverletzungen oder schweren Umweltschäden führen könnte (z. B. Ausfall kerntechnischer Anlagen, der Navigation oder Kommunikation von Flugzeugen oder von Waffenkontrollsystemen);
·Umstände, die dem übergeordneten Ziel einer höheren Straßenverkehrssicherheit und eines effizienteren Straßenverkehrs in Europa zuwiderlaufen.
1.5.Verwaltung der Certificate Policy
1.5.1.Aktualisierung der CPS der in der ECTL aufgeführten CA
(13)Jede in der ECTL aufgeführte Root-CA veröffentlicht ihre eigene Erklärung zum Zertifizierungsbetrieb (CPS), die mit dieser Certificate Policy konform sein muss. Eine Root-CA kann zusätzliche Anforderungen hinzufügen, muss jedoch sicherstellen, dass jederzeit sämtliche Anforderungen dieser Certificate Policy erfüllt werden.
(14)Jede in der ECTL aufgeführte CA führt ein geeignetes Änderungsverfahren für ihr CPS-Dokument ein. Die wichtigsten Eigenschaften des Änderungsverfahrens werden im öffentlichen Teil der CPS dokumentiert.
(15)Mit dem Änderungsverfahren wird sichergestellt, dass alle Änderungen an der vorliegenden Certificate Policy (CP) sorgfältig analysiert werden; sofern dies zur Einhaltung der CP in der geänderten Form erforderlich ist, wird die CPS innerhalb des im Umsetzungsschritt des Änderungsverfahrens für die CP festgelegten Zeitrahmens aktualisiert. Das Änderungsverfahren beinhaltet insbesondere Dringlichkeitsverfahren für Änderungen, mit denen eine fristgerechte Umsetzung sicherheitsrelevanter Änderungen an der Certificate Policy (CP) sichergestellt wird.
(16)Das Änderungsverfahren umfasst geeignete Maßnahmen zur Verifizierung der Konformität mit der Certificate Policy aller Änderungen an der Erklärung zum Zertifizierungsbetrieb (CPS). Alle Änderungen an der CPS werden eindeutig dokumentiert. Bevor eine neue Fassung einer CPS umgesetzt wird, muss deren Konformität mit der Certificate Policy von einem akkreditierten PKI-Prüfer bestätigt werden.
(17)Die Root-CA teilt der CPA jede Änderung an der CPS mit mindestens folgenden Angaben mit:
·einer genaue Beschreibung der Änderung;
·der Gründe für die Änderung;
·eine Bericht des akkreditierten PKI-Prüfers, in dem die Konformität mit der CP bestätigt wird;
·Kontaktangaben der für die CPS zuständigen Person;
·geplanter Zeitplan für die Umsetzung.
1.5.2.Verfahren zur Genehmigung von CPS
(18)Vor Beginn des Betriebs legt eine künftige Root-CA einem akkreditierten PKI-Prüfer ihre CPS im Rahmen eines Auftrags zur Konformitätsprüfung (Ablauf 13) sowie der CPA zur Genehmigung (Ablauf 15) vor.
(19)Eine Root-CA legt Änderungen an ihrer CPS einem akkreditierten PKI-Prüfer im Rahmen eines Auftrags zur Konformitätsprüfung (Ablauf 13) sowie der CPA zur Genehmigung (Ablauf 15) vor.
(20)Eine EA/AA legt ihre Erklärung zum Zertifizierungsbetrieb (CPS) oder Änderungen an ihrer CPS der Root-CA vor. Die Root-CA kann bei der für die Genehmigung der EA/AA gemäß Definition in den Abschnitten 4.1.2 und 8 zuständigen nationalen Instanz oder privatrechtlichen juristischen Person eine Konformitätsbescheinigung anfordern.
(21)Der akkreditierte PKI-Prüfer bewertet die CPS gemäß Abschnitt 8.
(22)Der akkreditierte PKI-Prüfer übermittelt die Ergebnisse der CPS-Bewertung als Teil des Auditberichts gemäß Darlegung in Abschnitt 8.1. Die CPS wird im Rahmen der Annahme oder Ablehnung des Auditberichts (siehe die Abschnitte 8.5 und 8.6 angenommen oder abgelehnt.
2.Verantwortlichkeiten für Veröffentlichung und Datenablage (Repository)
2.1.Methoden für die Veröffentlichung von Informationen über Zertifikate
(23)Informationen über Zertifikate können wie in Abschnitt 2.5 beschrieben veröffentlicht werden, d. h.:
·regelmäßig oder periodisch;
·auf Antrag einer der beteiligten Stellen.
In jedem dieser Fälle gelten unterschiedliche Dringlichkeitsstufen für die Veröffentlichung und somit Zeitpläne, die Teilnehmer müssen jedoch auf beide Regelungsarten vorbereitet sein.
(24)Die regelmäßige Veröffentlichung der Informationen über Zertifikate ermöglicht es, eine maximale Frist zu bestimmen, innerhalb der Informationen über Zertifikate für alle Knotenpunkte des C-ITS-Netzes aktualisiert werden. Die Häufigkeit der Veröffentlichung sämtlicher Informationen über Zertifikate wird in Abschnitt 2.2 festgelegt.
(25)Auf Antrag von Stellen, die am C-ITS-Netz beteiligt sind, können Teilnehmer jederzeit mit der Veröffentlichung von Informationen über Zertifikate beginnen und abhängig von ihrem Status einen aktuellen Satz an Informationen über Zertifikate anfordern, damit sie zu einem voll vertrauenswürdigen Knotenpunkt des C-ITS-Netzes werden können. Der Zweck dieser Veröffentlichung besteht vor allem darin, Teilnehmer auf den neusten allgemeinen Stand der Zertifikatinformationen im Netz zu bringen und sie in die Lage zu versetzen, bis zur nächsten regulären Veröffentlichung der Informationen auf Vertrauensbasis zu kommunizieren.
(26)Eine einzelne Root-CA kann ebenfalls jederzeit die Veröffentlichung von Informationen über Zertifikate einleiten, indem sie allen „abonnierten Mitgliedern“ des C-ITS-Netzes, die regelmäßig Informationen dieser Art erhalten, sind, einen aktualisieren Satz von Zertifikaten übermittelt. Dies unterstützt die Arbeit der CA und versetzt sie in die Lage, sich zwischen den regelmäßigen, geplanten Veröffentlichungsterminen der Zertifikate an die Mitglieder zu wenden.
(27)In Abschnitt 2.5 werden die Mechanismen und sämtliche Verfahren für die Veröffentlichung der Root-CA-Zertifikate und der ECTL dargelegt.
(28)Die zentrale Kontaktstelle (CPOC) veröffentlicht die (in der ECTL enthaltenen und für den öffentlichen Gebrauch bestimmten) Root-CA-Zertifikate, das TLM-Zertifikat und die ECTL, die sie herausgibt.
(29)Root-CA veröffentlichen ihre EA/AA-Zertifikate und CRL und sind in der Lage, alle drei an dieser Stelle genannten Mechanismen für deren Veröffentlichung bei ihren abonnierten Mitgliedern und Vertrauenden Dritten zu unterstützen, wobei sie alle erforderlichen Schritte zur Gewährleistung einer sicheren Übertragung gemäß Abschnitt 4 unternehmen.
2.2.Zeitpunkt oder Häufigkeit der Veröffentlichung
(30)Die Anforderungen an den Veröffentlichungszeitplan für Zertifikate und CRL müssen unter Berücksichtigung der verschiedenen einschränkenden Faktoren der einzelnen C-ITS-Knotenpunkte festgelegt werden, wobei das übergeordnete Ziel darin besteht, ein „vertrauenswürdiges Netz“ zu betreiben und Aktualisierungen so schnell wie möglich bei allen beteiligten C-ITS-Stationen zu veröffentlichen.
·Für die regelmäßige Veröffentlichung aktueller Informationen über Zertifikate (z. B. Änderungen an der Zusammensetzung der ECTL oder CRL) ist für den sicheren Betrieb des C-ITS-Netzes eine Frist von höchstens drei Monaten erforderlich.
·Root-CA veröffentlichen ihre CA-Zertifikate und CRL möglichst bald nach der Ausstellung.
·Für die Veröffentlichung der CRL wird die Datenablage (Repository) der Root-CA benutzt.
Darüber hinaus wird in der CPS für jede CA der Zeitraum angegeben, innerhalb dessen nach der Ausstellung eines Zertifikates durch die CA das betreffende Zertifikat veröffentlicht wird.
In diesem Abschnitt wird nur der Zeitpunkt oder die Häufigkeit der regelmäßigen Veröffentlichung festgelegt. Mittel zur Herstellung von Verbindungen zur Aktualisierung von C-ITS-Stationen mit den ECTL und CRL innerhalb einer Woche nach ihrer Veröffentlichung (unter normalen Betriebsbedingungen, z. B. Mobilfunkabdeckung, tatsächlicher Betrieb des Fahrzeugs usw.) werden den in im vorliegenden Dokument genannten Anforderungen entsprechend eingeführt.
2.3.Datenablagen
(31)Die Anforderungen an die Struktur der Datenablage zur Speicherung der Zertifikate und der von den Teilnehmern des C-ITS-Netzes zur Verfügung gestellten Informationen lauten für einzelne Teilnehmer wie folgt:
·im Allgemeinen sollte jede Root-CA eine Datenablage für Informationen über ihre eigenen, aktuell aktiven EA/AA-Zertifikate und CRL nutzen, um Zertifikate für die anderen PKI-Teilnehmer zu veröffentlichen (z. B. einen LDAPgestützten Verzeichnisdienst). Die Datenablage jeder Root-CA unterstützt alle erforderlichen Zugangskontrollen (Abschnitt 2.4) und Übertragungszeiten (Abschnitt 2.2) für jede Verbreitungsmethode für Informationen im Zusammenhang mit C-ITS;
·die Datenablage des TLM (Trust List Manager) (in der beispielsweise die von der CPOC veröffentlichten ECTL und TLM-Zertifikate gespeichert werden) sollte sich auf ein Veröffentlichungsverfahren stützen, das für jede Verteilungsmethode die in Abschnitt 2.2 dargelegten Übertragungszeiten gewährleisten kann.
Die Anforderungen der AA sind nicht festgelegt, müssen jedoch die gleichen Sicherheitsstufen wie die anderen Teilnehmer unterstützen; diese müssen in ihrer CPS ausgewiesen sein.
2.4.Zugangskontrollen für Datenablagen (Repositories)
(32)Die Anforderungen an die Zugangskontrolle zu Datenablagen für Informationen über Zertifikate genügen mindestens den allgemeinen Standards für den sicheren Umgang mit Informationen gemäß ISO/IEC 27001 und den Anforderungen in Abschnitt 4. Darüber hinaus müssen sie die Prozesssicherheit widerspiegeln, die für die einzelnen Verfahrensschritte bei der Veröffentlichung der Zertifikatinformationen hergestellt werden muss.
·Dazu gehört auch die Implementierung der Datenablage für TLM-Zertifikate und ECTL bei dem TLM/der CPOC. Alle Zertifizierungsstellen (CA) oder Betreiber von Datenablagen implementieren in Bezug auf sämtliche C-ITS-Teilnehmer und externen Parteien Zugangskontrollen für mindestens drei verschiedene Ebenen (z. B. allgemein zugänglich, beschränkt auf C-ITS-Teilnehmer, Root-CA-Ebene), um zu verhindern, dass Unbefugte Einträge in der Datenablage ergänzen, ändern oder löschen können.
·Die genauen Zugangskontrollmechanismen der einzelnen Teilnehmer sollten Bestandteil der jeweiligen CPS sein.
·Bei jeder einzelnen Root-CA müssen die EA- und AA-Datenablagen die gleichen Anforderungen an die Zugangskontrollverfahren erfüllen, und zwar unabhängig von dem Ort oder der vertraglichen Bindung an den Diensteanbieter, der die Datenablage betreibt.
Als Ausgangspunkt für die verschiedenen Ebenen der Zugangskontrolle sollten alle Root-CA oder Betreiber von Datenablagen mindestens drei verschiedene Ebenen (z. B. allgemein zugänglich, beschränkt auf C-ITS-Teilnehmer, Root-CA-Ebene) bereitstellen.
2.5.Veröffentlichung von Informationen über Zertifikate
2.5.1.Veröffentlichung von Informationen über das Zertifikat durch den TLM
(33)Der TLM im gemeinsamen europäischen C-ITS-Vertrauensbereich veröffentlicht die folgenden Informationen über die CPOC:
·alle derzeit gültigen TLM-Zertifikate für den nächsten Betriebszeitraum (aktuelle und Link-Zertifikate, sofern vorhanden);
·Informationen über die Zugangsstelle für die CPOC-Datenablage zur Bereitstellung der signierten Liste von Root-CA (ECTL);
·allgemeine Informationsstelle für die ECTL und den Einsatz der C-ITS.
2.5.2.Veröffentlichung von Informationen über Zertifikate durch CA
(34)Root-CA im gemeinsamen europäischen C-ITS-Vertrauensbereich veröffentlichen folgende Informationen:
·ausgestellte (derzeit gültige) Root-CA-Zertifikate (aktuelle Zertifikate und Zertifikate mit korrekt erneuertem Schlüssel, einschließlich eines Link-Zertifikats) in der in Abschnitt 2.3 genannten Datenablage;
·alle gültigen EA, AA-Teilnehmer mit Betreiber-ID und der geplanten Betriebsdauer;
·ausgestellte CA-Zertifikate in den in Abschnitt 2.3 genannten Datenablagen;
·die CRL für alle gesperrten CA-Zertifikate, die ihre nachgeordneten EA und AA abdecken;
·Angaben zur Zugangsstelle der CA zur CRL und zu CA-Informationen.
Alle Zertifikate sind in drei Vertraulichkeitsebenen einzustufen und für die allgemeine Öffentlichkeit bestimmte Dokumente müssen ohne Einschränkungen öffentlich zugänglich sein.
3.Identifizierung und Authentifizierung
3.1.Namen
3.1.1.Arten von Namen
3.1.1.1.Namen für TLM, Root-CA, EA, AA
(35)Der Name im TLM-Zertifikat besteht aus einem einzelnen Attribut „subject_Name“ mit dem reservierten Wert „EU_TLM“.
(36)Der Name von Root-CA besteht aus einem einzelnen Attribute „subject_Name“ mit einem von der CPA zugewiesenen Wert. Die Eindeutigkeit von Namen liegt in der alleinigen Verantwortung der CPA und der TLM muss das Register der Root-CA-Namen nach entsprechender Benachrichtigung durch die CPA pflegen (Genehmigung, Sperrung/Löschung einer Root-CA). Die Subjektnamen in Zertifikaten sind auf 32 Bytes beschränkt. Jede Root-CA schlägt der CPA ihren Namen in dem Antragsformular (Ablauf 14) vor. Die CPA ist für die Überprüfung der Eindeutigkeit von Namen zuständig. Ist der Name nicht eindeutig, wird das Antragsformular zurückgewiesen (Ablauf 4).
(37)Der Name in jedem EA/AA-Zertifikat kann aus einem einzelnen Attribut „subject_Name“ bestehen, das vom Aussteller des Zertifikats generiert wird. Die Eindeutigkeit von Namen liegt in der alleinigen Verantwortung der ausstellenden Root-CA.
(38)In den EA- und AA-Zertifikaten darf kein Name verwendet werden, der länger als 32 Byte ist, da der subject_Name in Zertifikaten auf 32 Bytes beschränkt ist.
(39)Die AT dürfen keinen Namen enthalten.
3.1.1.2.Namen für Endteilnehmer
(40)Jeder C-ITS-Station werden zwei Arten von eindeutigen Kennungen zugewiesen:
·eine kanonische ID, die bei der erstmaligen Registrierung der C-ITS-Station unter der Verantwortung des Herstellers gespeichert wird. Sie enthält eine Teilkette, aus der der Hersteller oder Betreiber hervorgeht, so dass diese Kennung eindeutig sein kann;
·einen „subject_name“ der Teil des Enrollment-Berechtigungsnachweises (EC) der C-ITS-Station sein kann und für den die EA verantwortlich ist.
3.1.1.3.Identifizierung der Zertifikate
(41)Zertifikate, die dem Format in [5] entsprechen, werden mittels Berechnung eines HasdId8-Werts gemäß Definition in [5] identifiziert.
3.1.2.Notwendigkeit der Aussagekraft von Namen
Keine Bestimmung vorgesehen.
3.1.3.Anonymität und Pseudonymität von Endteilnehmern
(42)Die AA stellt sicher, dass die Pseudonymität einer C-ITS-Station dadurch hergestellt wird, dass die C-ITS-Station mit AT versehen wird, die keine Namen oder Angaben enthalten, die eine Verbindung zwischen dem Subjekt und seiner wirklichen Identität herstellen könnten.
3.1.4.Regeln für die Auslegung verschiedener Namensformen
Keine Bestimmung vorgesehen.
3.1.5.Eindeutigkeit von Namen
(43)Die Namen für die TLM, Root-CA, EA, AA und kanonischen ID für C-ITS-Stationen müssen eindeutig sein.
(44)Der TLM stellt im Registrierungsprozess einer bestimmten Root-CA in der ECTL sicher, dass deren Zertifikatskennung (HaheudId8) eindeutig ist. Die Root-CA stellt im Ausstellungsprozess sicher, dass die Zertifikatskennung (HashedId8) jeder nachgeordneten CA eindeutig ist.
(45)Die HasheudId8 eines EC muss innerhalb der ausstellenden CA eindeutig sein. Die HasheudId8 eines AT muss nicht eindeutig sein.
3.2.Erstmalige Validierung der Identität
3.2.1.Methode zum Nachweis des Besitzes des privaten Schlüssels
(46)Die Root-CA muss nachweisen, dass sie den privaten Schlüssel, der dem öffentlichen Schlüssel im selbstunterzeichneten Zertifikat entspricht, rechtmäßig besitzt. Die CPOC überprüft diesen Nachweis.
(47)Die EA/AA muss nachweisen, dass sie den privaten Schlüssel, der dem im Zertifikat aufzuführenden öffentlichen Schlüssel entspricht, rechtmäßig besitzt. Die Root-CA überprüft diesen Nachweis.
(48)Der Besitz eines neuen privaten Schlüssels (zur Schlüsselerneuerung) wird mittels Signieren des Antrags mit dem neuen privaten Schlüssel (innere Signatur), gefolgt von der Generierung einer äußeren Signatur mit dem derzeit gültigen privaten Schlüssel über dem signierten Antrag nachgewiesen (als Garantie für die Authentizität des Antrags (Request)). Der Antragsteller reicht den unterzeichneten Zertifikatantrag über einen sicheren Kommunikationsweg bei der ausstellenden CA ein. Die ausstellende CA überprüft, ob die digitale Signatur des Antragstellers mit Hilfe des privaten Schlüssels erstellt wurde, der dem öffentlichen, dem Zertifikatantrag beigefügten Schlüssel entspricht. Die Root-CA gibt an, welche Zertifikatanträge und Antworten sie in ihrer CPS unterstützt.
3.2.2.Authentifizierung der Organisationsidentität
3.2.2.1.Authentifizierung der Organisationsidentität der Root-CA
(49)In einem Antragsformular an die CPA (d. h. Ablauf 14) übermittelt die Root-CA die Identität der Organisation und die Registrierungsinformationen, die sich wie folgt zusammensetzen:
·Name der Organisation;
·Postanschrift;
·E-Mailadresse;
·Name einer natürlichen Kontaktperson in der Organisation;
·(Telefonnummer;
·digitaler Fingerabdruck (d. h. SHA 256 Hash-Wert) des Zertifikates der Root-CA in gedruckter Form;
·kryptografische Informationen (d. h. kryptografische Algorithmen, Schlüssellängen) im Zertifikat der CA-Root;
·alle Genehmigungen, die die Root-CA nutzen und an Sub-CA weitergeben darf.
(50)Die CPA prüft die Identität der Organisation und der sonstigen Registrierungsinformationen, die vom Antragsteller auf Aufnahme eines Zertifikats der Root-CA in die ECTL bereitgestellt werden.
(51)Im Hinblick auf die Identität (z. B, den Namen) und gegebenenfalls hinsichtlich besonderer Attribute der Subjekte, denen ein Zertifikat ausgestellt wird, erhebt die CPA entweder unmittelbare Nachweise oder sie beschafft eine Bestätigung einer geeigneten, berechtigten Quelle. Die Nachweise können in Papierform oder in elektronischer Form vorgelegt werden.
(52)Die Identität des Subjekts wird zum Zeitpunkt der Registrierung auf geeignete Weise und im Einklang mit der vorliegenden Certificate Policy verifiziert.
(53)Bei jedem Zertifikatantrag sind Nachweise für Folgendes zu erbringen:
·den vollständigen Namen der organisatorischen Einheit (private Organisation, staatliche Stelle oder nichtgewerbliche Einrichtung);
·eine national anerkannte Registrierung oder sonstige Attribute, die so weit wie möglich zur Unterscheidung der Organisationseinheit von anderen mit demselben Namen eingesetzt werden können.
Die vorstehenden Regeln beruhen auf TS 102 042 [4]: Die CA stellt sicher, dass Nachweise für die Identifizierung von Abonnent und Subjekt sowie die Richtigkeit ihrer Namen und damit verbundenen Daten entweder im Rahmen des definierten Dienstes ordnungsgemäß geprüft oder gegebenenfalls mittels Prüfung von Bestätigungen geeigneter, berechtigte Quellen gefolgert werden; sie stellt ferner sicher, dass Anträge auf Zertifikate richtig, autorisiert und vollständig sind und den erhobenen Nachweisen oder Bestätigungen entsprechen.
3.2.2.2.Authentifizierung der Identität der TLM-Organisation
(54)Die Organisation, die das TLM betreibt, muss Nachweise für die Identifizierung und die Richtigkeit des Namens und der damit verbundenen Daten erbringen, um eine angemessene Verifizierung der erstmaligen Erstellung und Schlüsselerneuerung des TLM-Zertifikats zu ermöglichen.
(55)Die Identität des Subjekts wird zum Zeitpunkt der Erstellung des Zertifikats oder der Schlüsselerneuerung mit geeigneten Mitteln und im Einklang mit der vorliegenden Certificate Policy (CP) verifiziert.
(56)Nachweise für die Organisation werden auf die gleiche Weise wie in Abschnitt 3.2.2.1 spezifiziert übermittelt.
3.2.2.3.Authentifizierung der Identität von Sub-CA-Organisationen
(57)Die Root-CA prüft die Identität der Organisation sowie weitere Registrierungsangaben, die von Antragstellern für Sub-CA-Zertifikate (EA/AA) vorgelegt werden.
(58)Die Root-CA muss mindestens:
·die Existenz der Organisation durch einen Identitätsprüfungsservice oder eine Identitätsprüfungsdatenbank eines Dritten oder alternativ durch entsprechende Organisationsdokumente feststellen, die von einer zuständigen staatlichen Stelle oder anerkannten Behörde ausgestellt oder bei ihr eingereicht wurden und die Existenz der Organisation bestätigen;
·mittels Briefpost oder eines vergleichbaren Verfahrens den Antragsteller auffordern, bestimmte Informationen über die Organisation zu bestätigen und ferner zu bestätigen, dass er den Antrag auf ein Zertifikat genehmigt hat und dass die Person, die den Antrag im Namen des Antragstellers einreicht, dazu berechtigt ist. Enthält ein Zertifikat den Namen einer natürlichen Person als Bevollmächtigter der Organisation, bestätigt er außerdem, dass diese natürliche Person bei ihm beschäftigt ist und dass er sie bevollmächtigt hat, in seinem Namen zu handeln.
(59)Die Validierungsverfahren für die Ausstellung von CA-Zertifikaten werden in einer CPS der Root-CA dokumentiert.
3.2.2.4.Authentifizierung der Abonnentenorganisation von Endteilnehmern
(60)Bevor sich ein Abonnent von Endteilnehmern (Hersteller/Betreiber) bei einer vertrauenswürdigen EA anmelden kann, um seinen Endteilnehmern zu ermöglichen, Anträge auf EC-Zertifikate zu versenden, muss die EA
·die Identität der Abonnentenorganisation und andere vom Antragsteller bereitgestellte Registrierungsinformationen überprüfen;
·prüfen, ob der Typ der C-ITS-Station (d. h. das auf Marke, Modell und Version der C-ITS-Station basierende, konkrete Produkt) alle Kriterien für die Compliance-Bewertung erfüllt.
(61)Die EA muss mindestens:
·die Existenz der Organisation durch einen Identitätsprüfungsservice oder eine Identitätsprüfungsdatenbank eines Dritten oder alternativ durch entsprechende Organisationsdokumente feststellen, die von einer zuständigen staatlichen Stelle oder anerkannten Behörde ausgestellt oder bei ihr eingereicht wurden und die Existenz der Organisation bestätigen;
·mittels Briefpost oder eines vergleichbaren Verfahrens den Antragsteller auffordern, bestimmte Informationen über die Organisation zu bestätigen und ferner zu bestätigen, dass er den Antrag auf ein Zertifikat genehmigt hat und dass die Person, die den Antrag in seinem Namen einreicht, dazu berechtigt ist. Enthält ein Zertifikat den Namen einer natürlichen Person als Bevollmächtigter der Organisation, bestätigt er außerdem, dass diese natürliche Person bei ihm beschäftigt ist und dass er sie bevollmächtigt hat, in seinem Namen zu handeln.
(62)Die Validierungsverfahren für die Registrierung einer C-ITS-Station durch ihren Abonnenten werden in einer CPS der EA dokumentiert.
3.2.3.Authentifizierung einzelner Teilnehmer
3.2.3.1.Authentifizierung des einzelnen TLM/CA-Teilnehmers
(63)Für die Authentifizierung eines einzelnen Teilnehmers (natürliche Person), die in Verbindung mit einer juristischen Person oder einer organisatorischen Einheit (z. B. dem Abonnenten) identifiziert wurde, sind Nachweise über Folgendes vorzulegen:
·vollständiger Name des Subjekts (einschließlich des Nachnamens und der Vornamen, im Einklang mit geltendem Recht und den nationalen Verfahren zur Feststellung der Personalien);
·Geburtsdatum und Geburtsort, Verweis auf ein national anerkanntes Ausweisdokument oder andere Attribute des Abonnenten, die so weit wie möglich verwendet werden können, um die Person von anderen mit demselben Namen zu unterscheiden;
·vollständiger Name und Rechtsform der verbundenen juristischen Person oder einer anderen Organisationseinheit (z. B. der Abonnent);
·alle einschlägigen Registrierungsinformationen (z. B. die Firmenregistrierung) der verbundenen juristischen Person oder einer anderen Organisationseinheit;
·Nachweis, dass das Subjekt mit der juristischen Person oder einer anderen Organisationseinheit verbunden ist.
Die Nachweise können in Papierform oder in elektronischer Form vorgelegt werden.
(64)Zur Überprüfung seiner Identität legt der Bevollmächtigte einer Root-CA, EA, AA oder eines Abonnenten Unterlagen vor, aus denen hervorgeht, dass er für die Organisation arbeitet (Vollmachtsurkunde). Er muss außerdem einen amtlichen Ausweis vorlegen.
(65)Beim Verfahren des erstmaligen Enrollments (Ablauf 31/32) übermittelt ein Vertreter der EA/AA der entsprechenden Root-CA alle erforderlichen Informationen (siehe Abschnitt 4.1.2).
(66)Das Personal der Root-CA überprüft die Identität des Vertreters des Zertifikatantragstellers und alle zugehörigen Unterlagen, wobei es die Anforderungen für „vertrauenswürdiges Personal“ gemäß Abschnitt 5.2.1 anwendet. (Das Verfahren zur Validierung der Antragsdaten und zur Erstellung des Zertifikats durch die CA erfolgt durch „vertrauenswürdige Personen“ bei der Root-CA, die mindestens einer doppelten Aufsicht unterliegen, da es sich um sensible Vorgänge im Sinne von Abschnitt 5.2.2 handelt).
3.2.3.2.Authentifizierung der Identität der Abonnenten von C-ITS-Stationen
(67)Abonnenten werden durch autorisierte Endnutzer in der Organisation vertreten, die bei der ausstellenden EA und AA registriert sind. Diese Endnutzer, die von Organisationen (Herstellern oder Betreibern) benannt wurden, müssen ihre Identität und Authentizität nachweisen, bevor
·sie den Endteilnehmer (EE) bei seiner entsprechenden EA einschließlich seines kanonischen öffentlichen Schlüssels, der kanonischen ID (eindeutige Kennung) und der dem EE entsprechenden Genehmigungen registrieren;
·sich bei der AA anmelden und den Nachweis eines Abonnentenvertrags beschaffen, der an die EA übermittelt werden kann.
3.2.3.3.Authentifizierung der Identität von C-ITS-Stationen
(68)Endteilnehmer-Subjekte von EC authentifizieren sich bei der Beantragung von EC (Ablauf 31) selbst, indem sie ihren kanonischen Privatschlüssel für die erstmalige Authentifizierung verwenden. Die EA prüft die Authentifizierung anhand des kanonischen öffentlichen Schlüssels, der dem EE entspricht. Die kanonischen öffentlichen Schlüssel der EE werden der EA vor der Ausführung des ursprünglichen Antrags auf einem sicheren Kanal zwischen dem Hersteller oder Betreiber der C-ITS-Station und der EA übergeben (Ablauf 33).
(69)Die Endteilnehmer-Subjekte von AT authentifizieren sich bei der Beantragung von AT (Ablauf 32) selbst, indem sie ihren eindeutigen privaten Enrollment-Schlüssel verwenden. Die AA leitet die Signatur zur Validierung an die EA weiter (Ablauf 25); die EA validiert diese und bestätigt das Ergebnis der AA gegenüber (Ablauf 23).
3.2.4.Nicht verifizierte Angaben zu Abonnenten
Keine Bestimmung vorgesehen.
3.2.5.Validierung der Zertifizierungsstelle
3.2.5.1.Validierung von TLM, Root-CA, EA, AA
(70)Jede Organisation muss in der CPS mindestens einen Vertreter (z. B. einen Sicherheitsbeauftragten) benennen, der für die Beantragung neuer Zertifikate und Erneuerungen zuständig ist. Es gelten die Namensgebungsregeln in Abschnitt 3.2.3.
3.2.5.2.Validierung des Abonnenten der C-ITS-Station
(71)Mindestens eine natürliche Person, die für die Registrierung der C-ITS-Stationen bei einer EA verantwortlich ist (z. B. Sicherheitsbeauftragter) muss der EA bekannt und von ihr zugelassen sein (siehe Abschnitt 3.2.3).
3.2.5.3.Validierung von C-ITS-Stationen
(72)Ein Abonnent einer C-ITS-Station kann C-ITS-Stationen in einem bestimmten EA (Ablauf 33) registrieren lassen, sofern er von dieser EA authentifiziert wird.
Wird die C-ITS-Station mit einer eindeutigen kanonischen ID und einem kanonischen öffentlichen Schlüssel bei einer EA registriert, kann sie mittels eines Antrags, der mit dem kanonischen Privatschlüssel, der mit dem zuvor registrierten, kanonischen öffentlichen Schlüssel verbunden ist, signiert wurde, einen Enrollment-Berechtigungsnachweis (EC) beantragen.
3.2.6.Kriterien für die Interoperabilität
(73)Für die Kommunikation zwischen C-ITS-Stationen und EA (oder AA) muss die C-ITS-Station in der Lage sein, eine sichere Kommunikation mit EA (oder AA) herzustellen, d. h. Authentifizierungs-, Vertrauens- und Integritätsfunktionen gemäß Spezifikation in [1] zu implementieren Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist. Die EA und AA unterstützen diese sichere Kommunikation.
(74)Die EA und AA unterstützen Zertifikatanträge und Antworten, die konform mit [1] sind; dort ist ein sicheres Protokoll für die Beantragung/Beantwortung von AT vorgesehen, das die Anonymität des Antragstellers gegenüber der AA und die Aufgabentrennung zwischen AA und EA unterstützt. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist. Um eine Offenlegung der langfristigen Identität von C-ITS-Stationen zu verhindern, muss die Kommunikation zwischen einer mobilen C-ITS-Station und einer EA vertraulich sein (z. B. werden die Kommunikationsdaten durchgehend verschlüsselt „end-to-end“).
(75)Die AA übermittelt für jeden Auftrag auf Bevollmächtigung, den sie von einem Subjekt eines EE-Zertifikats erhält, ein Ersuchen um Validierung der Bevollmächtigung (Ablauf 25). Die EA validiert dieses Ersuchen in Bezug auf
·den Status der EE bei der EA;
·die Gültigkeit der Signatur;
·die beantragten ITS-Anwendungs-ID (ITS-AID) und -Berechtigungen;
·der Stand der Dienstleistungserbringung seitens AA gegenüber dem Abonnenten.
3.3.Identifizierung und Authentifizierung von Schlüsselerneuerungsanträgen (Re-Key)
3.3.1.Identifizierung und Authentifizierung für routinemäßige Schlüsselerneuerungsanträge
3.3.1.1.TLM-Zertifikate
(76)Der TLM generiert ein Schlüsselpaar und zwei Zertifikate: ein selbstsigniertes Zertifikat und ein Link-Zertifikat gemäß Abschnitt 7.
3.3.1.2.Root-CA-Zertifikate
Entfällt.
3.3.1.3.EA/AA-Zertifikatserneuerung oder Schlüsselerneuerung
(77)Bevor ein EA/AA-Zertifikat abläuft, beantragt die EA/AA ein neues Zertifikat (Ablauf 21/Ablauf 24), um die Kontinuität der Zertifikatsnutzung aufrechtzuerhalten. Die EA/AA generiert ein neues Schlüsselpaar zum Ersatz des ablaufenden Schlüsselpaars und signiert den Antrag auf Schlüsselerneuerung, der den neuen öffentlichen Schlüssel enthält, mit dem derzeit gültigen privaten Schlüssel („Schlüsselerneuerung“). Die EA oder AA generiert ein neues Schlüsselpaar und signiert den Antrag mit dem neuen privaten Schlüssel (innere Signatur) als Nachweis für den Besitz des neuen privaten Schlüssels. Der gesamte Antrag wird (gegengezeichnet) mit dem derzeit gültigen privaten Schlüssel (äußere Signatur) signiert, um die Integrität und Authentizität des Antrags zu gewährleisten. Wird ein Schlüsselpaar zur Ver- und Entschlüsselung verwendet, wird der Besitz privater Entschülsselungsschlüssel nachgewiesen (eine ausführliche Beschreibung der Schlüsselerneuerung ist Abschnitt 4.7.3.3 zu entnehmen).
(78)Die Identifizierungs- und Authentifizierungsmethode für routinemäßige Schlüsselerneuerungen entspricht der Methode für die Validierung der erstmaligen Ausstellung eines erstmaligen Root-CA-Zertifikats gemäß Abschnitt 3.2.2.
3.3.1.4.Berechtigungsnachweise von Endteilnehmern für das Enrollment (Anmeldung)
(79)Bevor ein bestehender EC (Berechtigungsnachweis) abläuft, beantragt der Endteilnehmer (EE) ein neues Zertifikat (Ablauf 31), um die Kontinuität der Zertifikatsnutzung aufrechtzuerhalten. Der EE generiert ein neues Schlüsselpaar, um das auslaufenden Schlüsselpaar zu ersetzen, und beantragt mit dem neuen öffentlichen Schlüssel ein neues Zertifikat; der Antrag wird mit dem derzeit gültigen privaten Schlüssel des EC signiert.
(80)Der EE (Endteilnehmer) kann den Antrag mit dem neu geschaffenen privaten Schlüssel (innere Signatur) unterzeichnen, um den Besitz des neuen privaten Schlüssels zu belegen. Anschließend wird der gesamte Antrag mit dem derzeit gültigen privaten Schlüssel signiert (gegengezeichnet) (äußere Signatur) und der empfangenden EA gegenüber gemäß Spezifikation in [1] verschlüsselt, um die Vertraulichkeit, Integrität und Authentizität des Antrags zu gewährleisten. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
3.3.1.5.Berechtigungstickets von Endteilnehmern
(81)Die Schlüsselerneuerung für Zertifikate für AT beruht auf demselben Verfahren wie die erstmalige Bevollmächtigung gemäß Definition in [1]. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
3.3.2.Identifizierung und Authentifizierung bei Schlüsselerneuerungsanträgen nach Zertifikatssperrung
3.3.2.1.CA-Zertifikate
(82)Die Authentifizierung einer CA-Organisation zur Schlüsselerneuerung für Root-CA-, EA- und AA-Zertifikate nach einer Sperrung wird in der gleichen Weise gehandhabt wie die erstmalige Ausstellung eines CA-Zertifikats gemäß Abschnitt 3.2.2.
3.3.2.2.Berechtigungsnachweise von Endteilnehmern für das Enrollment (Anmeldung)
(83)Die Authentifizierung eines EE (Endteilnehmers) zur Schlüsselerneuerung für ein EC-Zertifikat nach einer Sperrung wird in der gleichen Weise gehandhabt wie die erstmalige Ausstellung eines EE-Zertifikats gemäß Abschnitt 3.2.2.
3.3.2.3.Berechtigungsanträge von Endteilnehmern
Entfällt, da AT nicht gesperrt werden.
3.4.Identifizierung und Authentifizierung für Sperrungsantrag
3.4.1.Root-CA/EA/AA-Zertifikate
(84)Anträge auf Streichung eines Root-CA-Zertifikats aus der ECTL werden von der Root-CA dem TLM gegenüber authentifiziert (Abläufe 12 und 9). Anträge auf Sperrung eines EA/AA-Zertifikats werden von der maßgeblichen Root-CA und Sub-CA selbst authentifiziert.
(85)Zulässige Verfahren für die Authentifizierung von Sperranträgen eines Abonnenten sind unter anderem:
·eine schriftliche, unterschriebene Nachricht des Abonnenten auf dessen Firmenbriefpapier, mit der er unter Nennung des zu sperrenden Zertifikats die Sperrung beantragt;
·Kommunikation mit dem Abonnenten, der hinreichende Garantien dafür bietet, dass die Person oder Organisation, die die Sperrung beantragt, tatsächlich der Abonnent ist. Je nach Umständen kann eine solche Kommunikation einen oder mehrere folgender Wege beinhalten: E-Mail, Briefpost oder Kurierdienst.
3.4.2.Enrollment-Berechtigungsnachweise von C-ITS-Stationen
(86)Der Abonnent der C-ITS-Station kann den Enrollment-Berechtigungsnachweis (EC) einer zuvor registrierten C-ITS-Station bei einer EA sperren lassen (Ablauf 34). Der antragstellende Abonnent erstellt einen Antrag auf Sperrung einer bestimmten C-ITS-Station oder Liste von C-ITS-Stationen. Die EA authentifiziert den Sperrantrag vor der Verarbeitung und bestätigt die Sperrung der C-ITS-Stationen und ihrer Enrollment-Berechtigungsnachweise (EC).
(87)Die EA kann den EC einer C-ITS-Station im Einklang mit Abschnitt 7.3 sperren.
3.4.3.Berechtigungstickets von C-ITS-Stationen
(88)Da Berechtigungstickets (AT) nicht gesperrt werden, wird ihre Gültigkeit auf einen bestimmten Zeitraum begrenzt. Der Umfang zulässiger Gültigkeitszeiträume in der vorliegenden Certificate Policy wird in Abschnitt 7 spezifiziert.
4.Betriebliche Anforderungen im Lebenszyklus von Zertifikaten
4.1.Zertifikatantrag
(89)In diesem Abschnitt werden die Anforderungen an einen Erstantrag auf Ausstellung eines Zertifikats dargelegt.
(90)Der Begriff „Zertifikatantrag“ bezieht sich auf folgende Vorgänge:
·Registrierung und Aufbau eines Vertrauensverhältnisses zwischen dem TLM und der CPA;
·Registrierung und Aufbau eines Vertrauensverhältnisses zwischen der Root-CA, der CPA und dem TLM, einschließlich der Aufnahme des ersten Root-CA-Zertifikats in die ECTL (Liste vertrauenswürdiger europäischer Zertifikate);
·Registrierung und Aufbau von Vertrauensverhältnissen zwischen der EA/AA und der Root-CA, einschließlich der Ausstellung eines neuen EA-/AA-Zertifikats;
·Registrierung der C-ITS-Station bei der EA durch den Hersteller/Betreiber;
·Antrag der C-ITS-Stelle auf EC/AT.
4.1.1.Wer kann einen Zertifikatantrag einreichen?
4.1.1.1.Root-CA
(91)Root-CA generieren ihre eigenen Schlüsselpaare und stellen ihr Wurzelzertifikat selbst aus. Eine Root-CA kann einen Zertifikatantrag durch ihren benannten Vertreter einreichen (Ablauf 14).
4.1.1.2.TLM
(92)Der TLM generiert seine eigenen Schlüsselpaare und stellt seine Zertifikate selbst aus. Die erstmalige Erstellung des TLM-Zertifikats wird von einem Vertreter der TLM-Organisation unter der Kontrolle der CPA verarbeitet.
4.1.1.3.EA und AA
(93)Die Anforderung eines Zertifikatantrags der Sub-CA (EA und/oder AA) kann von einem Bevollmächtigten der EA oder AA beim Bevollmächtigten der maßgeblichen Root-CA eingereicht werden (Ablauf 27/28).
4.1.1.4.C-ITS-Station
(94)Abonnenten registrieren im Einklang mit Abschnitt 3.2.5.3 jede C-ITS-Station bei der EA.
(95)Jede bei der EA registrierte C-ITS-Station kann Anträge auf Enrollment-Berechtigungsnachweise (EC) versenden (Ablauf 31).
(96)Jede C-ITS-Station kann Anträge auf Berechtigungstickets (AT) versenden (Ablauf 32), ohne Interaktionen mit Abonnenten anzufordern. Bevor eine C-ITS-Station einen AT beantragt, muss sie über einen EC verfügen.
4.1.2.Enrollment-Prozess und Verantwortlichkeiten
(97)Genehmigungen, dass Root-CA und Sub-CA Zertifikate für bestimmte (behördliche) Zwecke ausstellen dürfen (d. h. besondere mobile und ortsfeste C-ITS-Stationen), können nur von den Mitgliedstaaten erteilt werden, in denen die Organisationen ansässig sind.
4.1.2.1.Root-CA
(98)Nach ihrem Audit (Ablauf 13 und 36, Abschnitt 8) können Root-CA bei der CPA die Aufnahme ihres Zertifikats bzw. ihrer Zertifikate in die ECTL beantragen (Ablauf 14). Der Enrollment-Prozess basiert auf einem unterschriebenen, von Hand ausgefüllten Antragsformular, das der CPA vom Bevollmächtigten der Root-CA physisch übergeben wird und mindestens die in den Abschnitten 3.2.2.1, 3.2.3 und 3.2.5.1 genannten Angaben enthält.
(99)Das Antragsformular der CA wird von deren Bevollmächtigten unterzeichnet.
(100)Zusätzlich zum Antragsformular legt der Bevollmächtigte der Root-CA der CPA eine Kopie der Erklärung zum Zertifizierungsbetrieb (CPS) der Root-CA (Ablauf 15) und ihren Auditbericht zur Genehmigung vor (Ablauf 16). Im Falle eines positiven Bescheids generiert und versendet die CPA eine Konformitätsbescheinigung an die CPOC/den TLM und die entsprechende Root-CA.
(101)Anschließend übermittelt der Bevollmächtigte der Root-CA sein Antragsformular (mit dem „Fingerprint“ (Fingerabdruck) des selbstsignierten Zertifikats), die amtliche ID und einen Nachweis seiner Berechtigung an die CPOC/den TLM. Das selbstsignierte Zertifikat wird der CPOC/dem TLM elektronisch zugestellt. CPOC/TLM überprüfen alle Unterlagen und das selbstsignierte Zertifikat.
(102)Verlaufen die Überprüfungen positiv, fügt der TLM das Zertifikat der Root-CA auf der Grundlage der Benachrichtigung von der CPA (Abläufe 1 und 2) der ECTL hinzu. Der detaillierte Prozess wird in der CPS des TLM beschrieben.
(103)Ein zusätzliches Verfahren zur Einholung einer Genehmigung der CPS und des Auditberichts einer Root-CA bei einer nationalen Einrichtungen bestimmter Länder sollte möglich sein.
4.1.2.2.TLM
(104)Nach seinem Audit kann sich der TLM bei der CPA anmelden (Enrollment). Der Vorgang des Enrollments basiert auf einem unterschriebenen, von Hand ausgefüllten Antragsformular, das der CPA (Ablauf 38) vom Bevollmächtigten des TLM physisch übergeben wird und mindestens die in den Abschnitten 3.2.2.2 und 3.2.3 genannten Angaben enthält.
(105)Das Antragsformular des TLM wird von dessen Bevollmächtigten unterzeichnet.
(106)Der TIM generiert zunächst sein selbstsigniertes Zertifikat und übermittelt es sicher an die CPA. Anschließend übergibt der TLM sein Antragsformular (mit dem Fingerabdruck des selbstsignierten Zertifikats), eine Kopie seiner CPS, eine amtliche ID, einen Nachweis der Bevollmächtigung und seinen Auditbericht der CPA (Ablauf 40). Die CPA prüft alle Dokumente und das selbstsignierte Zertifikat. Verläuft die Überprüfung sämtlicher Dokumente, des selbstsignierten Zertifikats und des Fingerabdrucks positiv, bestätigt die CPA den Enrollment-Prozess, indem sie dem TLM und der CPOC ihre Genehmigung übermittelt (Ablauf 39). Die vom TLM übermittelten Antragsinformationen werden von der CPA gespeichert. Anschließend wird das TLM-Zertifikat über die CPOC ausgestellt.
4.1.2.3.EA und AA
(107)Im Zuge des Enrollment-Prozesses übermitteln die EA/AA der entsprechenden Root-CA die maßgeblichen Dokumente (z. B. die CPS und den Auditbericht) zur Genehmigung (Ablauf 27/28). Im Falle einer positiven Prüfung der Unterlagen erteilt die Root-CA den entsprechenden Sub-CA die Genehmigung (Ablauf 29/30). Die Sub-CA (EA oder AA) übermitteln anschließend ihren signierten Antrag elektronisch und stellen ihr Antragsformular (gemäß Abschnitt 3.2.2.1), den Bevollmächtigungsnachweis und das ID-Dokument der entsprechenden Root-CA physisch zu. Die Root-CA überprüft den Antrag und die eingegangenen Dokumente (Antragsformular mit dem Fingerabdruck, d.h. dem SHA 256 hashvalue des Antrags der Sub-CA, den Bevollmächtigungsnachweis und das ID-Dokument). Führen alle Prüfungen zu einem positiven Ergebnis, stellt die Root-CA das entsprechende Sub-CA-Zertifikat aus. Ausführliche Informationen darüber, wie ein erstmaliger Antrag erfolgt, wird in der spezifischen CPS beschrieben.
(108)Der Bevollmächtigte der Sub-CA fügt dem Antragsformular der Sub-CA an die Root-CA zusätzlich eine Kopie der CPS bei.
(109)Ein akkreditierter PKI-Prüfer erhält die Informationen zur Prüfung gemäß Abschnitt 8.
(110)Befindet sich eine Sub-CA im Besitz eines anderen Teilnehmers als des Teilnehmers, der Eigentümer der Root-CA ist, unterzeichnet der Teilnehmer der Sub-CA vor der Ausstellung eines Antrags auf ein Sub-CA-Zertifikat einen Vertrag über den Dienst der Root-CA.
4.1.2.4.C-ITS-Station
(111)Die erstmalige Registrierung der Subjekte von Endteilnehmern (C-ITS-Stationen) wird vom verantwortlichen Abonnenten (Hersteller/Betreiber) bei der EA durchgeführt (Abläufe 33 und 35) und erfolgt nach der erfolgreichen Authentifizierung der Organisation des Abonnenten und eines seiner Vertreter gemäß den Abschnitten 3.2.2.4 und 3.2.5.2.
(112)Eine C-ITS-Station kann ein EC-Schlüsselpaar generieren (siehe Abschnitt 6.1) und einen signierten EC-Antrag gemäß [1] erstellen. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(113)Bei der Registrierung einer normalen C-ITS-Station (im Gegensatz zu einer speziellen mobilen oder ortsfesten C-ITS-Station) muss die EA prüfen, ob die Genehmigungen im erstmaligen Auftrag nicht für behördliche Zwecke bestimmt sind. Die Genehmigungen für behördliche Zwecke werden von den entsprechenden Mitgliedstaaten festgelegt. Das ausführliche Registrierungs- und Beantwortungsverfahren der EA bezüglich des Herstellers/Betreibers (Abläufe 33 und 35) wird in der entsprechenden CPS der EA dargelegt.
(114)Das Enrollment einer C-ITS-Station bei einer EA (Abschnitt 3.2.5.3) erfolgt gemäß [1] mittels Übermittlung ihres erstmaligen EC-Antrags.
(115)Nach der erstmaligen Registrierung durch einen authentifizierten Abonnentenvertreter genehmigt die EA die AT, die das Subjekt des Endteilnehmers (d. h. die C-ITS-Station) erwirken kann. Darüber hinaus wird jedem Endteilnehmer eine Vertrauenszusicherungsebene zugewiesen, die mit der Zertifizierung des Endteilnehmers nach einem der in Abschnitt 6.1.5.2 aufgeführten Schutzprofile zusammenhängt
(116)Reguläre Fahrzeuge müssen nur über eine C-ITS-Station verfügen, die bei einer EA registriert ist. Sonderfahrzeuge (wie Polizeiwagen und andere Sonderfahrzeuge mit besonderen Rechten) können bei einer zusätzlichen EA registriert werden oder verfügen über eine zusätzliche C-ITS-Station für Autorisierungen innerhalb des Geltungsbereichs ihres besonderen Zwecks. Die Fahrzeuge, für die eine solche Ausnahme gilt, werden von den zuständigen Mitgliedstaaten festgelegt. Die Genehmigungen für spezielle mobile und ortsfeste C-ITS-Stationen werden nur von den zuständigen Mitgliedstaaten erteilt. In den CPS der Root-CA oder Sub-CA, die Zertifikate für derartige Fahrzeuge in den betreffenden Mitgliedstaaten ausstellen, wird festgelegt, in welcher Weise der Zertifizierungsprozess für derartige Fahrzeuge zutrifft.
(117)Durchläuft der Abonnent gerade einen Prozess zur Migration einer C-ITS-Station von einer EA zu einer anderen EA, kann die C-ITS bei zwei (ähnlichen) EA registriert werden.
(118)Eine C-ITS-Station generiert ein AT-Schlüsselpaar (siehe Abschnitt 6.1) und erstellt einen signierten AT-Antrag gemäß [1]. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(119)Die C-ITS-Stationen senden einen Antrag auf Autorisierung an die URL der AA (Abläufe 32 und 26), indem sie mindestens die in Abschnitt 3.2.3.3 genannten, erforderlichen Informationen übermitteln. Die AA und EA validieren die Autorisierung für jeden Antrag gemäß den Abschnitten 3.2.6 und 4.2.2.5.
4.2.Bearbeitung von Zertifikatanträgen
4.2.1.Durchführung von Identifikations- und Authentifizierungsaufgaben
4.2.1.1.Identifizierung und Authentifizierung von Root-CA
(120)Der Bevollmächtigte der CPA ist für die Authentifizierung des Bevollmächtigten der Root-CA und die Genehmigung von dessen Enrollment-Prozess nach Abschnitt 3 zuständig.
4.2.1.2.Identifizierung und Authentifizierung des TLM
(121)Der Bevollmächtigte der CPA ist für die Authentifizierung des Bevollmächtigten des TLM und die Genehmigung von dessen im Rahmen des Enrollment-Prozesses nach Abschnitt 3 eingereichten Antragsformular nach Abschnitt 3 zuständig.
4.2.1.3.Identifizierung und Authentifizierung von EA und AA
(122)Die entsprechende Root-CA ist für die Authentifizierung des Bevollmächtigten der EA/AA und die Genehmigung von dessen im Rahmen des Enrollment-Prozesses eingereichten Antragsformular nach Abschnitt 3 zuständig.
(123)Die Root-CA bestätigt die positive Validierung des Antragsformulars bei der EA/AA. Die EA/AA kann anschließend einen Antrag auf Erteilung eines Zertifikats an die Root-CA richten (Ablauf 21/24), die Zertifikate für die entsprechende EA/AA ausstellt (Ablauf 18/19).
4.2.1.4.Identifizierung und Authentifizierung des EE-Abonnenten
(124)Bevor eine C-ITS-Station einen Antrag auf Ausstellung eines EC-Zertifikats stellen kann, muss der EE-Abonnent der EA die Angaben zur Kennung der C-ITS-Station sicher übermitteln (Ablauf 33). Die EA prüft den Antrag und trägt im Fall einer positiv verlaufenen Überprüfung die Angaben zur C-ITS-Station in ihre Datenbank ein und bestätigt dies dem EE-Abonnenten gegenüber (Ablauf 35). Dieser Vorgang wird für jede C-ITS-Station nur einmal durch den Hersteller oder Betreiber durchgeführt. Sobald eine C-ITS-Station bei einer EA registriert wird, kann sie jeweils ein einzelnes, von ihr benötigtes EC-Zertifikat beantragen (Ablauf 31). Die EA authentifiziert und verifiziert, ob die Angaben im EG-Zertifikatantrag für die betreffende C-ITS-Station gültig sind.
4.2.1.5.Berechtigungstickets
(125)Im Zuge von Autorisierungsanträgen (Ablauf 32) nach [1] muss die AA die EA authentifizieren, von der die C-ITS-Station ihren Enrollment-Berechtigungsnachweis (EC) erhalten hat. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist. Ist die AA nicht in der Lage, die EA zu authentifizieren, wird der Antrag abgelehnt (Ablauf 26). Es gilt die Anforderung, dass sich das EA-Zertifikat zur Authentifizierung der EA und zur Verifizierung ihrer Antworten im Besitz der AA befinden muss (Abläufe 25 und 23, Abschnitt 3.2.5.3).
(126)Die EA authentifiziert die C-ITS-Station, die ein Berechtigungsticket (AT) anfordert, indem sie deren EC verifiziert (Abläufe 25 und 23).
4.2.2.Genehmigung oder Ablehnung von Zertifikatanträgen
4.2.2.1.Genehmigung oder Ablehnung von Root-CA-Zertifikaten
(127)Der TLM trägt im Einklang mit der Genehmigung der CPA die Root-CA-Zertifikate in die ECTL ein bzw. entfernt sie daraus (Ablauf 1/2).
(128)Der TLM sollte nach dem Empfang der Genehmigung durch die CPA (Ablauf 1) die Signatur, die Informationen und die Verschlüsselung der Root-CA-Zertifikate verifizieren. Nach positiv verlaufener Validierung und Genehmigung durch die CPA setzt der TLM das entsprechende Wurzelzertifikat auf die ECTL und benachrichtigt die CPA (Ablauf 5).
4.2.2.2.Genehmigung oder Ablehnung von TLM-Zertifikaten
(129)Die CPA ist für die Genehmigung oder Ablehnung von TLM-Zertifikaten zuständig.
4.2.2.3.Genehmigung oder Ablehnung von EA- und AA-Zertifikaten
(130)Die Root-CA überprüft die Zertifikatanträge der Sub-CA (Ablauf 21/24) und die maßgeblichen (von einem akkreditierten PKI-Prüfer herausgegebenen) Berichte (Ablauf 36, Abschnitt 8), sobald sie diese von den entsprechenden Sub-CA der Root-CA erhalten hat. Führt die Prüfung des Antrags zu einem positiven Ergebnis, stellt die entsprechende Root-CA der antragstellenden EA/AA ein Zertifikat aus (Ablauf 18/19); andernfalls wird der Antrag abgelehnt, und der EA/AA wird kein Zertifikat ausgestellt.
4.2.2.4.Genehmigung oder Ablehnung von EC
(131)Die EA überprüft und validiert EC-Anträge im Einklang mit den Abschnitten 3.2.3.2 und 3.2.5.3.
(132)Ist der Zertifikatantrag nach [1] korrekt und gültig, generiert die EA das beantragte Zertifikat.
(133)Ist der Zertifikatantrag nicht gültig, lehnt die EA (Enrollment-Stelle) ihn ab und übermittelt eine Antwort, in der sie den Grund für die Ablehnung gemäß [1] darlegt. Wünscht eine C-ITS-Station weiterhin einen EC, kann sie einen neuen Zertifikatantrag stellen. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
4.2.2.5.Genehmigung oder Ablehnung von AT
(134)Der Zertifikatantrag wird durch die EA geprüft. Die AA kommuniziert zur Validierung des Antrags mit der EA (Ablauf 25). Die Enrollment-Stelle (EA) authentifiziert die antragstellende C-ITS-Station und validiert, ob sie zum Empfang des beantragten Berechtigungstickets (AT) berechtigt ist, dabei folgt sie der Certificate Policy (CP) (z. B. mittels Prüfung des Sperrungsstatus und Validierung der zeitlichen/regionalen Gültigkeit des Zertifikats, der Zulassungen, der Vertrauenszusicherungsebene usw.). Die EA sendet eine Validierungsantwort (Ablauf 23); ist die Antwort positiv, generiert die AA das beantragte Zertifikat und übermittelt es an die C-ITS-Station. Ist der AT-Antrag nicht korrekt oder ist die Validierungsantwort der EA negativ, lehnt die AA den Antrag ab. Benötigt eine C-ITS-Station weiterhin ein Berechtigungsticket (AT), stellt sie einen neuen Antrag auf Autorisierung.
4.2.3.Bearbeitungsdauer von Zertifikatanträgen
4.2.3.1.Antrag auf Root-CA-Zertifikat
(135)Die Bearbeitungszeit für den Identifizierungs- und Authentisierungsprozess eines Zertifikatantrags liegt innerhalb eines Arbeitstags und unterliegt einer maximalen Frist, die in der Erklärung zum Zertifizierungsbetrieb (CPS) der Root-CA festgelegt ist.
4.2.3.2.Antrag auf TLM-Zertifikat
(136)Für die Bearbeitung des TLM-Zertifikatantrags gilt eine in der CPS des TLM festgelegte Höchstdauer.
4.2.3.3.Antrag auf EA- und AA-Zertifikate
(137)Die Bearbeitungszeit für den Identifizierungs- und Authentisierungsprozess eines Zertifikatantrags liegt im Einklang mi der Vereinbarung und dem Vertrag zwischen der Root-CA von Mitgliedstaat/privater Organisation und der Sub-CA innerhalb eines Arbeitstags. Für die Bearbeitung von Anträgen auf Sub-CA-Zertifikate gilt eine maximale Frist, die in der Erklärung zum Zertifizierungsbetrieb (CPS) der Sub-CA festgelegt ist.
4.2.3.4.EC-Antrag
(138)Für die Bearbeitung von EC-Anträgen (Enrollment-Berechtigungsnachweis) gilt eine maximale Frist, die in der Erklärung zum Zertifizierungsbetrieb (CPS) der Enrollment-Stelle (EA) festgelegt ist.
4.2.3.5.AT-Antrag
(139)Für die Bearbeitung von AT-Anträgen (Berechtigungsticket) gilt eine maximale Frist, die in der Erklärung zum Zertifizierungsbetrieb (CPS) der AA festgelegt ist.
4.3.Zertifikatsausstellung
4.3.1.Maßnahmen der Wurzelzertifizierungsstelle während der Ausstellung von Zertifikaten
4.3.1.1.Ausstellung von Zertifikaten für die Root-CA
(140)Root-CA stellen ihre eigenen, selbstsignierten Root-CA-Zertifikate, Link-Zertifikate, Sub-CA-Zertifikate und CRL aus.
(141)Nach der Genehmigung durch die CPA (Ablauf 4) sendet die Root-CA ihr Zertifikat über die CPOC zur Aufnahme in die ECTL an dem TLM (Abläufe 11 und 8) (siehe Abschnitt 4.1.2.1). Der TLM prüft, ob die CPA das Zertifikat genehmigt hat (Ablauf 1).
4.3.1.2.Ausstellung von TLM Zertifikaten
(142)Der TLM stellt seine eigenen selbstsignierten TLM- und Link-Zertifikate aus und sendet sie an die CPOC (Ablauf 6).
4.3.1.3.Ausstellung von EA- und AA-Zertifikaten
(143)Die Sub-CA generieren einen signierten Zertifikatantrag und übermitteln ihn an die entsprechende Root-CA (Abläufe 21 und 24). Die Root-CA überprüft den Antrag und stellt der antragstellenden Sub-CA gemäß [5] sobald wie möglich, d. h. den in der CPS für die übliche betriebliche Praxis festgelegten Bestimmungen entsprechend, spätestens aber fünf Arbeitstage nach Eingang des Antrags, ein Zertifikat aus.
(144)Die Root-CA aktualisiert die Datenablage, die die Zertifikate der Sub-CA enthält.
4.3.1.4.Ausstellung von EC
(145)Die C-ITS-Station übermittelt der EA einen Antrag auf einen Enrollment-Berechtigungsnachweis (EC) gemäß [1]. Die EA authentifiziert und überprüft, ob die im Zertifikatantrag enthaltenen Informationen für eine C-ITS-Station gültig sind. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(146)Im Falle einer positiven Validierung stellt die EA ein der Registrierung der C-ITS-Station (siehe 4.2.1.4) entsprechendes Zertifikat aus und sendet es mittels einer EC-Antwortnachricht nach [1] an die C-ITS-Station. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(147)Besteht keine Registrierung, generiert die EA einen Fehlercode und sendet ihn mittels einer EC-Antwortnachricht nach [1] an die C-ITS-Station. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(148)EC-Anträge und EC-Antworten werden zur Wahrung der Vertraulichkeit verschlüsselt und zur Gewährleistung der Authentifizierung und Integrität signiert.
4.3.1.5.Ausstellung von AT
(149)Die C-ITS-Station übermittelt der AA eine Nachricht mit einem Antrag auf ein Berechtigungsticket (AT) gemäß [1]. Die AA übermittelt der EA ein AT-Validierungsersuchen gemäß [1]. Die EA übermittelt der AA eine Antwort zur AT-Validierung. Ist die Antwort positiv, generiert die AA ein Berechtigungsticket (AT) und sendet es mittels einer AT-Antwortnachricht nach [1] an die C-ITS-Station. Ist die Antwort negativ, generiert die AA einen Fehlercode und sendet ihn mittels einer AT-Antwortnachricht nach [1] an die C-ITS-Station. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(150)AT-Anträge und AT-Antworten werden zur Wahrung der Vertraulichkeit verschlüsselt (nur bei mobilen C-ITS-Stationen erforderlich) und zur Gewährleistung der Authentifizierung und Integrität signiert.
4.3.2.Benachrichtigung des Abonnenten über die Ausstellung von Zertifikaten durch die Zertifizierungsstelle
Entfällt.
4.4.Annahme der Zertifikate
4.4.1.Durchführung der Annahme von Zertifikaten
4.4.1.1.Root-CA
Entfällt.
4.4.1.2.TLM
Entfällt.
4.4.1.3.EA und AA
(151)Die EA/AA überprüft die Art des Zertifikats, die Signatur und die im empfangenen Zertifikat enthaltenen Angaben. Die EA/AA verwirft alle EA/AA-Zertifikate, die nicht als korrekt verifiziert wurden, und stellt einen neuen Antrag.
4.4.1.4.C-ITS-Station
(152)Die C-ITS-Station überprüft die EC/AT-Antwort, die sie von der EA/AA erhalten hat, anhand ihres ursprünglichen Antrags unter Einschluss der Signatur und der Zertifikatkette. Sie verwirft alle EC/AT-Antworten, die nicht als korrekt verifiziert wurden. In diesen Fällen sollte sie einen neuen EC/AT-Antrag übermittelt.
4.4.2.Veröffentlichung des Zertifikats
(153)TLM-Zertifikate und die zugehörigen Link-Zertifikate werden allen Teilnehmern über die CPOC zur Verfügung gestellt.
(154)Root-CA-Zertifikate werden vom CPOC über die ECTL veröffentlicht, die vom TLM signiert wird.
(155)Die Zertifikate von Sub-CA (EA und AA) werden von der Root-CA veröffentlicht.
(156)EC und AT werden nicht veröffentlicht.
4.4.3.Benachrichtigung über die Zertifikatsausstellung
Es gibt keine Benachrichtigungen über die Ausstellung.
4.5.Verwendung des Schlüsselpaars und des Zertifikats
4.5.1.Nutzung des privaten Schlüssels und des Zertifikats
4.5.1.1.Nutzung privater Schlüssel und Zertifikate für TLM
(157)Der TLM nutzt seine privaten Schlüssel zur Signierung seiner eigenen (TLM- und Link-) Zertifikate und der ECTL.
(158)Das TLM-Zertifikat wird von den PKI-Teilnehmern für die Überprüfung des ECTL und die Authentifizierung des TLM verwendet.
4.5.1.2.Nutzung privater Schlüssel und Zertifikate für Root-CA
(159)Root-CA nutzen ihre privaten Schlüssel zur Signierung ihrer eigenen Zertifikate, CRL, Link-Zertifikate und der EA/AA-Zertifikate.
(160)Root-CA-Zertifikate werden von den PKI-Teilnehmern für die Überprüfung der zugehörigen AA und EA-Zertifikate, der Link-Zertifikate und der CRL verwendet.
4.5.1.3.Nutzung privater Schlüssel und Zertifikats für EA und AA
(161)EA nutzen ihre privaten Schlüssel zur Signierung von EC und Entschlüsselung von Enrollment-Anträgen.
(162)EA-Zertifikate werden zur Verifizierung der Signatur zugehöriger EC und zur Verschlüsselung von EC- und AT-Anträgen durch EE gemäß Definition in [1]verwendet.
(163)AA nutzen ihre privaten Schlüssel zur Signierung von AT und zur Entschlüsselung von Anträgen auf AT (Berechtigungstickets).
(164)AA-Zertifikate werden von Endteilnehmern (EE) zur Verifizierung zugehöriger AT und zur Verschlüsselung von AT-Anträgen gemäß Definition in [1] verwendet.
4.5.1.4.Nutzung privater Schlüssel und Zertifikate für Endteilnehmer
(165)Endteilnehmer (EE) nutzen den einem gültigen EC (Enrollment-Berechtigungsnachweis) entsprechenden privaten Schlüssel zur Signierung eines neuen Enrollment-Antrags gemäß Definition in [1]. Der neue private Schlüssel wird zum Aufbau der inneren Signatur im Antrag verwendet, um den Besitz des privaten Schlüssels zu belegen, der dem neuen öffentlichen EC-Schlüssel entspricht.
(166)Endteilnehmer (EE) nutzen den einem gültigen EC (Enrollment-Berechtigungsnachweis) entsprechenden privaten Schlüssel zur Signierung eines Autorisierungsantrags gemäß Definition in [1]. Der dem neuen AT (Berechtigungsticket) entsprechende private Schlüssel wird zum Aufbau der inneren Signatur im Antrag verwendet, um den Besitz des privaten Schlüssels zu belegen, der dem neuen öffentlichen AT-Schlüssel entspricht.
(167)Endteilnehmer (EE) nutzen den einem ordnungsgemäßen AT entsprechenden privaten Schlüssel zum Signieren von C-ITS-Nachrichten gemäß Definition in [5].
4.5.2.Nutzung öffentlicher Schlüssel und Zertifikate durch Vertrauende Dritte
(168)Vertrauende Dritte nutzen den vertrauenswürdigen Zertifizierungspfad und die zugehörigen öffentlichen Schlüssel zu den in den Zertifikaten genannten Zwecken und zur Authentifizierung der vertrauenswürdigen gemeinsamen Identität von EC und AT.
(169)Root-CA- EA- und AA-Zertifikate sowie EC und AT dürfen ohne eine Vorabprüfung durch einen Vertrauenden Dritten nicht verwendet werden.
4.6.Zertifikatserneuerung
Nicht zulässig.
4.7.Schlüsselerneuerung von Zertifikaten (Re-Key)
4.7.1.Umstände für eine Schlüsselerneuerung
(170)Schlüsselerneuerungen von Zertifikaten werden bearbeitet, wenn ein Zertifikat das Ende seiner Laufzeit erreicht oder wenn bei einem privaten Schlüssel die betriebliche Nutzung endet, das Vertrauensverhältnis mit der Wurzelzertifizierungsstelle (CA) aber noch besteht. Ein neues Schlüsselpaar und das entsprechende Zertifikat werden in allen Fällen generiert und ausgestellt.
4.7.2.Wer darf eine Schlüsselerneuerung beantragen?
4.7.2.1.Root-CA
(171)Die Root-CA beantragt keine Schlüsselerneuerung. Der Schlüsselerneuerungsprozess stellt für die Root-CA einen internen Vorgang dar, weil ihr Zertifikat von ihr selbst signiert wird. Die Root-CA führt Schlüsselerneuerungen entweder mit Link-Zertifikaten oder Neuausstellungen durch (siehe Abschnitt 4.3.1.1).
4.7.2.2.TLM
(172)Der TLM beantragt keine Schlüsselerneuerung. Der Schlüsselerneuerungsprozess stellt für den TLM einen internen Vorgang dar, weil das TLM-Zertifikat von ihm selbst signiert wird.
4.7.2.3.EA und AA
(173)Der Zertifikatantrag von Sub-CA muss rechtzeitig eingereicht werden, um sicher sein zu können, dass ein neues Sub-CA-Zertifikat und ein funktionsfähiges Sub-CA-Schlüsselpaar vorliegt, bevor der aktuelle private Schlüssel der Sub-CA abläuft. Hinsichtlich des Datums der Einreichung muss auch die für die Genehmigung benötigte Zeit berücksichtigt werden.
4.7.2.4.C-ITS-Station
Entfällt.
4.7.3.Schlüsselerneuerungsprozess
4.7.3.1.TLM-Zertifikat
(174)Der TLM entscheidet auf der Grundlage der in den Abschnitten 6.1 und 7.2 aufgeführten Anforderungen über eine Schlüsselerneuerung. Der Prozess wird in seiner Erklärung zum Zertifizierungsbetrieb (CPS) ausführlich beschrieben.
(175)Der TLM führt den Prozess der Schlüsselerneuerung so rechtzeitig durch, dass die Verteilung des neuen TLM-Zertifikats und des Link-Zertifikats an alle Teilnehmer möglich ist, bevor das derzeitige TLM-Zertifikat abläuft.
(176)Der TLM verwendet für die Schlüsselerneuerung und zur Gewährleistung des Vertrauensverhältnisses des neuen, selbstsignierten Zertifikats Link-Zertifikate. Das neu generierte TLM- und Link-Zertifikat wird an die zentrale Kontaktstelle (CPOC) übertragen.
4.7.3.2.Root-CA-Zertifikat
(177)Die Root-CA entscheidet auf der Grundlage der in den Abschnitten 6.15 und 7.2 aufgeführten Anforderungen über eine Schlüsselerneuerung. Der Prozess in seinen Einzelheiten sollte in ihrer Erklärung zum Zertifizierungsbetrieb (CPS) festgelegt werden.
(178)Die Root-CA führt den Schlüsselerneuerungsprozess so rechtzeitig (bevor das Root-CA-Zertifikat abläuft) durch, dass das neue Zertifikat in die ECTL aufgenommen werden kann, bevor das Zertifikat der Root-CA gültig wird (siehe Abschnitt 5.6.2). Der Schlüsselerneuerungsprozess erfolgt entweder über Link-Zertifikate oder wie ein erstmaliger Antrag.
4.7.3.3.EA- und AA-Zertifikate
(179)Die EA oder AA beantragt ein neues Zertifikat wie folgt:
|
Schritt
|
Angabe
|
Antrag auf Schlüsselerneuerung
|
|
1
|
Generierung eines Schlüsselpaars
|
Die Sub-CA (EA und AA) generieren gemäß Abschnitt 6.1 neue Schlüsselpaare.
|
|
2
|
Generierung des Zertifikatantrags und der inneren Signatur
|
Die Sub-CA generiert aus dem neu generierten öffentlichen Schlüssel einen Zertifikatantrag und berücksichtigt dabei das Benennungsschema (subject_info) in Abschnitt 3, den Signaturalgorithmus, die SSP und optionale zusätzliche Parameter; ferner generiert sie mit dem entsprechenden neuen privaten Schlüssel die innere Signatur. Ist ein Verschlüsselungsschlüssel erforderlich, muss die Sub-CA auch den Besitz des entsprechenden privaten Entschlüsselungsschlüssels nachweisen.
|
|
3
|
Äußere Signatur generieren
|
Der gesamte Antrag wird zur Gewährleistung der Authentizität des signierten Antrags mit dem derzeit gültigen privaten Schlüssel signiert.
|
|
4
|
Antrag an Root-CA versenden
|
Der unterzeichnete Antrag wird bei der entsprechenden Root-CA eingereicht.
|
|
5
|
Prüfung des Antrags
|
Die entsprechende Root-CA überprüft die Integrität und Authentizität (Echtheit) des Antrags. Zunächst überprüft sie die äußere Signatur. Verläuft die Prüfung positiv, überprüft sie die innere Signatur. Liegt ein Nachweis für den Besitz des privaten Entschlüsselungsschlüssels vor, überprüft sie auch diesen Nachweis.
|
|
6
|
Antrag annehmen oder ablehnen
|
Wenn alle Kontrollen zu einem positiven Ergebnis führen, nimmt die Root-CA den Antrag an; andernfalls wird er abgelehnt.
|
|
7
|
Zertifikat generieren und ausstellen
|
Die Root-CA generiert ein neues Zertifikat und verteilt es an die antragstellenden Sub-CA.
|
|
8
|
Antwort senden
|
Die Sub-CA sendet der Root-CA eine Statusmeldung (bezüglich dessen, ob das Zertifikat eingegangen ist oder nicht).
|
Tabelle 3: Schlüsselerneuerungsprozess für EA und AA
(180)Bei einer automatischen Schlüsselerneuerung für Sub-CA stellt die Root-CA sicher, dass der Antragsteller tatsächlich im Besitz seines privaten Schlüssels ist. Es werden geeignete Protokolle für den Besitznachweis für private Entschlüsselungsschlüssel angewendet, beispielsweise die in RFC 4210 und 4211 definierten Protokolle. Für private Signaturschlüssel sollte die innere Signatur verwendet werden.
4.7.3.4.C-ITS-Stationszertifikate
Trifft für Berechtigungstickets (AT) nicht zu.
4.8.Änderung von Zertifikaten
Nicht zulässig.
4.9.Sperrung und Suspendierung von Zertifikaten
Siehe Abschnitt 7.
4.10.Statusauskunftsdienste von Zertifikaten
4.10.1.Betriebseigenschaften
Entfällt.
4.10.2.Verfügbarkeit des Dienstes
Entfällt.
4.10.3.Optionale Funktionen
Entfällt.
4.11.Beendigung des Vertragsverhältnisses
Entfällt.
4.12.Schlüsselhinterlegung und Wiederherstellung
4.12.1.Teilnehmer
4.12.1.1.Welches Schlüsselpaar kann hinterlegt werden?
Entfällt.
4.12.1.2.Wer kann einen Wiederherstellungsantrag stellen?
Entfällt.
4.12.1.3.Wiederherstellungsprozess und Verantwortlichkeiten
Entfällt.
4.12.1.4.Identifizierung und Authentifizierung
Entfällt.
4.12.1.5.Genehmigung oder Ablehnung von Wiederherstellungsanträgen
Entfällt.
4.12.1.6.KEA und KRA bei der Wiederherstellung von Schlüsselpaaren
Entfällt.
4.12.1.7.Verfügbarkeit von KEA und KRA
Entfällt.
4.12.2.Sitzungsschlüsselkapselung und Richtlinien und Praktiken für die Wiederherstellung
Entfällt.
5.Einrichtungs-, Verwaltungs- und Betriebskontrollen
(181)Die PKI besteht aus der Root-CA, den EA/AA, der CPOC und dem TLM, einschließlich ihrer IKT-Komponenten (z. B. Netze und Server).
(182)In diesem Abschnitt wird die für einen Bestandteil der PKI verantwortliche Stelle durch das Element selbst bestimmt. Mit anderen Worten: der Satz „die CA ist für die Durchführung der Prüfung zuständig“ ist gleichbedeutend mit „zuständig für die Durchführung ... ist die Stelle oder das Personal, die oder das die CA verwaltet“.
(183)Der Begriff „Elemente des C-ITS Trust Models“ umfasst die Root-CA, den TLM, die EA/AA, die CPOC und das sichere Netz.
5.1.Physische Kontrollen
(184)Alle Vorgänge im Rahmen des C-ITS Trust Models werden in einem physisch geschützten Umfeld durchgeführt, das vor der unbefugten Nutzung sensibler Informationen und Systeme, dem Zugang dazu oder vor deren Offenlegung abschreckt, diese verhindert und aufdeckt. Elemente des C-ITS Trust Models nutzen physische Sicherheitskontrollen im Einklang mit ISO 27001 und ISO 27005.
(185)Die Stellen, die die Elemente für die C-ITS-Vertrauenselemente verwalten, beschreiben die physischen, verfahrenstechnischen und personellen Sicherheitskontrollen in ihren CPS. Insbesondere müssen die CPS Informationen über den Standort und die Bauweise der Einrichtungen und ihre physischen Sicherheitskontrollen umfassen, die den kontrollierten Zugang zu allen Räumen gewährleisten, die in Einrichtungen der für das C-ITS Trust Model zuständigen Stellen genutzt werden.
5.1.1.Standort und Bauweise
5.1.1.1.Root-CA, CPOC, TLM
(186)Standort und Bauweise der Einrichtung, in der die Geräte und Daten von Root-CA, CPOC und TLM untergebracht sind (HSM, Aktivierungsdaten, Backup von Schlüsselpaaren, Rechner, Log, Skript des Schlüsselgenerierungsverfahrens (Key Ceremony), Zertifikatanträge usw.), entsprechen Einrichtungen, die für die Unterbringung sensibler Informationen von hohem Wert genutzt werden. Die Root-CA wird in einem speziell dafür bestimmten Bereich betrieben, der von physischen Bereichen anderer PKI-Komponenten getrennt ist.
(187)Die Root-CA, die CPOC und der TLM führen Richtlinien und Verfahren zur Sicherstellung dessen ein, dass in der physischen Umgebung, in der die Geräte der Root-CA untergebracht sind, ein hohes Maß an Sicherheit gewährleistet ist; damit soll garantiert werden, dass
·es von Netzen außerhalb des Trust Models getrennt ist;
·es in eine Reihe von (mindestens zwei) physischen Perimetern mit schrittweise höheren Sicherheitsstufen unterteilt ist;
·sensible Daten (HSM, Schlüsselpaar-Backup, Aktivierungsdaten usw.) in einem dafür vorgesehenen Safe in einem speziell dafür bestimmten Bereich unter mehrfacher Zugangskontrolle gespeichert werden.
(188)Die eingesetzten Sicherheitstechniken müssen darauf ausgelegt sein, gegen eine große Anzahl und Kombination verschiedener Angriffsformen Widerstand zu leisten. Die verwendeten Mechanismen müssen mindestens Folgendes umfassen:
·perimetrische Warnanlagen, Videoüberwachungssysteme, verstärkte Mauern und Bewegungsmelder;
·zwei-Faktoren-Authentifizierung (z. B. Smartcard und PIN) für jede Person und einen Zugangsausweis zum Betreten und Verlassen der Einrichtungen der Root-CA und des sicheren, physisch abgesicherten Bereichs.
(189)Die Root-CA, die CPOC und der TLM setzen befugtes Personal zur ständigen Überwachung (7x24x365-Basis) der Einrichtung ein, in der Geräte untergebracht sind. Das Betriebsumfeld (z. B. die physische Einrichtung) darf nie unbeaufsichtigt sein. Das Personal aus dem betrieblichen Umfeld darf nur dann Zutritt zu gesicherten Bereichen von Root-CA oder Sub-CA erhalten, wenn es dazu befugt ist.
5.1.1.2.EA/AA
(190)Es gelten die gleichen Bestimmungen wie in Abschnitt 5.1.1.1.
5.1.2.Physischer Zugang
5.1.2.1.Root-CA, CPOC, TLM
(191)Geräte und Daten (HSM, Aktivierungsdaten, Backup von Schlüsselpaaren, Rechner, Logs, Skript des Schlüsselgenerierungsverfahrens (Key Ceremony), Zertifikatanträge usw.) sind stets vor unbefugtem Zugang zu schützen. Die Mechanismen für die physische Sicherheit der Geräte müssen mindestens:
·eine ständige manuelle oder elektronische Überwachung auf unbefugtes Eindringen leisten;
·sicherstellen, dass kein unbefugter Zugang zur Hardware und zu den Aktivierungsdaten zugelassen wird;
·sicherstellen, dass alle transportablen Medien und Dokumente, die sensible Informationen in Klartext enthalten, in einem sicheren Behältnis aufbewahrt werden;
·sicherstellen, dass jede Person, die sichere Bereiche betritt und über keine dauernde Befugnis verfügt, stets unter der Aufsicht durch einen bevollmächtigen Mitarbeiter der Einrichtungen von Root-CA, CPOC oder TLM steht;
·sicherstellen, dass ein Zugangsprotokoll geführt und in regelmäßigen Abständen überprüft wird;
·mindestens zwei Ebenen schrittweise höherer Sicherheitsstufen bereitstellen, z. B. auf den Ebenen Grundstücksgrenze, Gebäude und Betriebsraum;
·zwei Vertrauensfunktionen erfüllende, physische Zugangskontrollen für das kryptografische Hardware-Sicherheitsmodul (HSM) und die Aktivierungsdaten vorschreiben.
(192)Am Gebäude, in dem Geräte untergerbacht sind, ist eine Sicherheitskontrolle durchzuführen, wenn dieses unbeaufsichtigt gelassen werden soll. Bei der Kontrolle wird zumindest überprüft, ob
·sich die Geräte in einem Zustand befinden, der für die derzeitige Betriebsweise geeignet ist;
·bei Offline-Komponenten alle Geräte abgeschaltet sind;
·Sicherheitsbehältnisse (manipulationssicherer Umschlag, Safe usw.) ordnungsgemäß versiegelt sind;
·die Systeme der physischen Sicherheit (z. B. Türschlösser, Lüftungsabdeckungen, Strom) ordnungsgemäß funktionieren;
·der Bereich gegen unbefugten Zutritt gesichert ist.
(193)Transportable kryptografische Module müssen vor der Lagerung deaktiviert werden. Befinden sich diese Module nicht im Einsatz, werden sie und die zugehörigen Zugangs- oder Aktivierungsdaten in einem Safe untergebracht. Aktivierungsdaten werden entweder auswendig gelernt oder in einer Weise aufgezeichnet und gespeichert, die der dem kryptografischen Modul zugeordneten Sicherheitsstufe entspricht. Sie werden nicht zusammen mit dem kryptografischen Modul gespeichert, um zu verhindern, dass nur eine Person Zugang zum privaten Schlüssel hat.
(194)Personen oder Gruppen mit Vertrauensfunktionen wird ausdrücklich die Verantwortung für die Durchführung solcher Kontrollen übertragen. Ist eine Personengruppe verantwortlich, so ist ein Protokoll zu führen, in dem die Person genannt wird, die die jeweilige Kontrolle ausführt. Ist die Einrichtung nicht ständig besetzt, zeichnet die Person, die die Einrichtung als letzte verlässt, einen Abmeldebogen ab, in dem Datum und Uhrzeit angegeben werden und bestätigt wird, dass alle erforderlichen physischen Schutzmechanismen vorhanden und aktiviert sind.
5.1.2.2.EA/AA
(195)Es gelten die gleichen Bestimmungen wie in Abschnitt 5.1.2.1.
5.1.3.Stromversorgung und Klimatisierung
(196)Sichere Einrichtungen für die Elemente des C-ITS Trust Models (Root-CA, CPOC, TLM, EA und AA) müssen mit einem zuverlässigen Zugang zu elektrischer Energie ausgestattet sein, damit auch bei vollständigem oder kurzzeitigem Stromausfall der Betrieb sichergestellt werden kann. Für den Fall eines Ausfalls der externen Stromversorgung und für eine reibungslose Abschaltung der Geräte des C-ITS Trust Models bei Energiemangel sind primäre Versorgungsanlagen und Backup-Installationen erforderlich. Einrichtungen des C-ITS Trust Models sind mit Heizungs-/Belüftungs-/Klimatisierungsanlagen auszustatten, mit denen die Temperatur und relative Luftfeuchtigkeit der Geräte des C-ITS Trust Models im Rahmen der Betriebsbedingungen gehalten werden können. Die Erklärung zum Zertifizierungsbetrieb (CPS) des Elements des C-ITS Trust Models enthält eine ausführliche Beschreibung des Plans und der Prozesse zur Umsetzung dieser Anforderungen.
5.1.4.Gefährdungen durch Wasser
(197)Sichere Einrichtungen für die Elemente des C-ITS Trust Models (Root-CA, CPOC, TLM, EA und AA) sollten so geschützt werden, dass die Auswirkungen durch Wassereinwirkung so gering wie möglich gehalten werden. Aus diesem Grund müssen Wasser- und Abflussleitungen vermieden werden. Die Erklärung zum Zertifizierungsbetrieb (CPS) eines Elements des C-ITS Trust Models enthält eine ausführliche Beschreibung des Plans und der Prozesse zur Umsetzung dieser Anforderungen.
5.1.5.Brandschutz
(198)Um eine schädigende Belastung durch Flammen oder Rauch zu vermeiden, werden die sicheren Einrichtungen von Elementen des C-ITS Trust Models (Root-CA, CPOC, TLM, EA und AA) entsprechend gebaut und ausgestattet und es werden Verfahren zur Bewältigung von Bedrohungen im Zusammenhang mit Feuer umgesetzt. Die Speichermedien sollten in geeigneten Behältern gegen Feuer geschützt werden.
(199)Die Elemente des C-ITS Trust Models schützen physische Medien, die Backups kritischer Systemdaten oder andere sensible Informationen enthalten, vor Umweltgefahren sowie der unbefugten Nutzung solcher Medien, dem Zugang zu ihnen oder deren Offenlegung. Die Erklärung zum Zertifizierungsbetrieb (CPS) des Elements des C-ITS Trust Models enthält eine ausführliche Beschreibung des Plans und der Prozesse zur Umsetzung dieser Anforderungen.
5.1.6.Medienmanagement
(200)Die im Rahmen des C-ITS Trust Models verwendeten Medien (Root-CA, CPOC, TLM, EA und AA) werden auf sichere Weise gehandhabt um sie vor Beschädigung, Diebstahl und unbefugtem Zugang zu schützen. Es werden Medienmanagementverfahren zum Schutz gegen Überalterung und Verschleiß von Medien während des Zeitraums, in dem Aufzeichnungen aufbewahrt werden müssen, umgesetzt.
(201)Sensible Daten werden vor dem Zugriff infolge einer Wiederverwendung von Speicherobjekten (z. B. gelöschten Dateien), durch die sensible Daten für unbefugt Nutzer zugänglich gemacht werden können, geschützt.
(202)Es wird ein Bestandsverzeichnis sämtlicher Informationsgüter geführt und es werden Anforderungen an den Schutz dieser Güter festgelegt, die im Einklang mit der Risikoanalyse stehen. Die Erklärung zum Zertifizierungsbetrieb (CPS) des Elements des C-ITS Trust Models enthält eine ausführliche Beschreibung des Plans und der Prozesse zur Umsetzung dieser Anforderungen.
5.1.7.Abfallentsorgung
(203)Die Elemente des C-ITS Trust Models (Root-CA, CPOC, TLM, EA und AA) führen Verfahren zur sicheren und irreversiblen Beseitigung von Abfällen (Papier, Medien oder andere Abfälle) durch, um die unbefugte Nutzung von Abfällen, die vertrauliche oder persönliche Informationen enthalten, sowie den unbefugten Zugang zu solchen Informationen oder deren Offenlegung zu verhindern. Alle Medien, die für die Speicherung sensibler Informationen wie Schlüsseln, Aktivierungsdaten oder Dateien verwendet werden, werden vor der Freigabe zur Entsorgung zerstört. Die Erklärung zum Zertifizierungsbetrieb (CPS) des Elements des C-ITS Trust Models enthält eine ausführliche Beschreibung des Plans und der Prozesse zur Umsetzung dieser Anforderungen.
5.1.8.Externe Sicherung
5.1.8.1.Root-CA, CPOC und TLM
(204)Nach einem Einsatz von Root-CA, CPOC und TLM sowie nach jeder Generierung neuer Schlüsselpaare werden vollständige Backups der Komponenten von Root-CA, CPOC und TLM erstellt, die für eine Wiederherstellung nach einem Systemausfall ausreichen. Es werden regelmäßig Sicherungskopien wesentlicher Unternehmensinformationen (Schlüsselpaar und CRL) sowie der Software erstellt. Es werden adäquate Backup-Einrichtungen bereitgestellt, damit eine Wiederherstellung aller wesentlichen Unternehmensinformationen und der Software nach einer Havarie oder einem Medienausfall sichergestellt ist. Back-up-Mechanismen für einzelne Systeme werden regelmäßig geprüft, um sicherzustellen, dass sie die Anforderungen des Plan zur Aufrechterhaltung des Geschäftsbetriebs erfüllen. Mindestens eine vollständige Backup-Kopie wird an einem externen Standort (Datenwiederherstellung im Falle eines Systemabsturzes, Disaster Recovery) gespeichert. Die Sicherungskopie wird an einem Ort mit physischen und verfahrenstechnischen Kontrollen gespeichert, die der des operativen PKI-Systems entsprechen.
(205)Die Backup-Daten unterliegen den gleichen Zugangsanforderungen wie die operativen Daten. Backup-Daten werden verschlüsselt und extern gespeichert. Bei einem vollständigen Datenverlust werden die Informationen, die erforderlich sind, um Root-CA, CPOC und TLM wieder in Betrieb zu setzen, vollständig aus den Backup-Daten wiederhergestellt.
(206)Privatschlüsselmaterial von Root-CA, CPOC und TLM darf nicht mit Hilfe von Standard-Backupmechanismen gesichert werden; stattdessen wird die Backup-Funktion des kryptografischen Moduls genutzt.
5.1.8.2.EA/AA
(207)Für diesen Abschnitt gelten die in Abschnitt 5.1.8.1 beschriebenen Prozesse.
5.2.Verfahrenskontrollen
In diesem Abschnitt werden die Aufgaben, die Pflichten und die Identifizierung des Personals beschrieben.
5.2.1.Vertrauensfunktionen
(208)Mitarbeiter, Auftragnehmer und Berater, denen eine Vertrauensfunktion zugewiesen wurde, gelten als „vertrauenswürdige Personen“. Personen, die die Anerkennung als vertrauenswürdige Personen anstreben, indem sie eine Vertrauensstellung beziehen, müssen die Screening-Anforderungen der vorliegenden Certificate Policy erfüllen.
(209)Vertrauenswürdige Personen haben Zugang zu Authentifizierungs- oder kryptografischen Operationen, die Folgendes wesentlich beeinflussen können:
·die Validierung von Informationen in Zertifikatanträgen;
·die Annahme, Ablehnung oder sonstige Bearbeitung von Zertifikatanträgen, Sperrungs- oder Erneuerungsanträgen;
·die Ausstellung oder die Sperrung von Zertifikaten unter Einschluss von Personal, das Zugang zu Beschränkungen unterliegenden Teilen der Datenablage oder zur Handhabung von Informationen über Abonnenten bzw. Anträgen hat.
(210)Zu den Vertrauensfunktionen gehören u. a.:
·der Kundenservice;
·die Systemadministration;
·ausgewiesene Technik (Designated Engineering);
·Führungskräfte, die mit der Verwaltung der Vertrauenswürdigkeit der Infrastruktur beauftragt sind.
(211)Die CA vermittelt in ihrer Erklärung zum Zertifizierungsbetrieb (CPS) klare Beschreibungen aller Vertrauensfunktionen.
5.2.2.Anzahl der pro Aufgabe erforderlichen Personen
(212)Die Elemente des C-ITS Trust Models richten zur Gewährleistung einer Aufgabentrennung auf der Grundlage von Vertrauensfunktionen strenge Kontrollverfahren ein, erhalten diese aufrecht und setzen sie durch; diese Verfahren stellen auch sicher, dass für die Durchführung sensibler Aufgaben mehrere vertrauenswürdige Personen erforderlich sind. Die Elemente des C-ITS Trust Models (TLM, CPOC, Root-CA, EA und AA) sollten [4] und die Anforderungen der folgenden Absätze einhalten.
(213)Es bestehen Richtlinien und Kontrollverfahren zur Gewährleistung einer Aufgabentrennung auf der Grundlage der beruflichen Zuständigkeiten. Für die sensibelsten Aufgaben wie dem Zugang zu und der Verwaltung von CA-Verschlüsselungshardware (HSM) und zugehörigen Schlüsselmaterials muss die Autorisierung mehrerer vertrauenswürdiger Personen vorgeschrieben sein.
(214)Diese internen Kontrollverfahren müssen so konzipiert sein, dass für den physischen oder logischen Zugang zu dem Gerät mindestens zwei vertrauenswürdige Personen erforderlich sind. Die Zugangsbeschränkungen zur CA-Verschlüsselungshardware müssen während des gesamten Lebenszyklus, vom Empfang über die Kontrolle bis zur logischen und/oder physischen Zerstörung am Ende, von mehreren vertrauenswürdigen Personen streng durchgesetzt werden. Sobald ein Modul mit funktionsfähigen Schlüsseln aktiviert wird, werden weitere Zugangskontrollen aufgerufen, damit eine getrennte Kontrolle über den physischen und logischen Zugang zu Gerät aufrechterhalten wird.
5.2.3.Identifizierung und Authentifizierung der einzelnen Funktionen
(215)Alle Personen, denen der Beschreibung in dieser Certificate Policy (CP) entsprechend eine Funktion zugewiesen wird, werden einer Identifizierung und Authentifizierung unterzogen, damit gewährleistet ist, dass die betreffende Funktion ihnen ermöglicht, ihre PKI-Pflichten zu erfüllen.
(216)Elemente des C-ITS Trust Modells überprüfen und bestätigen die Identität und Autorisierung aller Mitarbeiter, die die Anerkennung als vertrauenswürde Person anstreben, bevor:
·ihnen ihre Zugangsgeräte ausgehändigt werden und sie Zugang zu den erforderlichen Einrichtungen erhalten;
·ihnen elektronische Berechtigungsnachweise für den Zugang zu CA-Systemen und die Durchführung spezieller Aufgaben übergeben werden.
(217)In der Erklärung zum Zertifizierungsbetrieb (CPS) werden die Mechanismen beschrieben, die für die Identifizierung und Authentifizierung natürlicher Personen eingesetzt werden.
5.2.4.Funktionen, die eine Aufgabentrennung erfordern
(218)Zu den Aufgaben, für die eine Aufgabentrennung erforderlich ist, gehören unter anderem:
·die Annahme, Ablehnung und Sperrung von Anträgen sowie die anderweitige Bearbeitung von CA-Zertifikatanträgen;
·die Generierung, Ausstellung und Vernichtung eines CA-Zertifikats.
(219)Die Aufgabentrennung kann mit Hilfe von PKI-Geräten, Verfahren oder beidem durchgesetzt werden. Keiner Person darf mehr als eine Identität zugewiesen werden, sofern dies nicht von der Root-CA genehmigt wurde.
(220)Der Teil der Root-CA und CA, der mit der Verwaltung der Generierung und Sperrung von Zertifikaten befasst ist, muss hinsichtlich seiner Entscheidungen in Bezug auf die Einrichtung, Bereitstellung, Aufrechterhaltung und Suspendierung von Dienstleistungen gemäß geltenden Certificate Policies von anderen Organisationen unabhängig sein. Insbesondere stehen die Geschäftsleitung, das leitende Personal und das Personal mit Vertrauensfunktionen unter keinerlei geschäftlichem, finanziellem oder sonstigem Druck, der das Vertrauen in die von ihm erbrachten Dienstleistungen nachteilig beeinflussen könnten.
(221)Die EA und AA, die mobile C-ITS-Stationen betreuen, müssen getrennte operative Einheiten mit getrennten IT-Infrastrukturen und IT-Managementteams sein. Der Datenschutz-Grundverordnung entsprechend tauschen EA und AA nur für die Genehmigung von AT-Anträgen (Berechtigungstickets) personenbezogene Daten aus. Daten bezüglich der Genehmigung von AT-Anträgen übertragen sie nur über eine speziell dafür vorgesehene, sichere Schnittstelle mittels des in [1] genannten Protokolls zur Berechtigungsvalidierung. Andere Protokolle können unter der Voraussetzung verwendet werden, dass [1] umgesetzt worden ist.
(222)Die von der EA und AA gespeicherten Logdateien dürfen ausschließlich zum Zweck der Sperrung von Fehlverhalten aufweisenden EC auf der Grundlage von abgefangenen bösartigen CAM/DENM-Benachrichtigungen genutzt werden. Nachdem eine CAM/DENM-Benachrichtigung als „bösartig“ eingestuft wurde, wird die AA den Verifizierungsschlüssel des Berechtigungstickets (AT) in ihren Ausstellungsprotokollen aufsuchen und bei der EA einen Sperrungsantrag mit der verschlüsselten Signatur unter dem privaten EC-Schlüssel, der bei der Ausstellung des AT verwendet wurde, einreichen. Alle Logdateien müssen angemessen gegen den Zugang unbefugter Parteien geschützt sein und dürfen nicht an andere Stellen oder Behörden weitergegeben werden.
Anmerkung: Zum Zeitpunkt der Erstellung der vorliegenden Fassung der Certificate Policy war die Ausgestaltung der Fehlverhalten aufweisenden Funktion noch nicht definiert. Es ist geplant, die Fehlverhalten aufweisende Funktion bei künftigen Überarbeitungen der Certificate Policy in ihrer Ausgestaltung darzustellen.
5.3.Personalkontrollen
5.3.1.Anforderungen an Qualifikation, Erfahrung und Sicherheitsüberprüfung
(223)Die Elemente des C-ITS Trust Models beschäftigen in ausreichender Zahl Personal mit dem Fachwissen, den Erfahrungen und den Qualifikationen, die für die Aufgaben am Arbeitsplatz und die angebotenen Dienste erforderlich sind. Das PKI-Personal erfüllt diese Anforderungen durch eine formelle Ausbildung und entsprechende Zeugnisse, praktische Erfahrung oder eine Kombination aus beidem. Vertrauensfunktionen und Verantwortlichkeiten gemäß Spezifikation in der Erklärung zum Zertifizierungsbetrieb (CPS) werden in den Stellenbeschreibungen dokumentiert und eindeutig benannt. Für das PKI-Personal von Subunternehmern werden Stellenbeschreibungen festgelegt, die eine Trennung der Pflichten und Rechte sicherstellen; zudem wird auf der Grundlage von Pflichten und Zugangsebenen, Sicherheitsüberprüfungen und der Schulung und Sensibilisierung der Mitarbeiter die Sensibilität der jeweiligen Stelle bestimmt.
5.3.2.Verfahren zur Zuverlässigkeitsüberprüfung
(224)Die Elemente des C-ITS Trust Models führen für Personal, das eine Anerkennung als vertrauenswürde Peron anstrebt, Zuverlässigkeitsüberprüfungen durch. Die Zuverlässigkeitsüberprüfungen sind bei Personal, das Vertrauensstellungen innehat, mindestens alle fünf Jahre zu wiederholen.
(225)Die bei einer Zuverlässigkeitsüberprüfung ermittelten Faktoren, die als Gründe für die Ablehnung von Bewerbern für Vertrauensstellungen oder für Maßnahmen gegen eine bestehende vertrauenswürdige Person betrachtet werden können, umfassen unter anderem Folgendes:
·Falschdarstellungen durch den Bewerber oder die vertrauenswürdige Person;
·sehr ungünstige oder unzuverlässige berufliche Zeugnisse;
·bestimmte strafrechtliche Verurteilungen;
·Hinweise auf einen Mangel an finanziellem Verantwortungsbewusstsein.
(226)Berichte, die derartige Informationen enthalten, werden vom Personal der HR-Abteilung bewertet, das in Anbetracht der Art, der Größenordnung und der Häufigkeit des durch die Zuverlässigkeitsüberprüfung aufgedeckten Verhaltens angemessene Maßnahmen zu treffen hat. Die kann Maßnahmen bis einschließlich Aufhebungsangeboten an Bewerber für Vertrauensstellungen oder die Kündigung bestehender vertrauenswürdiger Personen umfassen. Die Verwendung von Informationen, die bei einer Zuverlässigkeitsüberprüfung als Grundlage für eine solche Maßnahme ermittelt wurden, unterliegt geltendem Recht.
(227)Hintergrundüberprüfungen von Personen, die die Anerkennung als vertrauenswürdige Person anstreben, umfassen unter anderem Folgendes:
·Bestätigung der früheren Beschäftigung;
·eine Überprüfung der beruflichen Zeugnisse, die ihre Beschäftigung über einen Zeitraum von mindestens fünf Jahren abdecken;
·Bestätigung des höchsten oder relevantesten Bildungsabschlusses;
·Abfrage der Strafregister.
5.3.3.Schulungsanforderungen
(228)Die Elemente des C-ITS Trust Models stellen ihren Mitarbeitern die erforderliche Schulung zur Verfügung, damit sie ihre Aufgaben im Zusammenhang mit den CA-Operationen sachkundig und zufriedenstellend erfüllen können.
(229)Die Ausbildungsprogramme werden regelmäßig überprüft; in der Ausbildung der Mitarbeiter werden Fragen behandelt, die für die von ihnen wahrgenommenen Funktionen relevant sind.
(230)Die Ausbildungsprogramme betreffen Angelegenheiten, die für das besondere Umfeld der Ausbildungsteilnehmer relevant sind, unter anderem:
·Sicherheitsgrundsätze und -mechanismen der Elemente des C-ITS Trust Models;
·die verwendeten Hard- und Softwareversionen;
·alle Pflichten, deren Erfüllung von der betreffenden Person erwartet wird, sowie interne und externe Berichtsverfahren und Sequenzen;
·PKI-Geschäftsprozesse und Arbeitsabläufe;
·Meldung und Handhabung von Zwischenfällen und Kompromittierungen;
·Verfahren zur Datenwiederherstellung im Falle eines Systemabsturzes und zur Aufrechterhaltung des Geschäftsbetriebs;
·ausreichende IT-Kenntnisse.
5.3.4.Nachschulungsintervalle und -anforderungen
(231)Die Personen, denen Vertrauensfunktionen zugewiesen wurden, müssen ihre während der Ausbildung erworbenen Kenntnisse fortlaufend unter Nutzung eines Schulungsumfelds auffrischen. Die Schulung ist immer dann zu wiederholen, wenn dies für erforderlich gehalten wird, mindestens jedoch alle zwei Jahre.
(232)Elemente des C-ITS Trust Models bieten ihrem Personal in dem Umfang und mit der Häufigkeit Auffrischungsschulungen und Aktualisierungen an, die zur Aufrechterhaltung des Kenntnisstandes erforderlich ist, den sie für die kompetente, zufriedenstellende Erfüllung der Verantwortlichkeiten an ihrem Arbeitsplatz benötigen.
(233)Personen mit Vertrauensfunktionen müssen eventuelle Änderungen im PKI-Betrieb kennen. Wesentliche Änderungen im Betrieb werden von einem Schulungs- bzw. Sensibilisierungsplan begleitet und die Durchführung des Plans wird dokumentiert.
5.3.5.Häufigkeit und Abfolge der Arbeitsplatzrotation
(234)Keine Vorgabe, solange die technischen Fähigkeiten, Erfahrungen und Zugangsrechte gewährleistet sind. Die Administratoren der Elemente des C-ITS Trust Models stellen sicher, dass personelle Veränderungen die Sicherheit des Systems nicht beeinträchtigen.
5.3.6.Sanktionen bei unbefugten Handlungen
(235)Jedes Element des C-ITS Trust Models muss ein förmliches Disziplinarverfahren entwickeln, damit die angemessene Sanktionierung unbefugter Handlungen gewährleistet ist. In schweren Fällen müssen Funktionszuweisungen und die entsprechenden Rechte entzogen werden.
5.3.7.Anforderungen an unabhängige Auftragnehmer
(236)Die Elemente des C-ITS Trust Models können selbständigen Unternehmern oder Beratern nur in dem Umfang den Erwerb der Anerkennung als vertrauenswürdige Personen gestatten, der mit klar umrissenen Beziehungen im Rahmen einer Auslagerung von Aufgabenbereichen in Einklang zu bringen ist; ferner gilt die Voraussetzung, dass die betreffende Stelle den Auftragnehmern oder Beratern im gleichen Maße vertraut wie Mitarbeitern und dass die Auftragnehmer und Berater die für Beschäftigte geltenden Anforderungen erfüllen.
(237)Ist dies nicht der Fall, erhalten selbständige Unternehmer und Berater nur Zugang zu PKI-sicheren C-ITS-Einrichtungen, wenn sie von vertrauenswürdigen Personen begleitet und unmittelbar beaufsichtigt werden.
5.3.8.Dem Personal bereitgestellte Dokumentation
(238)Elemente des C-ITS Trust Models bieten ihrem Personal die erforderliche Schulung und den Zugang zu den Unterlagen, die sie benötigen, um ihre Aufgaben kompetent und zufriedenstellend zu erfüllen.
5.4.Verfahren für die Protokollierung von Audits
(239)In diesem Abschnitt werden die Anforderungen hinsichtlich der Arten von aufzuzeichnenden Ereignissen und das Management von Auditprotokollen festgelegt.
5.4.1.Von jeder CA aufzuzeichnende und zu meldende Ereignisarten
(240)Ein Vertreter der Wurzelzertifizierungsstelle (CA) überprüft die Protokolle, Ereignisse und Verfahren der CA regelmäßig.
(241)Elemente des C-ITS Trust Models zeichnen folgende Arten von Auditereignissen auf (falls zutreffend):
·physischer Zugang zu Einrichtungen – der Zugang natürlicher Personen zu den Einrichtungen wird mittels Speicherung der Zugangsanfragen durch Smartcards aufgezeichnet. Jedes Mal, wenn ein Datensatz angelegt wird, wird ein Ereignis angelegt;
·Verwaltung der Vertrauensfunktionen – jede Änderung der Definition und der Zugangsebene der verschiedenen Funktionen wird einschließlich der Änderungen an Attributen der Funktionen aufgezeichnet. Jedes Mal, wenn ein Datensatz angelegt wird, wird ein Ereignis angelegt;
·logischer Zugang – es wird ein Ereignis angelegt, wenn ein Teilnehmer (z. B. ein Programm) Zugang zu sensiblen Bereichen (d. h. Netzen und Servern) hat;
·Backup-Management – jedes Mal, wenn ein Backup erfolgreich oder erfolglos abgeschlossen wird, wird ein Ereignis angelegt;
·Protokollmanagement – Protokolle werden gespeichert. Wenn die Größe des Protokolls eine bestimmte Größe überschreitet, wird ein Ereignis angelegt;
·Daten aus dem Authentisierungsprozess für Abonnenten und Elemente des C-ITS Trust Models – für jede Authentifizierungsanfrage durch Abonnenten und Elemente des C-ITS Trust Models wird ein Ereignis generiert;
·Annahme und Ablehnung von Zertifikatanträgen, einschließlich der Ausstellung und Erneuerung von Zertifikaten – es wird regelmäßig ein Ereignis mit einer Liste der in den vorangegangenen sieben Tagen angenommenen und abgelehnten Zertifikatanträgen generiert;
·Herstellerregistrierung – wenn ein Hersteller registriert wird, wird ein Ereignis angelegt;
·Registrierung der C-ITS-Station – ein Ereignis wird angelegt, wenn eine C-ITS-Station registriert wird;
·HSM-Management – ein Ereignis wird angelegt, wenn eine HSM-Sicherheitsverletzung aufgezeichnet wird;
·IT und Netzmanagement, soweit sie die PKI-Systeme betreffen – ein Ereignis wird angelegt, wenn ein PKI-Server abgeschaltet oder neu gestartet wird;
·Sicherheitsmanagement (erfolgreiche und erfolglose Zugangsversuche zum PKI-System, durchgeführte Aktionen an und durch PKI- und sonstige(n) sicherheitsrelevante(n) Systeme(n), Änderungen am Sicherheitsprofil, Systemabstürze, Hardware-Ausfälle und andere Anomalien, Firewall- und Router-Aktivitäten; sowie Zutritt zu und Verlassen von Einrichtungen des PKI-Systems);
·ereignisbezogene Daten werden mindestens fünf Jahre lang gespeichert, sofern keine zusätzlichen nationalen Vorschriften gelten.
(242)Im Einklang mit der Datenschutz-Grundverordnung (DSGVO) erlauben die Audit-Protokolle in Bezug auf Privatfahrzeuge an C-ITS-Stationen keinen Zugriff auf Daten, die die Privatsphäre betreffen.
(243)Die Protokolle von Sicherheitsaudits werden nach Möglichkeit automatisch erfasst. Ist dies nicht möglich, so ist ein Logbuch, ein Papierformular oder ein sonstiger physischer Mechanismus zu verwenden. Alle elektronischen und nicht elektronischen Protokolle von Sicherheitsaudits müssen aufbewahrt und bei Konformitätsprüfungen zur Verfügung gestellt werden.
(244)Jedes mit dem Lebenszyklus eines Zertifikats zusammenhängende Ereignis wird so in einem Protokoll erfasst, dass es der durchführenden Person zugeordnet werden kann. Alle Daten im Zusammenhang mit einer persönlichen Identität werden verschlüsselt und gegen unbefugten Zugriff geschützt.
(245)Audit-Protokolle umfassen mindestens folgende (automatisch oder manuell für jedes prüfbare Ereignis aufgezeichnete) Angaben:
·Art des Ereignisses (aus der vorstehenden Aufzählung);
·vertrauenswürdiges Datum und vertrauenswürdige Uhrzeit des Eintritts des Ereignisses;
·Ergebnis des Ereignisses – Erfolg oder Misserfolg, sofern angemessen;
·gegebenenfalls die Identität der Stelle und/oder des Betreibers, die bzw. der das Ereignis ausgelöst hat;
·Identität der Stelle, an die sich das Ereignis richtet.
5.4.2.Häufigkeit der Bearbeitung von Protokollen
(246)Die Überprüfung von Audit-Protokollen wird durch Alarmmeldungen auf der Grundlage von Unregelmäßigkeiten und Vorfällen innerhalb der CA-Systeme ausgelöst und darüber hinaus in regelmäßigen jährlichen Abständen durchgeführt.
(247)Die Bearbeitung von AuditProtokollen besteht in einer Überprüfung der Audit-Protokolle und der Dokumentierung der Gründe für alle bedeutenden Ereignisse in einer Zusammenfassung der AuditProtokolle. Im Rahmen der Überprüfungen von AuditProtokollen wird verifiziert, dass das Protokoll nicht manipuliert wurde; ferner werden alle Protokolleinträge kontrolliert und Alarmmeldungen oder Unregelmäßigkeiten in den Protokollen werden untersucht. Auf der Grundlage von Überprüfungen der AuditProtokolle getroffene Maßnahmen werden dokumentiert.
(248)Das Audit-Protokoll wird mindestens einmal wöchentlich archiviert. Administratoren archivieren das Protokoll manuell, wenn der freie Speicherplatz für das Audit-Protokoll kleiner ist als die Menge an Audit-Protokolldaten, die für die betreffende Woche erwartet werden.
5.4.3.Aufbewahrungszeitraum für Audit-Protokolle
(249)Protokoll-Datensätze, die sich auf die Lebenszyklen von Zertifikaten beziehen, werden mindestens fünf Jahre nach dem Ablauf des entsprechenden Zertifikats aufbewahrt.
5.4.4.Schutz der Audit-Protokolle
(250)Die Integrität und Vertraulichkeit des Audit-Protokolls wird durch einen auf Funktionen basierenden Zugriffskontrollmechanismus gewährleistet. Die internen Audit-Protokolle sind nur für Administratoren zugänglich; Audit-Protokolle im Zusammenhang mit dem Lebenszyklus von Zertifikaten sind über einer Webseite mit Nutzer-Login auch Nutzern mit entsprechender Autorisierung zugänglich. Der Zugang ist mit einer Authentifizierung mit mehreren Nutzern (mindestens zwei Nutzern) auf mindestens zwei Ebenen zu gewähren. Es muss technisch gewährleistet sein, dass die Nutzer nicht auf ihre eigenen Logdateien zugreifen können.
(251)Alle Protokolleinträge müssen unter Verwendung von Schlüsselmaterial der Verschlüsselungshardware HSM signiert werden.
(252)Ereignisprotokolle, die zur persönlichen Identifizierung führen können, beispielsweise über ein privates Fahrzeug, werden so verschlüsselt, dass nur befugte Personen sie lesen können.
(253)Ereignisse werden in einer Weise protokolliert, dass sie innerhalb der Frist, in der die Protokolle beibehalten werden müssen nicht ohne Weiteres gelöscht oder zerstört werden können (außer bei Übertragungen auf Langzeitmedien).
(254)Die Ereignisprotokolle sind so geschützt, dass sie für die Dauer ihrer Speicherfrist lesbar bleiben.
5.4.5.Sicherungsverfahren für Audit-Protokolle
(255)Audit-Protokolle und Audit-Zusammenfassungen werden mittels unternehmensinterner Sicherungsmechanismus unter Aufsicht von Inhabern autorisierter Vertrauensfunktionen getrennt von der Quellkomponente für ihre Erzeugung gesichert (Backup). Backups von Audit-Protokollen werden mit dem gleichen Vertrauensniveau geschützt, das auch für die ursprünglichen Protokolle gilt.
5.4.6.Audit-Erfassungssystem (intern oder extern)
(256)Die Geräte der Elemente des C-ITS Trust Models aktivieren die Auditprozesse beim Einschalten des Systems und deaktivieren sie erst beim Abschalten des Systems. Stehen keine Auditprozesse zur Verfügung, stellt das Element des C-ITS Trust Models seinen Betrieb vorübergehend ein.
(257)Am Ende eines jeden Betriebszeitraums sowie bei der Schlüsselerneuerung für Zertifikate ist dem Betriebsleiter und dem Leitungsorgan des Betriebs des jeweiligen PKI-Elements der kollektive Gerätestatus zu melden.
5.4.7.Benachrichtigung des ereignisauslösenden Subjekts
(258)Protokolliert das Audit-Erfassungssystem ein Ereignis, gewährleistet es die Verknüpfung des Ereignisses mit einer Vertrauensfunktion.
5.4.8.Schwachstellenbewertung
(259)Der für die Durchführung von Audits zuständige Aufgabenbereich und die für die Realisierung des Betriebs des PKI-Systems in den Elementen des C-ITS Trust Models zuständigen Aufgabenbereiche erläutern alle bedeutenden Ereignis in einer AuditProtokollzusammenfassung. Im Rahmen solcher Überprüfungen wird verifiziert, dass die Protokolle nicht manipuliert wurden und dass bei den Auditdaten keine Unterbrechungen oder sonstige Verluste vorliegen; anschließend werden sämtliche Protokolleinträge kurz kontrolliert, wobei Alarmmeldungen oder Unregelmäßigkeiten in den Protokollen einer gründlicheren Untersuchung unterzogen werden. Die infolge dieser Überprüfungen getroffenen Maßnahmen werden dokumentiert.
(260)Die Elemente des C-ITS Trust Models
·führen unter der Leitung der Elemente des C-ITS Trust Modells organisatorische und/oder technische Aufdeckungs- und Präventionskontrollen durch, um PKI-Systeme vor Viren und Schadsoftware zu schützen;
·dokumentieren und befolgen einen Prozess zur Beseitigung von Schwachstellen, der sich mit der Ermittlung, Prüfung, Beantwortung und Behebung von Schwachstellen befasst;
·durchlaufen eine Schwachstellenüberprüfung (Vulnerability Scan) oder führen diese wie folgt durch:
·nach Wechseln von Systemen oder Netzen, die von den Elementen des C-ITS Trust Models als bedeutend für PKI-Komponenten eingestuft werden und
·mindestens einmal im Monat auf öffentlichen und privaten IP-Adressen, die von der CA und der CPOC als zum PKI-System gehörend gekennzeichnet wurden,
·durchlaufen mindestens auf jährlicher Basis und nach Aktualisierungen oder Änderungen von Infrastrukturen oder Anwendungen, die von den Elementen des C-ITS Trust Models als für die PKI-Komponente einer Wurzelzertifizierungsstelle (CA) bedeutend gekennzeichnet wurden, einen Penetrationstest;
·bei Online-Systemen werden Nachweise erfasst, dass jede(r) einzelne Schwachstellenüberprüfung und Penetrationstest von einer Person oder Stelle (bzw. kollektiven Gruppe aus beiden) durchgeführt wurde, die über die Kompetenzen, Instrumente und Kenntnisse sowie den Ethikkodex und die Unabhängigkeit verfügt, die zur Erbringung eines verlässlichen Schwachstellen- oder Penetrationstests erforderlich sind;
·verfolgen und beheben Schwachstellen im Einklang mit den Strategien für die Cybersicherheit von Unternehmen und der Methode zur Risikominderung.
5.5.Archivierung von Aufzeichnungen
5.5.1.Art der archivierten Aufzeichnungen
(261)Die Elemente des C-ITS Trust Models archivieren Aufzeichnungen hinreichend detailliert, damit die Gültigkeit einer Signatur und der ordnungsgemäße Betrieb der PKI festgestellt werden können. Es werden mindestens folgende Aufzeichnungen mit PKI-Ereignisses archiviert (falls zutreffend):
·Protokoll über den physischen Zugang zu Einrichtungen von Elementen des C-ITS Trust Models (mindestens ein Jahr);
·Managementprotokoll der Vertrauensfunktion für Elemente des C-ITS Trust Models (mindestens 10 Jahre);
·Protokoll über den IT-Zugang für Elemente des C-ITS Trust Models (mindestens fünf Jahre);
·Protokoll über die Generierung, Nutzung und Vernichtung von CA-Schlüsseln (mindestens fünf Jahre) (nicht für TLM und CPOC);
·Protokoll über die Generierung, Nutzung und Vernichtung von Zertifikaten (mindestens zwei Jahre);
·Protokoll über CPA-Anträge (mindestens zwei Jahre);
·Protokoll über das Aktivierungsdatenmanagement für Elemente des C-ITS Trust Models (mindestens fünf Jahre);
·IT- und Netzprotokoll für Elemente des C-ITS Trust Models (mindestens fünf Jahre);
·PKI-Unterlagen für Elemente des C-ITS Trust Models (mindestens fünf Jahre);
·Bericht über Sicherheitsvorfälle und Audits für Elemente des C-ITS Trust Models (mindestens zehn Jahre);
·Geräte, Software und Konfiguration des Systems (mindestens fünf Jahre).
(262)Die Elemente des C-ITS Trust Models müssen folgende Unterlagen, die sich auf Zertifikatanträge und deren Verifizierung beziehen, sowie alle Zertifikate von TLM, Root-CA und CA und deren CRL mindestens sieben Jahre, nachdem ein Zertifikat auf der Grundlage dieser Unterlagen ungültig wird, aufbewahren:
·von Elementen des C-ITS Trust Models aufbewahrte PKI-Auditunterlagen;
·von Elementen des C-ITS Trust Models aufbewahrte CPS-Unterlagen;
·von Elementen des C-ITS Trust Models aufbewahrte Verträge zwischen der CPA und anderen Stellen;
·von CA und TLM aufbewahrte Zertifikate (oder andere Informationen über Sperrungen);
·Aufzeichnungen über Zertifikatanträge im System der Root-CA (gilt nicht für den TLM);
·sonstige Daten oder Anwendungen, die ausreichen, um den Inhalt des Archivs zu verifizieren;
·alle Arbeiten im Zusammenhang mit oder von Elementen des C-ITS Trust Models und Konformitätsprüfern.
(263)Die CA-Stelle bewahrt sämtliche Unterlagen, die sich auf Zertifikatanträge und deren Verifizierung beziehen, sowie sämtliche Zertifikate und Unterlagen über deren Sperrung mindestens sieben Jahre, nachdem auf diesen Unterlagen basierende Zertifikate ungültig werden, auf.
5.5.2.Aufbewahrungszeitraum für Archive
(264)Elemente des C-ITS Trust Models bewahren sämtliche Aufzeichnungen mindestens fünf Jahre, nachdem das entsprechende Zertifikat abgelaufen ist, auf; Verordnungen, die eine längere Archivierungszeit vorschreiben, bleiben hiervon unberührt.
5.5.3.Schutz von Archiven
(265)Elemente des C-ITS Trust Models speichern das Aufzeichnungsarchiv in einer sicheren, geschützten Speichereinrichtung getrennt von Geräten der CA und mit physischen und verfahrenstechnischen Sicherheitskontrollen, die denen der PKI gleichwertig oder besser als diese sind.
(266)Das Archiv ist mittels Speicherung in einem vertrauenswürdigen System vor unbefugter Einsichtnahme, Änderung, Löschung oder sonstiger Manipulation zu schützen.
(267)Die Medien, in denen die Archivdaten aufbewahrt werden, und die für deren Verarbeitung erforderlichen Anwendungen werden in einer Weise gepflegt, die sicherstellt, dass während des in der vorliegenden Certificate Policy festgelegten Zeitraums auf sie zugegriffen werden kann.
5.5.4.Systemarchiv und Speicherung
(268)Die Elemente des C-ITS Trust Models führen schrittweise Sicherungen der Systemarchive für Informationen dieser Art täglich und vollständige Sicherungen (Backups) wöchentlich durch. Kopien von Aufzeichnungen in Papierform werden in einer gesicherten Einrichtung außerhalb des Standorts aufbewahrt.
5.5.5.Anforderungen an Zeitstempel von Aufzeichnungen
(269)Die Elemente des C-ITS Trust Models, die eine Datenbank für Sperrungen verwalten, stellen sicher, dass die Aufzeichnungen Angaben zur Uhrzeit und zum Datum der Erstellung von Sperraufzeichnungen enthalten. Die Integrität dieser Informationen wird mithilfe kryptografischer Lösungen gesichert.
5.5.6.Archiverfassungssystem (intern oder extern)
(270)Das Archiverfassungssystem ist intern.
5.5.7.Verfahren zur Beschaffung und Verifizierung von Archivinformationen
(271)Sämtliche Elemente des C-ITS Trust Models erlauben ausschließlich bevollmächtigten, vertrauenswürdigen Personen den Zugang zum Archiv. Root-CA und CA beschreiben in ihrer Erklärung zum Zertifizierungsbetrieb (CPS) die Verfahren für die Erstellung, Verifizierung, Packung, Übertragung und Speicherung von Archivinformationen.
(272)Die Geräte von Root-CA und CA überprüfen vor der erneuten Speicherung die Integrität der Informationen.
5.6.Schlüsselwechsel für Elemente des C-ITS Trust Models
(273)Bei folgenden Elementen des C-ITS Trust Models bestehen besondere Anforderungen an Schlüsselwechsel: TLM-, Root-CA- und EA/A-/AA-Zertifikate.
5.6.1.TLM
(274)Der TLM löscht seinen privaten Schlüssel, wenn das entsprechende Zertifikat abläuft. Vor der Deaktivierung des derzeit gültigen privaten Schlüssels generiert er ein neues Schlüsselpaar und das entsprechende TLM-Zertifikat. Dabei sorgt er dafür. dass das neue (Link-)Zertifikat so rechtzeitig in die ECTL aufgenommen wird, dass es vor seinem Gültigwerden an alle C-ITS-Stationen verteilt werden kann. Das Link-Zertifikat und das neue selbstsignierte Zertifikat werden an die zentrale Kontaktstelle (CPOC) übertragen.
5.6.2.Root-CA
(275)Die Root-CA deaktiviert und löscht den derzeitigen privaten Schlüssel (einschließlich der Backup-Schlüssel), so dass sie keine EA/AA Zertifikate mit einer über die Gültigkeit des Root-CA-Zertifikats hinausgehenden Gültigkeit ausstellen kann.
(276)Die Root-CA generiert vor der Deaktivierung des derzeitigen privaten Schlüssels (einschließlich der Backup-Schlüssel) ein neues Schlüsselpaar und ein entsprechendes Root-CA- und Link-Zertifikat und übermittelt es an den TLM zur Aufnahme in die ECTL (Liste vertrauenswürdiger europäischer Zertifikate). Die Gültigkeitsdauer des neuen Root-CA-Zertifikats beginnt mit der geplanten Deaktivierung des derzeitigen privaten Schlüssels. Die Root-CA sorgt dafür, dass das neue Zertifikat so rechtzeitig in die ECTL aufgenommen wird, dass es vor seinem Gültigwerden an alle C-ITS-Stationen verteilt werden kann.
(277)Die Root-CA aktiviert den neuen privaten Schlüssel, sobald das entsprechende Zertifikat der Root-CA gültig wird.
5.6.3.EA/AA-Zertifikat
(278)Die EA/AA deaktiviert den derzeitigen privaten Schlüssel, so dass sie keine EC/AT mit einer über die Gültigkeit des EA/AA-Zertifikats hinausgehenden Gültigkeit ausstellen kann.
(279)Die EA/AA generiert vor der Deaktivierung des derzeitigen privaten Schlüssels ein neues Schlüsselpaar und fordert das entsprechende EA/AA-Zertifikat an. Die Gültigkeitsdauer des neuen EA/AA-Zertifikats für die beginnt mit der geplanten Deaktivierung des derzeitigen privaten Schlüssels. Die EA/AA sorgt dafür, dass das neue Zertifikat so rechtzeitig veröffentlicht werden kann, dass es vor seinem Gültigwerden an alle C-ITS-Stationen verteilt werden kann.
(280)Die EA/AA aktiviert den neuen privaten Schlüssel, sobald das entsprechende EA/AA-Zertifikat gültig wird.
5.6.4.Prüfer
Keine Regelung.
5.7.Kompromittierung und Datenwiederherstellung im Falle eines Systemabsturzes (Disaster Recovery)
5.7.1.Umgang mit Störungen und Kompromittierungen
(281)Die Elemente des C-ITS Trust Models überwachen ihre Geräte fortlaufend, so dass potenzielle Hackerversuche oder andere Formen von Kompromittierungen aufgedeckt werden. In einem solchen Fall führen sie Untersuchungen zur Ermittlung der Art und des Umfangs der Schäden durch.
(282)Entdeckt das für das Management der Root-CA oder des TLM zuständige Personal einen potenziellen Hackerversuch oder eine andere Form der Kompromittierung, führt es Untersuchungen zur Ermittlung der Art und des Umfangs der Schäden durch. Bei einer Kompromittierung des private Schlüssels wird das Root-CA-Zertifikat gesperrt. Die IT-Sicherheitsexperten der CPA bewerten den Umfang des potenziellen Schadens, um festzustellen, ob die PKI neu aufgebaut werden muss, ob nur einige Zertifikate gesperrt werden müssen und/oder ob die PKI kompromittiert wurde. Darüber hinaus bestimmt die CPA im Einklang mit ihrem Plan zur Aufrechterhaltung des Geschäftsbetriebs, welche Dienste beizubehalten sind (Sperrung und Information über den Zertifikatsstatus) und wie dies erfolgen soll.
(283)In der Erklärung zum Zertifizierungsbetrieb (CPS) werden Zwischenfälle, Kompromittierungen und die Aufrechterhaltung des Geschäftsbetriebs behandelt, wobei sie sich zu ihrer Umsetzung auch auf andere Ressourcen und Pläne des Unternehmens stützen kann.
(284)Entdeckt das für das Management der EA/AA/CPOC zuständige Personal einen potenziellen Hackerversuch oder eine andere Form der Kompromittierung, führt es Untersuchungen zur Ermittlung der Art und des Umfangs der Schäden durch. Das für das Management der CA- oder der CPOC-Stelle verantwortliche Personal bewertet den Umfang des potenziellen Schadens, um festzustellen, ob die PKI-Komponenten neu aufgebaut werden müssen, ob nur einige Zertifikate gesperrt werden müssen und/oder ob die PKI-Komponente kompromittiert wurde. Darüber hinaus bestimmt die Sub-CA-Stelle im Einklang mit ihrem Plan zur Aufrechterhaltung des Geschäftsbetriebs, welche Dienste beizubehalten sind und wie dies erfolgen soll. Wird eine PKI-Komponente kompromittiert, warnt die CA-Stelle ihre eigene Root-CA und den TLM über die CPOC.
(285)Zwischenfälle, Kompromittierungen und die Aufrechterhaltung des Geschäftsbetriebs werden in der Erklärung zum Zertifizierungsbetrieb (CPS) der Root-CA oder des TLM behandelt (bzw. anderen relevanten Unterlagen, wenn es sich um die CPOC handelt), wobei sich die CPOC zu deren Umsetzung auch auf andere Ressourcen und Pläne des Unternehmens stützen kann.
(286)Die Root-CA und die CA alarmieren alle Vertreter von Mitgliedstaaten und Root-CA, mit denen sie eine Vereinbarung im Zusammenhang mit kooperativen intelligenten Verkehrssystemen (C-ITS) geschlossen haben, und übermitteln ihnen genaue Informationen über die Folgen des Zwischenfalls, damit diese ihre eigenen Störungsmanagementpläne aktivieren können.
5.7.2.Beschädigung von Rechnerressourcen, Software und/oder Daten
(287)Wird eine Havarie festgestellt, die den ordnungsgemäßen Betrieb eines Elements des C-ITS Trust Models verhindert, so setzt dieses Element seinen Betrieb aus und prüft, ob der private Schlüssel kompromittiert wurde (mit Ausnahme der CPOC). Defekte Hardware wird so schnell wie möglich ersetzt und es gelten die in den Abschnitten 5.7.3 und 5.7.4 beschriebenen Verfahren.
(288)Die Beschädigung von Rechnerressourcen, Software und/oder Daten wird der Root-CA bei den höchsten Risikostufen innerhalb von 24 Stunden gemeldet. Alle anderen Ereignisse müssen in den regelmäßigen Bericht der Root-CA, EA und AA aufgenommen werden.
5.7.3.Verfahren bei der Kompromittierung von privaten Schlüsseln
(289)Wenn der private Schlüssel einer Root-CA kompromittiert ist, verloren geht oder zerstört wird oder der Verdacht seiner Kompromittierung besteht, muss die Root-CA:
·ihren Betrieb aussetzen;
·den Plan zur Datenwiederherstellung im Falle eines Systemabsturzes und den Migrationsplan in Gang setzen;
·ihr Root-CA-Zertifikat sperren;
·das „Schlüsselproblem“ ermitteln, das die Kompromittierung hervorrief, und die CPA benachrichtigen, die über den TLM das Root-CA-Zertifikat sperrt (siehe Abschnitt 7);
·alle Abonnenten, mit denen sie eine Vereinbarung geschlossen hat, warnen.
(290)Wenn der private Schlüssel einer EA/AA kompromittiert ist, verloren geht oder zerstört wird oder der Verdacht seiner Kompromittierung besteht, muss die EA/AA:
·ihren Betrieb aussetzen;
·ihr eigenes Zertifikat sperren;
·das „Schlüsselproblem“ ermitteln und die Root-CA benachrichtigen;
·Abonnenten, mit denen eine Vereinbarung besteht, warnen.
(291)Wenn der EC- oder AT-Schlüssel einer C-ITS-Station kompromittiert ist, verloren geht oder zerstört wird oder der Verdacht seiner Kompromittierung besteht, muss die EA/AA, bei der die C-ITS-Station ein Abonnement hat, Folgendes veranlassen:
·Sperrung des Enrollment-Berechtigungsnachweises (EC) des betroffenen ITS;
·Ermittlung des „Schlüsselproblems“ und Benachrichtigung der Root-CA;
·Warnung der Abonnenten, mit denen sie eine Vereinbarung geschlossen hat.
(292)Reichen von der Root-CA und/oder CA oder C-ITS-Stationen verwendete Algorithmen oder zugehörige Parameter für ihren verbleibenden Verwendungszweck nicht mehr aus, informiert die CPA (mit entsprechender Empfehlung kryptografischer Experten) die Root-CA-Stelle, mit der sie eine Vereinbarung geschlossen hat, und ändert die verwendeten Algorithmen. (Einzelheiten sind Abschnitt 6 und den CPS der Root-CA und Sub-CA zu entnehmen.)
5.7.4.Fähigkeiten zur Aufrechterhaltung des Geschäftsbetriebs nach einem Systemabsturz
(293)Die sichere Einrichtungen für CA-Operationen betreibenden Elemente des C-ITS Trust Models entwickeln, testen, pflegen und implementieren einen Plan zur Datenwiederherstellung im Falle eines Systemabsturzes, der darauf ausgelegt ist, die Auswirkungen von Naturkatastrophen oder von Menschen verursachten Katastrophen zu mildern. Diese Pläne behandeln die Wiederherstellung von Diensten der Informationssysteme und Schlüsselfunktionen des Unternehmens.
(294)Nach einem Zwischenfall einer bestimmten Risikostufe muss die kompromittierte CA von einem akkreditieren PKI-Prüfer erneut geprüft werden (siehe Abschnitt 8).
(295)Kann eine kompromittierte CA nicht mehr arbeiten (z. B. nach einem schweren Zwischenfall), muss ein Migrationsplan für die Übertragung ihrer Funktionen auf eine andere Root-CA erstellt werden. Für die Unterstützung des Migrationsplans muss zumindest die Root-CA der EU zur Verfügung stehen. Die kompromittierte CA stellt ihre Funktion ein.
(296)Die Root-CA nehmen den Plan zu Datenwiederherstellung im Falle eines Systemabsturzes und den Migrationsplan in die Erklärung zum Zertifizierungsbetrieb (CPS) auf.
5.8.Beendigung und Übertragung
5.8.1.TLM
(297)Der TLM beendet seinen Betrieb nicht, aber eine den TLM verwaltende Stelle kann eine andere Stelle übernehmen.
(298)Im Falle eines Wechsels der Verwaltungsstelle:
·beantragt sie die Genehmigung der CPA für den Wechsel des TLM-Managements von der alten auf die neue Stelle;
·die CPA genehmigt den Wechsel des TLM-Managements;
·sämtliche Audit-Protokolle und archivierten Aufzeichnungen werden von der alten Managementstelle an die neue Stelle übertragen.
5.8.2.Root-CA
(299)Die Root-CA beendet/beginnt ihren Betrieb nicht ohne die Erstellung eines Migrationsplans (in der maßgeblichen CPS festgelegt), der den laufenden Betrieb für alle Abonnenten gewährleistet.
(300)Im Falle der Beendigung des Root-CA-Dienstes veranlasst die Root-CA Folgendes:
·Benachrichtigung der CPA;
·Benachrichtigung des TLM, damit dieser das Zertifikat der Root-CA von der ECTL streichen kann;
·Sperrung der entsprechenden Root-CA mittels Ausstellung einer Zertifikatsperrliste (CRL), in der sie selbst enthalten ist;
·Warnung der Root-CA, mit denen sie eine Vereinbarung über die Erneuerung von EA/AA-Zertifikaten geschlossen hat;
·Vernichtung des privaten Schlüssels der Root-CA;
·Übermittlung der letzten Informationen über den Sperrstatus an den Vertrauenden Dritten (von der Root-CA signierte CRL) mit dem deutlichen Hinweis, dass es sich um die letzte Information über Sperrungen handelt;
·Archivierung aller Audit-Protokolle und sonstiger Aufzeichnungen vor der Beendigung der PKI;
·Übermittlung archivierter Aufzeichnungen an eine geeignete Behörde.
(301)Der TLM streicht das entsprechende Root-CA-Zertifikat von der ECTL.
5.8.3.EA/AA
(302)Wird der EA/AA-Dienst beendet, übermittelt die EA/AA-Stelle vor der Beendigung entsprechende Benachrichtigungen. Eine EA oder AA beendet/beginnt ihren Betrieb nicht ohne die Erstellung eines Migrationsplans (in der maßgeblichen CPS festgelegt), der den laufenden Betrieb für alle Abonnenten gewährleistet. Die EA/AA
·informiert die Root-CA per Einschreiben;
·zerstört den privaten Schlüssel der CA;
·überträgt ihre Datenbank an die von der Root-CA benannte Stelle;
·stellt die Ausstellung von Zertifikaten ein;
·während ihre Datenbank übertragen wird und bis die Datenbank an einer neuen Stelle voll funktionsfähig ist, erhält sie Kapazitäten zur Genehmigung von Anträgen der zuständigen Datenschutzbehörde aufrecht;
·wurde eine Sub-CA kompromittiert, sperrt die Root-CA die Sub-CA und gibt eine neue CRL mit einem Verzeichnis gesperrter Sub-CA heraus;
·archiviert vor der Beendigung der PKI alle Audit-Protokolle und sonstigen Aufzeichnungen;
·überträgt archivierte Aufzeichnungen an eine von der Root-CA benannte Stelle.
(303)Im Falle der Beendigung der Dienste der CA ist die CA dafür verantwortlich, alle für die Erfordernisse von CA- und PKI-Komponenten relevanten Aufzeichnungen zu führen.
6.Technische Sicherheitskontrollen
6.1.Generierung und Installation von Schlüsselpaaren
6.1.1.TLM, Root-CA, EA, AA
(304)Der Prozess der Generierung von Schlüsselpaaren erfüllt folgende Anforderungen:
·jeder Teilnehmer muss in der Lage sein, im Einklang mit den Abschnitten 6.1.4 und 6.1.5 seine eigenen Schlüsselpaare zu generieren;
·der Prozess der Ableitung symmetrischer Verschlüsselungsschlüssel und eines MAC-Schlüssels für Zertifikatanträge (ECIES) wird gemäß [1] und [5] durchgeführt;
·im Schlüsselgenerierungsprozess werden die in den Abschnitten 6.1.4.1 und 6.1.4.2 beschriebenen Algorithmen und Schlüssellängen verwendet;
·für den Prozess der Generierung von Schlüsselpaaren gelten die Anforderungen für die „sichere Speicherung privater Schlüssel“ (siehe Abschnitt 6.1.5);
·die Root-CA und deren Abonnenten (Sub-CA) stellen sicher, dass die Integrität und Authentizität ihrer öffentlichen Schlüssel und damit verbundener Parameter während der Verteilung an die registrierten Stellen der Sub-CA erhalten bleiben.
6.1.2.EE – mobile C-ITS-Station
(305)Jede mobile C-ITS-Station generiert ihre eigenen Schlüsselpaare gemäß den Abschnitten 6.1.4 und 6.1.5.
(306)Der Prozess der Ableitung symmetrischer Verschlüsselungsschlüssel und eines MAC-Schlüssels für Zertifikatanträge (ECIES) wird gemäß [1] und [5] durchgeführt;
(307)Bei den Schlüsselgenerierungsprozessen werden die in den Abschnitten 6.1.4.1 und 6.1.4.2 beschriebenen Algorithmen und Schlüssellängen verwendet.
(308)Für die Prozesse der Generierung von Schlüsselpaaren gelten die Anforderungen für die „sichere Speicherung privater Schlüssel“ (siehe Abschnitt 6.1.5);
6.1.3.EE – ortsfeste C-ITS-Station
(309)Jede ortsfeste C-ITS-Station generiert ihr eigenes Schlüsselpaar gemäß den Abschnitten 6.1.4 und 6.1.5.
(310)Bei den Schlüsselgenerierungsprozessen werden die in den Abschnitten 6.1.4.1 und 6.1.4.2 beschriebenen Algorithmen und Schlüssellängen verwendet.
(311)Für die Prozesse der Generierung von Schlüsselpaaren gelten die Anforderungen für die „sichere Speicherung privater Schlüssel“ (siehe Abschnitt 6.1.5).
6.1.4.Kryptografische Anforderungen
(312)PKI-Teilnehmer müssen hinsichtlich des Signaturalgorithmus, der Schlüssellänge, des Zufallszahlengenerators und der Link-Zertifikate die in den folgenden Absätzen dargelegten kryptografischen Anforderungen erfüllen.
6.1.4.1.Algorithmus und Schlüssellänge – Signaturalgorithmen
(313)Spätestens zwei Jahre nach dem Inkrafttreten dieser Verordnung müssen alle PKI-Teilnehmer (TLM, Root-CA, EA, AA und C-ITS-Stationen) in der Lage sein, gemäß Tabelle 4 Schlüsselpaare zu generieren und den privaten Schlüssel mit ausgewählten Algorithmen für Signaturvorgänge zu nutzen.
(314)Sämtliche PKI-Teilnehmer, die ihrer Funktion gemäß Definition in Abschnitt 1.3.6 entsprechend die Integrität der ECTL, der Zertifikate und/oder der signierten Nachrichten kontrollieren müssen, unterstützen die entsprechenden, in Tabelle 5 aufgeführten Algorithmen für die Verifizierung. Insbesondere müssen die C-ITS-Stationen in der Lage sein, die Integrität der ECTL zu überprüfen.
|
|
TLM
|
Root-CA
|
EA
|
AA
|
C-ITS-Station
|
|
ECDSA_nistP256_ung_SHA 256
|
-
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP256r1_with_SHA 256
|
-
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
-
|
-
|
|
X kennzeichnet die verbindliche Unterstützung
|
Tabelle 4: Generierung von Schlüsselpaaren und Nutzung des privaten Schlüssels für Signaturvorgänge
|
|
TLM
|
Root-CA
|
EA
|
AA
|
C-ITS-Station
|
|
ECDSA_nistP256_ung_SHA 256
|
X
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP256r1_with_SHA 256
|
X
|
X
|
X
|
X
|
X
|
|
ECDSA_brainpoolP384r1_with_SHA 384
|
X
|
X
|
X
|
X
|
X
|
|
X kennzeichnet die verbindliche Unterstützung
|
Tabelle 5: Überblick über Verifizierungen
(315)Wenn die CPA dies auf der Grundlage neu festgestellter kryptografischer Schwachstellen entscheidet, müssen alle C-ITS-Stationen so bald wie möglich zu einem der beiden Algorithmen (ECDSA_nistP256_with_SHA 256 oder ECDSA_brainpoolP256_with_SHA 256) wechseln können. Der/die tatsächlich verwendete(n) Algorithmus/Algorithmen werden in der Erklärung zum Zertifizierungsbetrieb (CPS) der CA festgelegt, die im Einklang mit der vorliegenden Certificate Policy (CP) das Zertifikat für den entsprechenden öffentlichen Schlüssel ausstellt.
6.1.4.2.Algorithmus und Schlüssellänge – Verschlüsselungsalgorithmen für Enrollment und Berechtigung
(316)Spätestens zwei Jahre nach dem Inkrafttreten dieser Verordnung müssen alle PKI-Teilnehmer (TLM, EA, AA und C-ITS-Stationen) in der Lage sein, gemäß Tabelle 6 öffentliche Schlüssel für die Verschlüsselung von Enrollment- und Berechtigungsanträgen und den Antworten darauf mit ausgewählten Algorithmen zu nutzen. Der/die tatsächlich verwendete(n) Algorithmus/Algorithmen werden in der Erklärung zum Zertifizierungsbetrieb (CPS) der CA festgelegt, die im Einklang mit der vorliegenden Certificate Policy (CP) das Zertifikat für den entsprechenden öffentlichen Schlüssel ausstellt.
(317)Die in Tabelle 6 benannten Algorithmen geben die Länge der Schlüssel und die Länge der Hash-Algorithmen an und sind gemäß [5] zu implementieren.
|
|
TLM
|
Root-CA
|
EA
|
AA
|
C-ITS-Station
|
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
X kennzeichnet die verbindliche Unterstützung
|
Tabelle 6: Verwendung öffentlicher Schlüssel für die Verschlüsselung von Enrollment- und Berechtigungsanträgen/Antworten
(318)Spätestens zwei Jahre nach dem Inkrafttreten dieser Verordnung müssen alle PKI-Teilnehmer (EA, AA und C-ITS-Stationen) in der Lage sein, gemäß Tabelle 7 Schlüsselpaare zu generieren und den privaten Schlüssel zur Entschlüsselung von Enrollment- und Berechtigungsanträgen und den Antworten darauf zu nutzen:
|
|
TLM
|
Root-CA
|
EA
|
AA
|
C-ITS-Station
|
|
ECIES_nistP256_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
ECIES_brainpoolP256r1_with_AES 128_CCM
|
-
|
-
|
X
|
X
|
X
|
|
X kennzeichnet die verbindliche Unterstützung
|
Tabelle 7: Generierung von Schlüsselpaaren und Nutzung des privaten Schlüssels für die Entschlüsselung von Enrollment- und Berechtigungsanträgen und den Antworten darauf
6.1.4.3.Krypto-Agilität
(319)Die Anforderungen an Schlüssellängen und Algorithmen müssen im Zeitablauf geändert werden, damit ein angemessenes Sicherheitsniveau aufrechterhalten wird. Die CPA überwacht die Notwendigkeit solcher Änderungen unter Berücksichtigung tatsächlicher Gefährdungen und der neusten Entwicklungen in der Kryptografie. Sie wird eine Aktualisierung dieser Certificate Policy entwerfen, genehmigen und veröffentlichen, wenn sie beschließt, dass die kryptografischen Algorithmen aktualisiert werden sollten. Wird mit einer neuen Ausgabe dieser Certificate Policy (CP) eine Änderung des Algorithmus und/oder der Schlüssellänge angekündigt, führt die CPA eine Migrationsstrategie mit Übergangsfristen ein, während der die alten Algorithmen und Schlüssellängen weiter unterstützt werden müssen.
(320)Um die Übertragung auf neue Algorithmen und/oder Schlüssellängen zu ermöglichen und zu erleichtern, wird empfohlen, dass alle PKI-Teilnehmer Hardware und/oder Software implementieren, die zu einer Umstellung der Schlüssellängen und Algorithmen in der Lage ist.
(321)Änderungen der Wurzel- und TLM-Zertifikate werden mit Hilfe von Link-Zertifikaten (siehe Abschnitt 4.6) unterstützt und durchgeführt; Link-Zertifikate werden zur Überbrückung des Übergangszeitraums zwischen alten und neuen Wurzelzertifikaten genutzt („Migration des Trust Models“).
6.1.5.Sichere Speicherung privater Schlüssel
In diesem Abschnitt werden die Anforderungen an die sichere Speicherung und Generierung von Schlüsselpaaren und Zufallsnummern für CA und Endteilnehmer beschrieben. Diese Anforderungen werden für kryptografische Module festgelegt und in den folgenden Unterabschnitten beschrieben.
6.1.5.1.Root-CA-, Sub-CA- und TLM-Ebene
(322)Ein kryptografisches Modul ist für Folgendes zu verwenden:
·Generierung, Nutzung, Verwaltung und Speicherung privater Schlüssel;
·Generierung und Verwendung von Zufallszahlen (die Bewertung der Funktion zur Generierung von Zufallszahlen ist Bestandteil der Sicherheitsevaluierung und -zertifizierung);
·Erstellung von Sicherungen (Backups) privater Schlüssel gemäß Abschnitt 6.1.6;
·Löschung privater Schlüssel.
Das kryptografische Modul wird mit einem der folgenden Schutzprofile (PP) zertifiziert, wobei die Vertrauenszusicherungsebene EAL-4 oder höher ist:
·Schutzprofile für HSM:
·CEN EN 419 221-2: Schutzprofile für die kryptografischen Module von TSP – Teil 2: Kryptografisches Modul für CSP-Signaturvorgänge mit Backup;
·CEN EN 419 221-4: Schutzprofile für die kryptografischen Module von TSP – Teil 4: Kryptografisches Modul für CSP-Signaturvorgänge ohne Backup;
·CEN EN 419 221-5: Schutzprofile für die kryptografischen Module von TSP – Teil 5: Kryptografisches Modul für Vertrauensdienste;
·Schutzprofile für Smartcards:
·CEN EN 419 211-2: Schutzprofile für sichere Signaturerstellungseinheiten – Teil 2: Gerät mit Schlüsselgenerierung;
·CEN EN 419 211-3: Schutzprofile für sichere Signaturerstellungseinheiten – Teil 3: Gerät mit Schlüsselimport.
Für den manuellen Zugriff auf das kryptografische Modul ist eine zwei-Faktoren-Authentifizierung vom Administrator erforderlich. Darüber hinaus ist die Beteiligung von zwei berechtigten Personen erforderlich.
Mit der Implementierung eines kryptografischen Moduls wird sichergestellt, dass außerhalb des kryptografischen Moduls kein Zugang zu Schlüsseln möglich ist. Das kryptografische Modul umfasst einen Zugangskontrollmechanismus zur Verhinderung einer unbefugten Nutzung privater Schlüssel.
6.1.5.2.Endteilnehmer
(323)Ein kryptografisches Modul für Endteilnehmer (EE) ist für Folgendes zu verwenden:
·Generierung, Nutzung, Verwaltung und Speicherung privater Schlüssel;
·Generierung und Verwendung von Zufallszahlen (die Bewertung der Funktion zur Generierung von Zufallszahlen ist Bestandteil der Sicherheitsevaluierung und -zertifizierung);
·sichere Löschung eines privaten Schlüssels.
(324)Das kryptografische Modul ist vor unbefugter Entfernung, Ersetzung und Änderung zu schützen. Sämtliche Schutzprofile und zugehörigen Unterlagen, die für die Sicherheitszertifizierung des kryptografischen Moduls gelten, werden nach ISO 15408 bewertet, validiert und zertifiziert, wobei die Vereinbarung über die gegenseitige Anerkennung von IT-Sicherheitszertifikaten der Gruppe Hoher Beamter für Informationssicherheit (SOG-IS) oder ein gleichwertiges europäisches System für die Cybersicherheitszertifizierung innerhalb des einschlägigen europäischen Cybersicherheitsrahmens anzuwenden ist.
(325)Da es wichtig ist, das höchstmögliche Sicherheitsniveau aufrechtzuerhalten, werden Sicherheitszertifikate für das kryptografische Modul im Rahmen der Regelung zur Zertifizierung nach gemeinsamen Kriterien (Common Criteria) (ISO 15408) ausgestellt von einer Konformitätsbewertungsstelle, die vom Managementausschuss im Rahmen der SOG-IS-Abkommen anerkannt wird, oder von einer Konformitätsbewertungsstelle, die bei einer nationalen Cybersicherheitszertifizierungsbehörde eines Mitgliedstaats akkreditiert ist. Eine solche Konformitätsbewertungsstelle muss Bedingungen für die Sicherheitsevaluierung erfüllen, die denen nach dem SOG-IS-Abkommen zur gegenseitigen Anerkennung mindestens gleichwertig sind.
Anmerkung: der Link zwischen dem kryptografischen Modul und der C-ITS-Station ist zu schützen.
6.1.6.Backup von privaten Schlüsseln
(326)Die Generierung, Speicherung und Nutzung von Backups privater Schlüssel muss mindestens den Sicherheitsanforderungen genügen, die für die Originalschlüssel erforderlich sind.
(327)Backups privater Schlüssel werden von Root-CA, EA und AA erstellt.
(328)Für EC und AT werden keine Backups privater Schlüssel erstellt.
6.1.7.Vernichtung privater Schlüssel
(329)Root-CA, EA, AA sowie mobile und ortsfeste C-ITS-Stationen vernichten ihren privaten Schlüssel und alle entsprechenden Backups, wenn ein neues Schlüsselpaar und ein entsprechendes Zertifikat generiert und erfolgreich installiert worden ist, und die Überlappungszeit (wenn überhaupt, dann nur bei nur CA) verstrichen ist. Private Schüssel werden mit Hilfe des Mechanismus vernichtet, den das für die Schlüsselspeicherung verwendete kryptografische Modul bietet, oder die Vernichtung erfolgt gemäß Beschreibung in dem entsprechenden, in Abschnitt 6.1.5.2 beschriebenen Schutzprofil (PP).
6.2.Aktivierungsdaten
(330)Aktivierungsdaten beziehen sich auf Authentifizierungsfaktoren, die für den Betrieb von kryptografischen Modulen erforderlich sind, um unbefugten Zugang zu verhindern. Die Nutzung der Aktivierungsdaten eines kryptografischen Geräts einer Wurzelzertifizierungsstelle (CA) erfordert das Tätigwerden von zwei befugten Personen.
6.3.Computer-Sicherheitskontrollen
(331)Die Computersicherheitskontrollen der CA werden dem hohen Sicherheitsniveau entsprechend unter Einhaltung der Anforderungen der ISO/IEC 27002 konzipiert.
6.4.Lebenslange technische Kontrollen
(332)Die technischen Kontrollen der CA erstrecken sich über den gesamten Lebenszyklus der CA, wobei dies insbesondere die Anforderungen in Abschnitt 6.1.4.3 („Krypto-Agilität“) einschließt.
6.5.Kontrollen der Netzsicherheit
(333)Die Netze der CA (Root-CA, EA und AA) werden im Einklang mit den Anforderungen und Durchführungsleitlinien der ISO/IEC 27001 und ISO/IEC 27002 gegen Angriffe widerstandsfähig gemacht.
(334)Die Verfügbarkeit der CA-Netze werden unter Berücksichtigung des geschätzten Verkehrsaufkommens konzipiert.
7.Zertifikatprofile, CRL und CTL
7.1.Zertifikatprofil
(335)Die in [5] definierten Zertifikatprofile werden für TLM, Wurzelzertifikate, EA-Zertifikate, AA-Zertifikate, AT und EC verwendet. Die staatlichen EA in den einzelnen Ländern können für Enrollment-Berechtigungsnachweise (EC) andere Zertifikatprofile nutzen.
(336)In den Zertifikaten von Root-CA, EA und AA werden die Genehmigungen angegeben, für die diese CA (Root-CA, EA und AA) Zertifikate ausstellen dürfen.
(337)Auf der Grundlage von [5]:
·nutzt jede Root-CA ihren eigenen privaten Signaturschlüssel zur Ausstellung von CRL;
·der TLM verwendet seinen eigenen privaten Signatur-Schlüssel zur Ausstellung der ECTL.
7.2.Gültigkeit von Zertifikaten
(338)Alle C-ITS-Zertifikatprofile enthalten ein Ausstellungs- und ein Ablaufdatum, die die Gültigkeitsdauer des Zertifikats darstellen. Auf den einzelnen PKI-Ebenen werden die Zertifikate rechtzeitig vor ihrem Ablauf generiert.
(339)Die Gültigkeitsdauer der CA- und EC-Zertifikate schließt eine Überlappungszeit ein. TLM- und Root-CA-Zertifikate werden frühestens drei Monate und spätestens einen Monat vor Beginn ihrer Gültigkeit ausgestellt (basierend auf dem Laufzeitbeginn laut Zertifikat) und auf die ECTL (Liste vertrauenswürdiger europäischer Zertifikate) gesetzt. Diese Phase des Ladens der Anfangsgrößen wird für die sichere Verteilung der Zertifikate an alle entsprechenden Vertrauenden Dritten gemäß Abschnitt 2.2 benötigt. Dadurch wird sichergestellt, dass alle Vertrauenden Dritten ab dem Beginn der Überlappungszeit bereits in der Lage sind, mit einem neuen Zertifikat herausgegebene Meldungen zu verifizieren.
(340)Zu Beginn der Überlappungszeit werden die aufeinanderfolgenden CA-, EC- und AT-Zertifikate ausgestellt (sofern zutreffend), an die entsprechenden Vertrauenden Dritten verteilt und von diesen installiert. Während der Überlappungszeit werden die aktuellen Zertifikate nur zu Verifizierungszwecken genutzt.
(341)Da die in Tabelle 8 aufgeführten Gültigkeitsdauern die Gültigkeitsdauern der jeweils übergeordneten Zertifikate nicht überschreiten dürfen, gelten folgende Einschränkungen:
·maximumvalidity [maximale Gültigkeit] (Root-CA) = privatekeyusage [Privatschlüsselnutzung] (Root-CA) + maximumvalidity [maximale Gültigkeit] (EA, AA);
·maximumvalidity [maximale Gültigkeit] (EA) = privatekeyusage [Privatschlüsselnutzung] (EA) + maximumvalidity [maximale Gültigkeit] (EC);
·maximumvalidity [maximale Gültigkeit] (AA) = privatekeyusage [Privatschlüsselnutzung] (AA) + [Zeitraum zum Laden der Anfangsgrößen] (AT).
(342)Die Gültigkeit der Link-Zertifikate (Root und TLM) beginnt mit der Nutzung des entsprechenden Privatschlüssels und endet mit der maximalen Gültigkeitsdauer der Root-CA oder des TLM.
(343)Tabelle 8 sind die maximalen Gültigkeitsdauern für C-ITS-CA-Zertifikate zu entnehmen (die Gültigkeitsdauern von AT sind Abschnitt 7.2.1 zu entnehmen).
|
Stelle
|
Max. Nutzungszeitsaum für private Schlüssel
|
Maximale Gültigkeitsdauer
|
|
Root-CA
|
3 Jahre
|
8 Jahre
|
|
EA
|
2 Jahre
|
5 Jahre
|
|
AA
|
4 Jahre
|
5 Jahre
|
|
EC
|
3 Jahre
|
3 Jahre
|
|
TLM
|
3 Jahre
|
4 Jahre
|
Tabelle 8: Gültigkeitsdauer der Zertifikate im Rahmen des C-ITS Trust Models
7.2.1.Pseudonym-Zertifikate
(344)In diesem Zusammenhang werden Pseudonyme durch Berechtigungstickets (AT) umgesetzt. Folglich bezieht sich dieser Abschnitt auf AT und nicht auf Pseudonyme.
(345)Die Anforderungen dieses Abschnitts gelten nur für AT mobiler C-ITS-Stationen, die CAM- und DENM-Benachrichtigungen senden und bei denen datenschutzrechtliche Risiken im Zusammenhang mit dem Standort zutreffen. Für die AT für ortsfeste C-ITS-Stationen und mobile C-ITS-Stationen, die für besondere Aufgaben eingesetzt werden und bei denen keine datenschutzrechtlichen Risiken im Zusammenhang mit dem Standort zutreffen, (z-. B. gekennzeichnete Einsatzfahrzeuge und Fahrzeuge der Strafverfolgungsbehörden) gelten keine besonderen Anforderungen an AT-Zertifikate.
(346)Es gelten folgende Begriffsbestimmungen:
·„Gültigkeitsdauer für AT“ – der Zeitraum, für den ein AT (Berechtigungsticket) gültig ist, d. h. der Zeitraum zwischen dem Anfangs- und dem Ablaufdatum des AT;
·„Zeitraum des Ladens der Anfangsgrößen für AT“ – unter dem Laden der Anfangsgrößen wird die Möglichkeit für C-ITS-Stationen verstanden, AT bereits vor dem Beginn der Gültigkeitsdauer zu erhalten. Der Zeitraum des Ladens der Anfangsgrößen ist der höchstzulässige Zeitraum zwischen der Beantragung von AT bis zum Ende des letzten Gültigkeitsdatums beantragter AT;
·„Nutzungszeitraum für AT“ – der Zeitraum, in dem ein AT effektiv zur Signierung von CAM/DENM-Benachrichtigungen genutzt wird;
·„maximale Anzahl paralleler AT“ – die Anzahl der AT, aus denen eine C-ITS-Station zu einem beliebigen Zeitpunkt zur Signierung einer CAM-/DENM-Benachrichtigung auswählen kann, d. h. die Anzahl verschiedener AT, die an eine C-ITS-Station ausgegeben werden und gleichzeitig gültig sind.
(347)Es gelten die folgenden Anforderungen:
·der Zeitraum des Ladens der Anfangsgrößen für AT darf drei Monate nicht überschreiten;
·die Gültigkeitsdauer für AT darf eine Woche nicht überschreiten;
·die Höchstzahl paralleler AT darf pro C-ITS-Station 100 nicht überschreiten;
·die Nutzungsdauer eines AT hängt davon ab, welche Strategie bei AT-Wechseln verfolgt wird und wie lange ein Fahrzeug in Betrieb ist; sie wird aber durch die maximale Anzahl paralleler AT und die Gültigkeitsdauer begrenzt. Konkret entspricht die durchschnittliche Nutzungsdauer für eine C-ITS-Station mindestens der Betriebszeit des Fahrzeugs während einer Gültigkeitsdauer, geteilt durch die Höchstzahl paralleler AT.
7.2.2.Berechtigungstickets für ortsfeste C-ITS-Stationen
(348)Es gelten die Begriffsbestimmungen in Abschnitt 7.2.1 und die folgenden Anforderungen:
·der Zeitraum des Ladens der Anfangsgrößen für AT darf drei Monate nicht überschreiten;
·die Höchstzahl paralleler AT darf pro C-ITS-Station zwei nicht überschreiten.
7.3.Sperrung von Zertifikaten
7.3.1.Sperrung von CA-, EA- und AA-Zertifikaten
Root-CA-, EA- und AA-Zertifikate können gesperrt werden. Gesperrte Zertifikate von Root-CA, EA und AA werden so bald wie möglich unter Vermeidung unangemessener Verzögerungen auf einer Zertifikatssperrliste (CRL) veröffentlicht. Diese CRL wird von der entsprechenden Root-CA signiert und verwendet das in Abschnitt 7.4 beschriebene Profil. Zur Sperrung von Zertifikaten einer Root-CA gibt die entsprechende Root-CA eine CRL heraus, auf der sie selbst steht. Darüber hinaus gilt für Fälle einer Sicherheitskompromittierung Abschnitt 5.7.3. Darüber hinaus streicht der TLM gesperrte CA aus der Trust List und gibt eine neue Trust List heraus. Abgelaufene Zertifikate sind aus dem entsprechenden CRL und der Liste vertrauenswürdiger Zertifikate zu streichen.
(349)Zertifikate werden gesperrt, wenn:
·die Root-CA Grund zu der Annahme oder dem starken Verdacht haben, dass der entsprechende private Schlüssel kompromittiert wurde;
·der Root-CA mitgeteilt wurde, dass der Vertrag mit dem Abonnenten beendet worden ist;
·Angaben (beispielsweise Name und Verbindungen zwischen CA und Subjekt) im Zertifikat falsch sind oder sich geändert haben;
·ein Sicherheitsvorfall eintritt, der sich auf den Zertifikatsinhaber auswirkt;
·ein Audit (siehe Abschnitt 8) zu einem negativen Ergebnis führt.
(350)Der Abonnent unterrichtet die CA unverzüglich über eine bekannte oder vermutete Kompromittierung seines privaten Schlüssels. Es muss sichergestellt sein, dass nur authentifizierte Anträge zu gesperrten Zertifikaten führen.
7.3.2.Sperrung von Enrollment-Berechtigungsnachweisen
(351)Die Sperrung von Enrollment-Berechtigungsnachweisen (EC) kann vom Abonnenten der C-ITS-Station ausgelöst werden (Ablauf 34) und wird mittels einer internen schwarzen Liste in einer Datenbank für Sperrungen mit einem Zeitstempel umgesetzt, die von den einzelnen EA generiert und gepflegt wird. Die schwarze Liste wird nie veröffentlicht und ist vertraulich zu behandeln; sie wird nur von der entsprechenden EA verwendet, um im Zusammenhang mit Anträgen auf AT und neue EC die Gültigkeit der entsprechenden EC zu verifizieren.
7.3.3.Sperrung von Berechtigungstickets
(352)Da AT nicht von entsprechenden CA gesperrt werden, habe sie eine kurze Laufzeit und dürfen nicht zu lange bevor sie gültig werden ausgestellt werden. Die zulässigen Werte für den Lebenszyklusparameter des Zertifikats werden in Abschnitt 7.2 dargelegt.
7.4.Zertifikatssperrliste
(353)Format und Inhalt der von der Root-CA herausgegebenen Zertifikatsperrliste (CRL) entsprechen den in [1] festgelegten Werten.
7.5.European Certificate Trust List (Liste vertrauenswürdiger europäischer Zertifikate)
(354)Format und Inhalt der vom TLM herausgegebenen Zertifikatsperrliste (CRL) entsprechen den in [1] festgelegten Werten.
8.Compliance-Audits und andere Bewertungen
8.1.Audit-Themen und Audit-Grundlage
(355)Der Zweck von Compliance-Audits besteht darin, zu verifizieren, ob TLM, Root-CA, EA und AA nach der vorliegenden Certificate Policy (CP) arbeiten. Die TLM, Root-CA, EA und AA wählen für den Audit ihrer Erklärung zum Zertifizierungsbetrieb (CPS) einen unabhängig handelnden, akkreditierten PKI-Prüfer. Der Audit wird mit einer Bewertung nach ISO/IEC 27001 und ISO/IEC 27002 kombiniert.
(356)Für eine Root-CA werden Compliance-Audits von der Root-CA selbst (Ablauf 13) und für eine Sub-CA von deren untergeordneten EA/AA angeordnet.
(357)Ein Compliance-Audit für den TLM wird von der CPA angeordnet (Ablauf 38).
(358)Auf entsprechendes Ersuchen führt ein akkreditierter PKI-Prüfer einen Compliance-Audit auf einer der folgenden Ebenen durch:
(1)Konformität der CPS von TLM, Root-CA, EA oder AA mit dieser Certificate Policy (CP);
(2)Konformität der vorgesehenen Praktiken von TLM, Root-CA, EA oder AA mit deren CPS, vor der Aufnahme des Betriebs;
(3)Konformität der Praktiken und betrieblichen Tätigkeiten von TLM, Root-CA, EA oder AA mit deren CPS, während des Betriebs.
(359)Der Audit erstreckt sich auf alle in der vorliegenden Certificate Policy (CP) aufgeführten, von den zum Audit vorgesehenen TLM, Root-CA, EA oder AA zu erfüllenden Anforderungen. Sie umfasst darüber hinaus den Betrieb der CA in der PKI der C-ITS einschließlich aller in deren CPS erwähnten Prozesse, der Räumlichkeiten und der verantwortlichen Personen.
(360)Der akkreditierte PKI-Prüfer legt der Root-CA (Ablauf 36), EA, AA oder CPA (Ablauf 16 und 40), wie jeweils zutreffend, einen ausführlichen Bericht über den Audit vor.
8.2.Häufigkeit der Audits
(361)Root-CA, TLM, EA oder AA beauftragen in den folgenden Fällen einen akkreditierten PKI-Prüfung mit einer Compliance-Prüfung an sich selbst:
·bei ihrer ursprünglichen Einrichtung (Compliance der Stufen 1 und 2);
·bei jeder Änderung der CP. Die CPA legt den Inhalt der CP-Änderung und den Zeitplan für deren Einsatz fest und bestimmt den Audit-Bedarf dementsprechend (einschließlich der erforderlichen Compliance-Stufe);
·bei jeder Änderung ihrer CPS (Compliance-Stufen 1, 2 und 3). Da die Verwaltungsstellen von Root-CA TLM und EA/AA entscheiden, welche Änderungen bei der Umsetzung sich aus der Aktualisierung ihrer Erklärung zum Zertifizierungsbetrieb (CPS) ergeben, geben sie einen Compliance-Audit in Auftrag, bevor sie die betreffenden Änderungen umsetzen. Bei nur geringfügigen Änderungen der CPS (z. B. redaktioneller Art) kann die Verwaltungsstelle bei der CPA in einem ordnungsgemäß begründeten Antrag um die Genehmigung bitten, Compliance-Audits der Stufe 1, 2 oder 3 überspringen zu dürfen;
·regelmäßig, mindestens jedoch alle drei Jahre während des Betriebs (Compliance der Stufe 3).
8.3.Identität/Qualifikation des Prüfers
(362)Die zu prüfende CA wählt ein(n) unabhängig handelnde(s), akkreditierte(s) Unternehmen/Organisation („Audit-Stelle“) oder akkreditierte PKI-Prüfer für ihren Audit nach vorliegender Certificate Policy (CP) aus. Die Audit-Stelle wird von einem Mitglied der European Accreditation akkreditiert und zertifiziert.
8.4.Beziehung des Prüfers zur geprüften Stelle
(363)Der akkreditierte PKI-Prüfer muss von der geprüften Stelle unabhängig sein.
8.5.Aufgrund von Mängeln getroffene Maßnahmen
(364)Wird in einem Auditbericht mangelnde Compliance eines TLM festgestellt, erteilt die CPA dem TLM eine Anordnung, umgehend Vorbeugungs- bzw. Korrekturmaßnahmen zu treffen.
(365)Stellt eine Root-CA, in deren Auditbericht mangelnde Compliance festgestellt wurde, einen neuen Antrag, lehnt die CPA den Antrag ab und übermittelt der Root-CA eine entsprechenden Ablehnungsbescheid (Ablauf 4). In derartigen Fällen wird die Root-CA suspendiert. Sie muss Korrekturmaßnahmen treffen, den Audit erneut in Auftrag geben und einen erneuten Antrag auf Genehmigung durch die CPA stellen. Die Root-CA darf nicht zulassen, dass während der Suspendierung Zertifikate ausgestellt werden.
(366)Bei einem regulären Audit einer Root-CA oder bei einer Änderungen an der CPS einer Root-CA kann die CPA je nach Art der im Auditbericht beschriebenen Nichtkonformität entscheiden, die Root-CA zu sperren und diese Entscheidung dem TLM mitzuteilen (Ablauf 2) und so die Streichung des Zertifikats der Root-CA aus der ECTL und die Aufnahme der Root-CA in die Zertifikatssperrliste (CRL) veranlassen. Die CPA übermittelt der Root-CA einen entsprechenden Ablehnungsbescheid (Ablauf 4). Die Root-CA muss Korrekturmaßnahmen treffen, erneut einen umfassenden Audit (Stufen 1 bis 3) in Auftrag geben und einen neuen Antrag auf die Genehmigung durch die CPA stellen. Alternativ kann die CPA beschließen, die Root-CA nicht zu sperren, sondern ihr eine Nachfrist zu gewähren, in der die Root-CA Korrekturmaßnahmen trifft, erneut einen Audit in Auftrag gibt und den Auditbericht erneut bei der CPA einreicht. In diesem Fall muss der Betrieb der Root-CA ausgesetzt werden und ihr ist es nicht gestattet, Zertifikate und CRL auszustellen.
(367)Im Falle Audits von EA/AA entscheidet die Root-CA, ob sie den Bericht annimmt oder nicht. Je nach Ergebnis des Audits entscheidet die Root-CA, ob sie das EA-/AA-Zertifikat gemäß den Vorschriften in der Erklärung zum Zertifizierungsbetrieb (CPS) der Root-CA sperrt. Die Root-CA stellt jederzeit sicher, dass EA/AA die vorliegende Certificate Policy (CP) einhalten.
8.6.Mitteilung der Ergebnisse
(368)Root-CA und der TLM übermitteln den Auditbericht an die CPA (Ablauf 16). Die Root-CA und der TLM speichern alle Berichte über von ihnen in Auftrag gegebene Audits. Die CPA übermittelt der Root-CA und dem TLM eine entsprechende Genehmigung oder Ablehnung (Ablauf 4).
(369)Die Root-CA sendet der entsprechenden EA/AA ein Konformitätszertifikat.
9.Sonstige Bestimmungen
9.1.Gebühren
(370)Ein Grundsatz des implementierten C-ITS Trust Models der EU besteht darin, dass die Root-CA gemeinsam für die vollständige Finanzierung der regelmäßigen laufenden Betriebskosten der CPA und der zentralen Elemente (TLM und CPOC), die im Zusammenhang mit den in der vorliegenden Certificate Policy (CP) dargelegten Tätigkeiten anfallen, sorgen.
(371)Die Root-CA (einschließlich der Root-CA der EU) sind berechtigt, bei ihren Sub-CA Gebühren zu erheben.
(372)Jeder Teilnehmer des C-ITS Trust Models erhält während des gesamten Betriebszeitraums diskriminierungsfrei Zugang zu mindestens einer Root-CA, EA und AA.
(373)Jede Root-CA ist berechtigt, die von ihr für die CPA und die zentralen Elemente (TLM und CPOC) gezahlten Gebühren auf die registrierten Teilnehmer des C-ITS Trust Models einschließlich der angemeldeten und autorisierten C-ITS-Stationen umzulegen.
9.2.Finanzielle Verantwortlichkeiten
(374)Die erstmalige Einrichtung einer Root-CA erstreckt sich über einen Zeitraum von mindestens drei Jahren, damit sie Mitglied des C-ITS Trust Models der EU werden kann. Die CPS eines Root-CA-Betreibers enthält auch ausführliche Bestimmungen über die Sperrung oder Schließung von Root-CA.
(375)Jede Root-CA muss die finanzielle Tragfähigkeit der juristischen Person nachweisen, von der sie mindestens drei Jahre lang implementiert wird. Dieser Plan für die finanzielle Tragfähigkeit ist Bestandteil des anfänglichen Satzes von für das Enrollment erforderlichen Unterlagen und muss alle drei Jahre aktualisiert und der CPA gemeldet werden.
(376)Jede Root-CA muss zum Nachweis ihrer finanziellen Nachhaltigkeit der Betriebsleitung und der CPA jedes Jahr die Gebührenstruktur melden, die für die EA/AA und die angemeldeten und autorisierten C-ITS-Stationen gelten.
(377)Alle finanziell und rechtlich verantwortlichen Stellen der Root-CA, EA, AA und der zentralen Elemente (CPOC und TLM) des C-ITS Trust Models müssen ihre betrieblichen Pflichten durch Versicherungen in angemessener Höhe abdecken, um eine Entschädigung für betriebliche Fehler und einen finanziellen Ausgleich für ihre Pflichten erzielen zu können, falls eines der technischen Elemente ausfallen sollte.
9.3.Vertraulichkeit von Geschäftsinformationen
(378)Folgende Angaben sind vertraulich zu behandeln und zu schützen:
·Antragsaufzeichnungen, ob gebilligt oder abgelehnt, von Root-CA, EA, AAA;
·Auditberichte von Root-CA, EA, AA und TLM;
·Pläne der Datenwiederherstellung im Falle eines Systemabsturzes von Root-CA, EA, AA, CPOC und TLM;
·private Schlüssel der Elemente des C-ITS Trust Models (C-ITS-Stationen, TLM, EA, AA, Root-CA);
·sonstige von der CPA sowie den Root-CA, A, AA, TLM und CPOC. als vertraulich eingestufte Informationen.
9.4.Datenschutzplan
(379)In den CPS der Root-CA und der EA/AA werden der Datenschutzplan und die Anforderungen an die Behandlung personenbezogener Angaben und den Datenschutz auf der Grundlage der DSGVO und anderer anwendbarer gesetzlicher Rahmen (z. B. nationale Rechtvorschriften) dargelegt.
10.Referenzdokumente
In diesem Anhang werden folgende Referenzdokumente herangezogen:
|
[1]
|
ETSI TS 102 941 V1.2.1, Intelligent transport systems (ITS) – security, trust and privacy management.
|
|
[2]
|
ETSI TS 102 940 V1.3.1, Intelligent transport systems (ITS) – security, ITS communications security architecture and security management.
|
|
[3]
|
Certificate policy and certification practices framework (RFC 3647, 1999).
|
|
[4]
|
ETSI TS 102 042 V2.4.1 Policy requirements for certification authorities issuing public key certificates.
|
|
[5]
|
ETSI TS 103 097 V1.3.1, Intelligent transport systems (ITS) – security, security header and certificate formats.
|
|
[6]
|
Calder, A. (2006). Information security based on ISO 27001/ISO 1779: a management guide. Van Haren Publishing.
|
|
[7]
|
ISO, I., & Std, I. E. C. (2011). ISO 27005 (2011): Informationstechnik - IT-Sicherheitsverfahren - Informationssicherheits-Risikomanagement. ISO.
|
|
|
|
