DE112020006966T5 - Wahrnehmung über dynamische kontextbezogene strassenbelegungskarten für die sicherheit ungeschützter verkehrsteilnehmer in intelligenten transportsystemen - Google Patents

Wahrnehmung über dynamische kontextbezogene strassenbelegungskarten für die sicherheit ungeschützter verkehrsteilnehmer in intelligenten transportsystemen Download PDF

Info

Publication number
DE112020006966T5
DE112020006966T5 DE112020006966.4T DE112020006966T DE112020006966T5 DE 112020006966 T5 DE112020006966 T5 DE 112020006966T5 DE 112020006966 T DE112020006966 T DE 112020006966T DE 112020006966 T5 DE112020006966 T5 DE 112020006966T5
Authority
DE
Germany
Prior art keywords
vru
vam
cluster
data
dcrom
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112020006966.4T
Other languages
English (en)
Inventor
Vesh Raj Sharma Banjade
Kathiravetpillai Sivanesan
Satish C. Jha
Leonardo Gomes Baltar
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112020006966T5 publication Critical patent/DE112020006966T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/161—Decentralised systems, e.g. inter-vehicle communication
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00—Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B60W30/08—Active safety systems predicting or avoiding probable or impending collision or attempting to minimise its consequences
    • B60W30/095—Predicting travel path or likelihood of collision
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W30/00—Purposes of road vehicle drive control systems not related to the control of a particular sub-unit, e.g. of systems using conjoint control of vehicle sub-units
    • B60W30/08—Active safety systems predicting or avoiding probable or impending collision or attempting to minimise its consequences
    • B60W30/09—Taking automatic action to avoid collision, e.g. braking and steering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06V—IMAGE OR VIDEO RECOGNITION OR UNDERSTANDING
    • G06V20/00—Scenes; Scene-specific elements
    • G06V20/50—Context or environment of the image
    • G06V20/56—Context or environment of the image exterior to a vehicle by using sensors mounted on the vehicle
    • G06V20/58—Recognition of moving objects or obstacles, e.g. vehicles or pedestrians; Recognition of traffic objects, e.g. traffic signs, traffic lights or roads
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096708—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control
    • G08G1/096725—Systems involving transmission of highway information, e.g. weather, speed limits where the received information might be used to generate an automatic action on the vehicle control where the received information generates an automatic action on the vehicle control
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/09—Arrangements for giving variable traffic instructions
    • G08G1/0962—Arrangements for giving variable traffic instructions having an indicator mounted inside the vehicle, e.g. giving voice messages
    • G08G1/0967—Systems involving transmission of highway information, e.g. weather, speed limits
    • G08G1/096766—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission
    • G08G1/096791—Systems involving transmission of highway information, e.g. weather, speed limits where the system is characterised by the origin of the information transmission where the origin of the information is another vehicle
    • G—PHYSICS
    • G08—SIGNALLING
    • G08G—TRAFFIC CONTROL SYSTEMS
    • G08G1/00—Traffic control systems for road vehicles
    • G08G1/16—Anti-collision systems
    • G08G1/166—Anti-collision systems for active traffic, e.g. moving vehicles, pedestrians, bikes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/30—Services specially adapted for particular environments, situations or purposes
    • H04W4/40—Services specially adapted for particular environments, situations or purposes for vehicles, e.g. vehicle-to-pedestrians [V2P]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/90—Services for handling of emergency or hazardous situations, e.g. earthquake and tsunami warning systems [ETWS]
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
    • B60R21/00—Arrangements or fittings on vehicles for protecting or preventing injuries to occupants or pedestrians in case of accidents or other traffic risks
    • B60R21/01—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents
    • B60R21/013—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents including means for detecting collisions, impending collisions or roll-over
    • B60R21/0134—Electrical circuits for triggering passive safety arrangements, e.g. airbags, safety belt tighteners, in case of vehicle accidents or impending vehicle accidents including means for detecting collisions, impending collisions or roll-over responsive to imminent contact with an obstacle, e.g. using radar systems
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2554/00—Input parameters relating to objects
    • B60W2554/40—Dynamic objects, e.g. animals, windblown objects
    • B60W2554/404—Characteristics
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle

Landscapes

  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Atmospheric Sciences (AREA)
  • Signal Processing (AREA)
  • Automation & Control Theory (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Business, Economics & Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Public Health (AREA)
  • Emergency Management (AREA)
  • Health & Medical Sciences (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)
  • Traffic Control Systems (AREA)

Abstract

Offenbarte Ausführungsformen beinhalten Technologien zum Verbessern von Sicherheitsmechanismen in computergestützt und/oder automatisiert fahrenden (CA-/AD-) Fahrzeugen zum Schutz ungeschützter Verkehrsteilnehmer (VRUs). Einige Ausführungsformen beinhalten eine dynamische kontextbezogene Straßenbelegungskarte (Dynamic Contextual Road Occupancy Map - DCROM) für Wahrnehmungsaspekte für VRU-Sicherheit. Andere Ausführungsformen werden beschrieben und/oder beansprucht.

Description

  • VERWANDTE ANMELDUNGEN
  • Die vorliegende Anmeldung beansprucht die Priorität der vorläufigen US-Anmeldung. Nr. 62/994,471 , eingereicht am 25. März 2020 (AC8655-Z) sowie der vorläufigen US-Anmeldung Nr. 63/033,597 , eingereicht am 2. Juni 2020 (AC8655-Z2), deren Inhalt hiermit jeweils in seiner Gesamtheit durch Bezugnahme aufgenommen wird.
  • TECHNISCHES GEBIET
  • Vorliegend beschriebene Ausführungsformen betreffen allgemein Edge-Computing-, Netzwerkkommunikations- und Kommunikationssystem-Implementierungen und insbesondere verbundene und computergestützte (CA, computer-assisted) bzw. autonom fahrende (AD, autonomous driving) Fahrzeuge, Internet-der-Fahrzeuge- (IoV-, internet ofvehicles), Internet-der-Dinge- (loT-, internet of things) Technologien und intelligente Transportsysteme.
  • HINTERGRUND
  • Intelligente Transportsysteme (ITS) umfassen fortgeschrittene Anwendungen und Dienste in Bezug auf unterschiedliche Transport- und Verkehrsmodi, um eine Erhöhung der Verkehrssicherheit und -effizienz zu ermöglichen und Emissionen und Kraftstoffverbrauch zu reduzieren. Verschiedene Formen von Drahtloskommunikation und/oder Funkzugangstechnologien (radio access technologies, RATs) können für ITS Verwendung finden. Diese RATs müssen möglicherweise in einem oder mehreren Kommunikationskanälen koexistieren, wie etwa jenen, die im 5,9-Gigahertz- (GHz) Band verfügbar sind. Bestehende RATs weisen keine Mechanismen auf, um miteinander zu koexistieren, und sind in der Regel nicht miteinander interoperabel.
  • Kooperative intelligente Transportsysteme (C-ITS, cooperative intelligent transport systems) wurden entwickelt, um eine Erhöhung der Verkehrssicherheit und -effizienz zu ermöglichen und Emissionen und Kraftstoffverbrauch zu reduzieren. Der anfängliche Fokus der C-ITS lag auf der Straßenverkehrssicherheit und insbesondere auf Fahrzeugsicherheit. In letzter Zeit werden Bemühungen unternommen, um Verkehrssicherheit und -effizienz für ungeschützte Verkehrsteilnehmer (VRUs, vulnerable road users) zu erhöhen, was sich auf physische Entitäten (z.B. Fußgänger) und/oder auf Benutzervorrichtungen (z.B. Mobilstationen usw.) bezieht, die von physischen Entitäten verwendet werden. Die Regelung (EU) Nr.„ 168/2013 des Europäischen Parlaments und des Rats vom 15. Januar 2013 zur Genehmigung und Marktüberwachung von zwei- oder dreirädrigen und vierrädrigen Fahrzeugen („EU-Regelung 168/2013 ") liefert verschiedene Beispiele für VRUs.
  • Es wird erwartet, dass computergestützte und/oder autonom fahrende (AD-) Fahrzeuge („CA/AD-Fahrzeuge“) durch Eliminieren oder Reduzieren menschlicher Fehler beim Betreiben von Fahrzeugen VRU-bezogene Verletzungen und Todesfälle reduzieren. Wenngleich sie mit einer ausgereiften Erkennungstechnologie-Suite sowie Rechen- und Kartierungstechnologien ausgestattet sind, können CA/AD-Fahrzeuge bisher jedoch nur sehr wenig in Bezug auf Erkennung, geschweige denn Korrektur menschlicher Fehler auf Seiten der VRUs ausrichten.
  • KURZBESCHREIBUNG DER ZEICHNUNGEN
  • In den Zeichnungen, die nicht notwendigerweise maßstabsgetreu gezeichnet sind, können gleiche Ziffern ähnliche Komponenten in verschiedenen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten repräsentieren. Einige Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der zugehörigen Zeichnungen veranschaulicht, wobei gilt:
  • 1 veranschaulicht eine Betriebsanordnung, in der verschiedene Ausführungsformen umgesetzt werden können. 2 veranschaulicht einen beispielhaften Ansatz mit geschichteten Belegungskarten zum Erstellen einer dynamischen kontextbezogenen Straßenbelegungskarte (dynamic contextual road occupancy map, DCROM) zur Wahrnehmung gemäß verschiedenen Ausführungsformen. 3 zeigt einen beispielhaften Prozess für VRU-Sicherheitsmechanismen gemäß verschiedenen Ausführungsformen. 4 veranschaulicht eine beispielhafte VRU-Sicherheitsprozedur gemäß verschiedenen Ausführungsformen. 5a, 5b, 5c, 5D und 5e veranschaulichen einen DCROP-Anwendungsfall gemäß verschiedenen Ausführungsformen. 6a und 6b veranschaulichen beispielhafte VRU-Bewusstmachungsnachrichten (VRU awareness messages, VAMs) gemäß verschiedenen Ausführungsformen. 7a, 7b und 7c veranschaulichen Beispiele für VRU-Cluster-Operationen gemäß verschiedenen Ausführungsformen. 8 veranschaulicht ein Beispiel für eine Gitterbelegungskarte, bei der eine Ego-VRU-ITS-S eine Ursprungs-ITS-S ist, gemäß verschiedenen Ausführungsformen. 9 veranschaulicht ein Beispiel für eine Gitterbelegungskarte, bei der eine Straßenrand- (roadside) ITS-S (R-ITS-S) eine Ursprungs-ITS-S ist, gemäß verschiedenen Ausführungsformen.
  • 10 zeigt eine beispielhafte ITS-S-Referenzarchitektur gemäß verschiedenen Ausführungsformen. 11 stellt ein beispielhaftes VRU-Basisdienst- (VRU basic service, VBS-) Funktionsmodell gemäß verschiedenen Ausführungsformen dar. 12 zeigt ein Beispiel für VBS-Zustandsmaschinen gemäß verschiedenen Ausführungsformen. 13 stellt eine beispielhafte Fahrzeug-ITS-Station (V-ITS-S) in einem Fahrzeugsystem gemäß verschiedenen Ausführungsformen dar. 14 stellt eine beispielhafte persönliche ITS-Station (P-ITS-S) dar, die gemäß verschiedenen Ausführungsformen als VRU-ITS-S verwendet werden kann. 15 stellt eine beispielhafte Straßenrand- (roadside) ITS-S in einem Straßenrand-Infrastrukturknoten gemäß verschiedenen Ausführungsformen dar.
  • 16 und 17 stellen beispielhafte Komponenten verschiedener Rechenknoten in einem oder mehreren Edge-Computing-Systemen dar. 18 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge Computing. 19 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. 20 veranschaulicht einen beispielhaften Ansatz für Vernetzung und Dienste in einem Edge-Computing-System. 21 veranschaulicht eine beispielhafte Softwareverteilungsplattform gemäß verschiedenen Ausführungsformen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Der Betrieb und die Steuerung von Fahrzeugen werden mit der Zeit autonomer, und die meisten Fahrzeuge werden wahrscheinlich in Zukunft vollständig autonom werden. Fahrzeuge, die irgendeine Form von Autonomie beinhalten oder anderweitig einen menschlichen Bediener unterstützen, können vorliegend als „computergestützte oder autonom fahrende“ Fahrzeuge bezeichnet werden. Computergestützte oder autonom fahrende (CA/AD-) Fahrzeuge können künstliche Intelligenz (AI), maschinelles Lernen (ML) und/oder andere ähnliche selbstlernende Systeme beinhalten, um autonomen Betrieb zu ermöglichen und/oder Fahrassistenzfähigkeiten bereitzustellen. Typischerweise nehmen diese Systeme ihre Umgebung wahr (z.B. unter Verwendung von Sensordaten) und führen verschiedene Aktionen durch, um die Wahrscheinlichkeit eines erfolgreichen Fahrzeugbetriebs zu maximieren.
  • Die Fahrzeug-zu-Alles- (V2X-) Anwendungen (einfach als „V2X“ bezeichnet) beinhalten die folgenden Arten von Kommunikationen: Fahrzeug-zu-Fahrzeug (V2V), Fahrzeug-zu-Infrastruktur (V2I) und/oder Infrastruktur-zu-Fahrzeug (I2V), Fahrzeug-zu-Netzwerk (V2N) und/oder Netzwerk-zu-Fahrzeug (N2V), Fahrzeug-zu-Fußgänger-Kommunikationen (V2P) und ITS-Station- (ITS-S-) zu-ITS-S-Kommunikation (X2X). V2X-Anwendungen können Cooperative Awareness (kooperatives/gemeinsames Bewusstsein) verwenden, um intelligentere Dienste für Endbenutzer bereitzustellen. Dies bedeutet, dass Entitäten, wie etwa Fahrzeugstationen oder Fahrzeugbenutzergeräte (vUEs), einschließlich etwa CA/AD-Fahrzeugen, Straßenrandinfrastruktur oder Straßenrandeinheiten (RSUs, roadside units), Anwendungsserver und Fußgängervorrichtungen (z.B. Smartphones, Tablets usw.), Wissen über ihre lokale Umgebung sammeln (z.B. Informationen, die von anderen Fahrzeugen oder Sensorgeräten in der Nähe empfangen werden), um dieses Wissen zu verarbeiten und gemeinsam zu nutzen, um intelligentere Dienste bereitzustellen, wie etwa kooperative Wahrnehmung, Manöverkoordination und dergleichen, die für Kollisionswarnsysteme, autonomes Fahren und/oder dergleichen verwendet werden.
  • Eine solche V2X-Anwendung beinhaltet intelligente Transportsysteme (ITS), die Systeme zum Unterstützen des Transports von Gütern und Menschen mit Informationen und Kommunikationstechnologien sind, um die Transportinfrastruktur und Transportmittel (z.B. Automobile, Züge, Flugzeuge, Wasserfahrzeuge usw.) effizient und sicher zu verwenden. Die Elemente von ITS werden in verschiedenen Standardisierungsorganisationen sowohl auf internationaler als auch auf regionaler Ebene standardisiert. Kommunikationen in ITS (ITSC) können eine Vielzahl von existierenden und neuen Zugangstechnologien (oder Funkzugangstechnologien (RATs) und ITS-Anwendungen nutzen. Zu Beispielen für diese V2X-RATs zählen IEEE- (Institute of Electrical and Electronics Engineers) RATs und 3GPP- (Third Generation Partnership) RATs. Zu den IEEE-V2X-RATs zählen zum Beispiel Wireless Access in Vehicular Environments (WAVE, Drahtloszugang in Fahrzeugumgebungen), Dedicated Short Range Communication (DSRC, dedizierte Nahbereichskommunikation), intelligente Transportsysteme im 5-GHz-Frequenzband (ITS-G5), das IEEE 802.1 1p-Protokoll (wobei es sich um Schicht 1 (L1) und Schicht 2 (L2) von WAVE, DSRC und ITS-G5 handelt) und bisweilen das IEEE 802.16-Protokoll, das als Worldwide Interoperability for Microwave Access (WiMAX) bezeichnet wird. Der Begriff „DSRC“ bezieht sich auf Fahrzeugkommunikationen im 5,9-GHz-Frequenzband, das im Allgemeinen in den Vereinigten Staaten verwendet wird, während sich „ITS-G5“ auf Fahrzeugkommunikationen im 5,9-GHz-Frequenzband in Europa bezieht. Da die vorliegenden Ausführungsformen auf eine beliebige Anzahl unterschiedlicher RATs (einschließlich IEEE 802.1 1p-basierter RATs) anwendbar sind, die in einem beliebigen geographischen oder politischen Gebiet verwendet werden können, können die Begriffe „DSRC“ (neben anderen Gebieten in den USA verwendet) und „ITS-G5“ (neben anderen Gebieten in Europa verwendet) in dieser Offenbarung durchweg austauschbar verwendet werden. Zu den 3GPP-V2X-RATs zählen zum Beispiel zellulares V2X (C-V2X, cellular V2X) unter Verwendung von LTE- (Long Term Evolution) Technologien (manchmal als „LTE-V2X“ bezeichnet) und/oder unter Verwendung von Technologien der 5. Generation (5G) (manchmal als „5G-V2X“ oder „NR-V2X“ bezeichnet). Andere RATs können für ITS- und/oder V2X-Anwendungen verwendet werden, wie etwa RATs, die UHF- und VHF-Frequenzen, GSM (Global System for Mobile Communications) und/oder andere Drahtloskommunikationstechnologien verwenden.
  • 1 veranschaulicht eine Übersicht einer Umgebung 100 zum Einbinden und Verwenden der Ausführungsformen der vorliegenden Offenbarung. Wie gezeigt, beinhaltet die beispielhafte Umgebung für die veranschaulichten Ausführungsformen Fahrzeuge 110A und 10B (gemeinsam „Fahrzeuge 110“). Die Fahrzeuge 110 beinhalten einen Motor, ein Getriebe, Achsen, Räder und so weiter (nicht gezeigt). Die Fahrzeuge 110 können eine beliebige Art von Kraftfahrzeugen sein, die zum Befördern von Personen oder Gütern verwendet werden, von denen jedes mit einem Motor, einem Getriebe, Achsen, Rädern sowie Steuersystemen ausgestattet ist, die zum Fahren, Parken, Passagierkomfort und/oder Sicherheit usw. verwendet werden. Die Begriffe „Motor“, „motorisiert“ usw., wie vorliegend verwendet, beziehen sich auf Vorrichtungen, die eine Form von Energie in mechanische Energie konvertieren, und beinhalten Verbrennungsmotoren (ICE), Kompressionsverbrennungsmotoren (CCE), Elektromotoren und Hybride (z.B. einschließlich eines ICE/CCE und Elektromotor(en)). Die mehreren in 1 gezeigten Fahrzeuge 1452 können Kraftfahrzeuge unterschiedlicher Fabrikate, Modelle, Verkleidung usw. repräsentieren.
  • Zur Veranschaulichung ist die folgende Beschreibung für Einsatzszenarien bereitgestellt, die Fahrzeuge 110 in einer 2D-Autobahn-/Fernstraßen-/Straßenumgebung beinhalten, wobei die Fahrzeuge 110 Automobile sind. Die hier beschriebenen Ausführungsformen sind jedoch auch auf andere Arten von Fahrzeugen anwendbar, wie etwa Lastkraftwagen, Busse, Motorboote, Motorräder, elektrische Personentransporter und/oder beliebige andere motorisierte Vorrichtungen, die in der Lage sind, Personen oder Güter zu transportieren. Zudem sind vorliegend beschriebene Ausführungsformen auf soziale Vernetzung zwischen Fahrzeugen unterschiedlicher Fahrzeugtypen anwendbar. Die vorliegend beschriebenen Ausführungsformen können auch auf 3D-Einsatzszenarien, bei denen einige oder alle der Fahrzeuge 110 als Flugobjekte implementiert sind, wie etwa Flugzeuge, Drohnen, UAVs, und/oder auf beliebige andere ähnliche motorisierte Vorrichtungen anwendbar sein.
  • Zur Veranschaulichung ist die folgende Beschreibung für beispielhafte Ausführungsformen bereitgestellt, bei denen die Fahrzeuge 110 fahrzeuginterne Systeme (IVSs, in-vehicle systems) 101 beinhalten, die nachstehend ausführlicher besprochen werden. Die Fahrzeuge 110 könnten jedoch zusätzliche oder alternative Arten von Rechenvorrichtungen/- systemen beinhalten, wie etwa Smartphones, Tablets, Wearables, Laptops, Laptop-Computer, fahrzeuginternes Infotainment-System, fahrzeuginternes Unterhaltungssystem, Instrumentencluster, Head-Up-Display-(HUD-) Vorrichtung, bordeigene Diagnosevorrichtung, mobile Dashtop-Ausrüstung, mobiles Datenendgerät, elektronisches Engine-Verwaltungssystem, elektronische/Engine-Steuereinheit, elektronisches/Engine-Steuermodul, eingebettetes System, Mikrocontroller, Steuermodul, Engine-Verwaltungssystem und dergleichen, die betreibbar sein können zum Durchführen der verschiedenen vorliegend besprochenen Ausführungsformen. Fahrzeuge 110, die ein Rechensystem (z.B. das IVS 101) beinhalten, sowie die in der vorliegenden Offenbarung in Bezug genommenen Fahrzeuge können als Fahrzeugbenutzergeräte (vUEs) 110, Fahrzeugstationen 110, Fahrzeug-ITS-Stationen (V-ITS-S) 110, computergestützte (CA)/autonom fahrende (AD) Fahrzeuge 110 und/oder dergleichen bezeichnet werden.
  • Jedes Fahrzeug 110 beinhaltet ein fahrzeuginternes System (IVS) 101, einen oder mehrere Sensoren 172 und eine oder mehrere Fahrsteuereinheiten (DCUs) 174. Das IVS 100 beinhaltet eine Anzahl von Fahrzeug-Rechenhardwaresubsystemen und/oder -anwendungen, die zum Beispiel verschiedene Hardware- und Softwareelemente beinhalten, um die ITS-Architektur aus 10 zu implementieren. Die Fahrzeuge 110 können eine oder mehrere V2X-RATs einsetzen, die es den Fahrzeugen 110 ermöglichen, direkt miteinander und mit Infrastrukturgeräten (z.B. dem Netzzugangsknoten (NAN, network access node) 130) zu kommunizieren. Die V2X-RATs können sich auf zellulare 3GPP-V2X-RAT (z.B. LTE, 5G/NR und darüber), eine WLAN-V2X (W-V2X) RAT (z.B. DSRC in den USA oder ITS-G5 in der EU) und/oder irgendeine andere RAT wie etwa die vorliegend erörterten beziehen. Einige oder alle der Fahrzeuge 110 können eine Positionsbestimmungsschaltungsanordnung zum (groben) Bestimmen ihrer jeweiligen Geolokationen und Kommunizieren ihrer aktuellen Position mit dem NAN 130 auf sichere und zuverlässige Weise beinhalten. Dadurch können sich die Fahrzeuge 110 untereinander und/oder mit dem NAN 130 synchronisieren. Zusätzlich können einige oder alle der Fahrzeuge 110 computergestützte oder autonom fahrende (CA/AD) Fahrzeuge sein, die künstliche Intelligenz (AI) und/oder Robotik zum Unterstützen des Fahrzeugbetriebs beinhalten können.
  • Das IVS 101 beinhaltet die ITS-S 103, die gleich oder ähnlich der ITS-S 1301 aus 13 sein kann. Das IVS 101 kann aufrüstbare Fahrzeugrechensysteme (UVCSs, upgradeable vehicular compute systems) sein oder diese beinhalten, wie etwa die nachstehend erörterten. Wie vorliegend besprochen, ist die ITS-S 103 (oder die zugrunde liegende V2X-RAT-Schaltungsanordnung, auf der die ITS-S 103 arbeitet) in der Lage, eine Kanalabtast- oder Medienabtastoperation durchzuführen, die zumindest Energiedetektion (ED) nutzt, um das Vorhandensein oder das Nichtvorhandensein anderer Signale auf einem Kanal zu bestimmen, um zu bestimmen, ob ein Kanal belegt oder frei ist. Die ED kann Abtasten von Funkfrequenz- (RF-) Energie über ein beabsichtigtes Übertragungsband, Spektrum oder Kanal für einen Zeitraum und Vergleichen der abgetasteten RF-Energie mit einem vordefinierten oder konfigurierten Schwellenwert beinhalten. Wenn die abgetastete RF-Energie über dem Schwellenwert liegt, kann das beabsichtigte Übertragungsband, Spektrum oder der Kanal als belegt angesehen werden.
  • Mit Ausnahme der UVCS-Technologie der vorliegenden Offenbarung können das IVS 101 und das CA/AD-Fahrzeug 110 ansonsten ein beliebiges einer Anzahl von fahrzeuginternen Systemen und CA/AD-Fahrzeugen sein, von computergestützten bis teilweise oder vollständig autonomen Fahrzeugen. Zudem können das IVS 101 und das CA/AD-Fahrzeug 110 andere Komponenten/Subsysteme beinhalten, die nicht durch 1 gezeigt sind, wie etwa die in der gesamten vorliegenden Offenbarung gezeigten und beschriebenen Elemente. Diese und andere Aspekte der zugrunde liegenden UVCS-Technologie, die zum Implementieren des IVS 101 verwendet wird, werden ferner unter Bezugnahme auf die verbleibenden 10 bis 15 beschrieben.
  • Zusätzlich zu der vorliegend erörterten Funktionalität ist die ITS-S 1301 (oder die zugrunde liegende V2X-RAT-Schaltungsanordnung, auf der die ITS-S 1301 arbeitet) in der Lage, verschiedene Signale zu messen oder verschiedene Signal-/Kanaleigenschaften zu bestimmen/identifizieren. Signalmessung kann für Zellenauswahl, Handover, Netzwerkanbindung, Testzwecke und/oder andere Zwecke durchgeführt werden. Die Messwerte/Eigenschaften, die durch die ITS-S 1301 (oder die V2X-RAT-Schaltungsanordnung) gesammelt werden, können eines oder mehrere der Folgenden beinhalten: eine Bandbreite (BW), Netzwerk- oder Zelllast, Latenz, Jitter, Umlaufzeit (RTT, round trip time), Anzahl von Interrupts, reihenfolgenveränderte Übermittlung von Datenpaketen, Übertragungsleistung, Bitfehlerrate, Bitfehlerverhältnis (BER, bit error ratio), Blockfehlerrate (BLER, block error rate), Paketverlustrate (PLR, packet loss rate), Paketempfangsrate (PRR, packet reception rate), Kanalbelegtverhältnis (CBR, channel busy ratio), Kanalbelegungsverhältnis (CR), Signal-RauschVerhältnis (SNR, signal-to-noise ratio), Signal-Rausch- und Interferenzverhältnis (SINR, singalto-noise and inference ratio), Signal-plus-Rauschen-plus-Verzerrung zu Rauschen-plus-Verzerrung- (SINAD-, signal-plus-noise-plus-distortion to noise-plus-distortio) Verhältnis, Spitzenleistung zu Durchschnittsleistung (PAPR, peak-to average power ratio), Referenzsignalempfangsleistung (RSRP, reference signal received power), Empfangssignalstärkeindikator (RSSI, received signal strength indicator), Referenzsignalempfangsqualität (RSRQ, reference signal received quality), GNSS-Timing von Zellframes zur UE-Positionsbestimmung für E-UTRAN oder 5G/NR (z.B. ein Timing zwischen einer Referenzzeit des NAN 130 und einer GNSS-spezifischen Referenzzeit für ein gegebenes GNSS), GNSS-Code-Messwerte (z.B. die GNSS-Code-Phase (ganzzahlige und gebrochene Anteile) des Spreizcodes des i-ten GNSS-Satellitensignals), GNSS-Trägerphasenmesswerte (z.B. die Anzahl von Trägerphasenzyklen (ganzzahlige und gebrochene Anteile) des i-ten GNSS-Satellitensignals, gemessen seit dem Einrasten auf das Signal, auch als Accumulated Delta Range (ADR) bezeichnet), Kanalinterferenzmesswerte, Wärmerauschleistungsmesswerte, Messwerte der empfangene Interferenzleistung und/oder andere ähnliche Messwerte. Die RSRP-, RSSI- und/oder RSRQ-Messwerte können RSRP-, RSSI- und/oder RSRQ-Messwerte zellspezifischer Referenzsignale, Kanalzustandsinformations-Referenzsignale (CSI-RS) und/oder Synchronisationssignale (SS) oder SS-Blöcke für 3GPP-Netzwerke (z.B. LTE oder 5G/NR) und RSRP-, RSSI- und/oder RSRQ-Messwerte verschiedener Baken, FILS Discovery Frames oder Anfrageantwortframes für IEEE 802.11-WLAN/WiFi-Netzwerke beinhalten. Andere Messwerte können zusätzlich oder alternativ verwendet werden, wie etwa jene, die in 3GPP TS 36,214 v15,4.0 (2019-09), 3GPP TS 38,215 v16,1.0 (2020-04), IEEE 802,11, Teil 11 erörtert werden: „Wireless LAN Medium Access Control (MAC) und Physical Layer (PHY) Spezifikationen, IEEE Std.", und/oder dergleichen. Die gleichen oder ähnliche Messwerte können durch den NAN 130 gemessen oder gesammelt werden.
  • Die Subsysteme/Anwendungen können auch Instrumentengruppen-Subsysteme, Vordersitz- und/oder Rücksitz-Infotainment-Subsysteme und/oder andere ähnliche Mediensubsysteme, ein Navigationssubsystem (NAV) 102, ein Fahrzeugstatussubsystem/- anwendung, ein HUD-Subsystem, ein EMA-Subsystem und so weiter beinhalten. Das NAV 102 kann konfigurierbar oder funktionsfähig sein, Navigationsführung oder -steuerung bereitzustellen, in Abhängigkeit davon, ob das Fahrzeug 110 ein computergestütztes Fahrzeug, ein teilweise oder vollständig autonom fahrendes Fahrzeug ist. Das NAV 102 kann mit Computer Vision („maschinellem Sehen“) ausgelegt sein, um stationäre oder sich bewegende Objekte (z.B. einen Fußgänger, ein anderes Fahrzeug oder ein anderes sich bewegendes Objekt) in einem das Fahrzeug 110 umgebenden Bereich zu erkennen, während es sich auf dem Weg zu seinem Ziel bewegt. Das NAV 102 kann konfigurierbar oder funktionsfähig sein, stationäre oder sich bewegende Objekte in dem das Fahrzeug 110 umgebenden Bereich zu erkennen und in Reaktion darauf seine Entscheidung beim Führen oder Steuern von DCUs des Fahrzeugs 110 zumindest teilweise basierend auf Sensordaten, die durch die Sensoren 172 gesammelt werden, zu treffen.
  • Die DCUs 174 beinhalten Hardwareelemente, die verschiedene Systeme der Fahrzeuge 110 steuern, wie etwa den Betrieb des Motors, das Getriebe, die Lenkung, das Bremsen usw. Die DCUs 174 sind eingebettete Systeme oder andere ähnliche Computervorrichtungen, die ein entsprechendes System eines Fahrzeugs 110 steuern. Die DCUs 174 können jeweils die gleichen oder ähnliche Komponenten wie Vorrichtungen/Systeme der nachstehend erörterten Figur 1774 aufweisen oder können irgendein anderer geeigneter Mikrocontroller oder irgendeine andere geeignete Prozessorvorrichtung, Speichervorrichtung(en), Kommunikationsschnittstellen und dergleichen sein. Einzelne DCUs 174 sind in der Lage, mit einem oder mehreren Sensoren 172 und Aktuatoren (z.B. den Aktuatoren 1774 aus 17) zu kommunizieren. Die Sensoren 172 sind Hardwareelemente, die dazu konfigurierbar oder betreibbar sind, eine Umgebung, die die Fahrzeuge 110 umgibt, und/oder Änderungen in der Umgebung zu detektieren. Die Sensoren 172 sind konfigurierbar oder funktionsfähig, um den DCUs 174 und/oder einem oder mehreren KI-Agenten verschiedene Sensordaten bereitzustellen, um den DCUs 174 und/oder einem oder mehreren KI-Agenten zu ermöglichen, jeweilige Steuersysteme der Fahrzeuge 110 zu steuern. Einige oder alle der Sensoren 172 können gleich oder ähnlich wie die Sensorschaltungsanordnung 1772 aus 17 sein. Ferner ist jedes Fahrzeug 110 mit den RSS-Ausführungsformen der vorliegenden Offenbarung versehen. Insbesondere kann das IVS 101 eine Facilities-Schicht beinhalten oder implementieren und eine oder mehrere Facilities innerhalb der Facilities-Schicht betreiben.
  • Eigenständig oder in Reaktion auf Benutzerinteraktionen kommuniziert oder interagiert das IVS 101 mit einem oder mehreren Fahrzeugen 110 über die Schnittstelle 153, die zum Beispiel 3GPP-basierte direkte Links oder IEEE-basierte direkte Links sein können. Die direkten 3GPP-(z.B. LTE- oder 5G/NR-) Links können sein: Sidelinks, ProSe- (Proximity Services) Links und/oder PC5-Schnittstellen/-Links, IEEE- (WiFi-) basierte direkte Links oder PAN- (Personal Area Network)-basierte Links, zum Beispiel WiFi-Direktlinks, IEEE 802.11p-Links, IEEE 802.11bd-Links, IEEE 802.15.4-Links (z.B. ZigBee, IPv6 über Low Power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread usw.). Andere Technologien könnten verwendet werden, wie etwa Bluetooth/Bluetooth Low Energy (BLE) oder dergleichen. In verschiedenen Ausführungsformen können die Fahrzeuge 110 ITS-Protokolldateneinheiten (PDUs) oder andere Nachrichten der Ausführungsbeispiele über die Schnittstelle 153 miteinander austauschen.
  • Eigenständig oder in Reaktion auf Benutzerinteraktionen kommuniziert oder interagiert das IVS 101 mit einem oder mehreren Remote/Cloud-Servern 160 über den NAN 130 über die Schnittstelle 112 und über das Netzwerk 158. Der NAN 130 ist dazu eingerichtet, den Fahrzeugen 110 über jeweilige Schnittstellen 112 zwischen dem NAN 130 und den einzelnen Fahrzeugen 110 Netzwerkkonnektivität bereitzustellen. Der NAN 130 ist oder beinhaltet eine ITS-S und kann eine Straßenrand-ITS-S (R-ITS-S) sein. Der NAN 130 ist ein Netzwerkelement, das Teil eines Zugangsnetzes ist, das Netzwerkkonnektivität für die Endbenutzervorrichtungen (z.B. V-ITS-Ss 110 und/oder VRU-ITS-Ss 117) bereitstellt. Die Zugangsnetze können Funkzugangsnetzwerke (RANs) sein, wie etwa ein NG-RAN oder ein 5G-RAN für ein RAN, das in einem 5G/NR-Zellularnetzwerk arbeitet, ein E-UTRAN für ein RAN, das in einem LTE- oder 4G-Mobilfunknetzwerk arbeitet, oder ein Legacy-RAN, wie etwa ein UTRAN oder GERAN für GSM- oder CDMA-Zellularnetzwerke. Das Zugangsnetz oder RAN kann für WiMAX-Implementierungen als ein Zugangsdienstnetz bezeichnet werden. In einigen Ausführungsformen kann der RAN ganz oder teilweise als eine oder mehrere Softwareentitäten implementiert sein, die auf Servercomputern als Teil eines virtuellen Netzwerks ausgeführt werden, das als Cloud-RAN (CRAN), Cognitive Radio (CR), virtueller Basisbandeinheitspool (vBBUP) und/oder dergleichen bezeichnet werden kann. Bei diesen Ausführungsformen kann das CRAN, das CR oder der vBBUP eine RAN-Funktionsaufteilung implementieren, wobei eine oder mehrere Kommunikationsprotokollschichten durch das CRAN/das CR/den vBBUP betrieben werden und andere Kommunikationsprotokollentitäten durch einzelne RAN-Knoten 130 betrieben werden. Dieses virtualisierte Framework ermöglicht den freigewordenen Prozessorkernen des NAN 130, andere virtualisierte Anwendungen durchzuführen, wie etwa virtualisierte Anwendungen für die vorliegend erörterten VRU/V-ITS-S-Ausführungsformen.
  • Die Umgebung 100 beinhaltet zudem einen VRU 116, der eine VRU-ITS-S 117 beinhaltet.
  • Der VRU 116 ist sowohl ein nicht motorisierter Verkehrsteilnehmer als auch eine Klasse von Fahrzeugen (z.B. Mopeds, Motorräder, Segways usw.), wie in Anhang I der EU-Regelung 168/2013 definiert (siehe z.B. International Organization for Standardization (ISO) D., „Straßenfahrzeuge - Fahrzeugdynamik und Fahrverhalten - Begriffe“, ISO 8855 (2013) (im Folgenden „[ISO8855]“)). Ein VRU 116 ist ein Akteur, der mit einem VRU-System 117 in einem gegebenen Anwendungsfall und einem gegebenen Verhaltensszenario interagiert. Ist beispielsweise der VRU 116 mit einer persönlichen Vorrichtung ausgestattet, so kann der VRU 116 über die persönliche Vorrichtung direkt mit anderen ITS-Stationen und/oder anderen VRUs 116 mit VRU-Vorrichtungen 117 interagieren. Die VRU-ITS-S 117 könnte entweder ein Fußgänger-VRU (siehe z.B. P-ITS-S 1401 aus 14) oder ein Fahrzeug-VRU (auf Fahrrad, Motorrad) sein. Der Begriff „VRU-ITS-S“ bezieht sich vorliegend auf einen beliebigen Typ von VRU-Vorrichtung oder VRU-System. Bevor der potentielle VRU überhaupt als VRU identifiziert werden kann, kann er als nicht-VRU bezeichnet werden und in dem ITS in einem RUHE- oder inaktiven Zustand befindlich angesehen werden.
  • Ist der VRU 116 nicht mit einer Vorrichtung ausgestattet, so interagiert der VRU 116 indirekt, da der VRU 116 durch eine andere ITS-Station in dem VRU-System 117 über deren Erfassungseinrichtungen, wie etwa Sensoren und/oder andere Komponenten, detektiert wird. Solche VRUs 116 können jedoch andere VRUs 116 (z.B. ein Fahrrad) nicht erkennen. In ETSI TS 103 300-2 V0.3.0 (2019-12) („[TS103300-2]“) wurden die verschiedenen Typen von VRUs 116 in die folgenden vier Profile kategorisiert:
    • • VRU-Profil-1: Fußgänger (Gehsteigbenutzer, Kinder, Kinderwägen, Menschen mit Behinderung, ältere Menschen, usw.)
    • • VRU-Profil-2: Fahrradfahrer (Leichtfahrzeuge, die Personen tragen, Rollstuhlfahrer, Pferde mit Reitern, Skater, E-Scooter, Segways usw.) und
    • • VRU-Profil-3: Kraftradfahrer (Motorräder, angetriebene Zweiräder, Mopeds usw.).
    • • VRU-Profil-4: Tiere, die ein Sicherheitsrisiko für andere Verkehrsteilnehmer darstellen (Hunde, Wildtiere, Pferde, Kühe, Schafe usw.).
  • Diese Profile definieren ferner das VRU-Funktionssystem und die Kommunikationsarchitekturen für die VRU-ITS-S 117. Zum zuverlässigen Unterstützen der VRU-Profilbewusstseinsaktivierung stellen Ausführungsformen vorliegend VRU-bezogene funktionelle Systemanforderungen, Protokoll- und Nachrichtenaustauschmechanismen einschließlich, ohne jedoch hierauf eingeschränkt zu sein, VAMS [TS103300-2] bereit. Außerdem gelten die vorliegenden Ausführungsformen auch für jeden in Tabelle 0-1 aufgelisteten VRU-Vorrichtungstyp (siehe z.B. [TS103300-2]). Tabelle 0-1
    VRU-Typ Beschreibung
    VRU-Tx Die VRU-Vorrichtung 117 ist nur mit Sender ausgestattet und kann Bakennachrichten über den VRU 116 senden
    VRU-Rx Die VRU-Vorrichtung 117 ist nur mit einem Empfänger und einer Anwendung zum Empfangen einer Nachricht von anderen ITS-Ss ausgestattet und ist in der Lage, den VRU 116 zu warnen/benachrichtigen
    VRU-St Die VRU-Vorrichtung 117 enthält eine ITS-S mit sowohl VRU-Tx- als auch VRU-Rx-Fähigkeiten
  • Ein VRU 116 kann mit einer tragbaren Vorrichtung (z.B. der Vorrichtung 117) ausgestattet sein. Der Begriff „VRU“ kann verwendet werden, um sowohl auf einen VRU 116 als auch seine VRU-Vorrichtung 117 zu verweisen, es sei denn, der Kontext gibt etwas anderes vor. Die VRU-Vorrichtung 117 kann anfänglich konfiguriert sein und kann sich während ihres Betriebs im Anschluss an Kontextänderungen, die spezifiziert werden müssen, entwickeln. Dies gilt insbesondere für das Einrichten des VRU-Profils und des VRU-Typs, die automatisch beim Einschalten oder über ein HMI erreicht werden können. Die Änderung des Straßenbenutzer-Vulnerabilitätszustands muss zudem bereitgestellt werden, um den VRU-Basisdienst zu aktivieren, wenn der Straßenbenutzer vulnerabel/ungeschützt wird, oder ihn zu deaktivieren, wenn er in einen geschützten Bereich eintritt. Die Anfangskonfiguration kann automatisch eingerichtet werden, wenn die Vorrichtung eingeschaltet wird. Dies kann für folgenden VRU-Gerätetyp der Fall sein: VRU-Tx mit der einzigen Kommunikationsfähigkeit zum Senden von Nachrichten und Erfüllen der Kanalüberlastungssteuerregeln; VRU-Rx mit der einzigen Kommunikationsfähigkeit zum Empfangen von Nachrichten; und/oder VRU-St mit Vollduplex-Kommunikationsfähigkeiten. Während des Betriebs kann sich das VRU-Profil zudem aufgrund von Clusterung oder Deassemblierung ändern. Folglich wird die VRU-Vorrichtungsrolle in der Lage sein, sich gemäß den Änderungen des VRU-Profils zu entwickeln.
  • Ein „VRU-System“ (z.B. VRU-ITS-S 117) umfasst ITS-Artefakte, die für VRU-Anwendungsfälle und -szenarien wie etwa die vorliegend erörterten relevant sind, einschließlich der Primärkomponenten und ihrer Konfiguration, der Akteure und ihrer Ausrüstung, relevanten Verkehrssituationen und Betriebsumgebungen. Die Begriffe „VRU-Vorrichtung“, „VRU-Ausrüstung“ und „VRU-System“ beziehen sich auf eine tragbare Vorrichtung (z.B. Mobilstationen wie Smartphones, Tablets, Wearable-Vorrichtungen, Fitness-Tracker usw.) oder eine IoT-Vorrichtung (z.B. Verkehrssteuervorrichtungen), die durch eine VRU 116 verwendet wird und die ITS-S-Technologie integriert, und somit kann die VRU-ITS-S 117 eine „VRU-Vorrichtung“, „VRU-Ausrüstung“ und/oder ein „VRU-System“ beinhalten oder sich auf diese beziehen.
  • Die in der vorliegenden Offenbarung betrachteten VRU-Systeme sind kooperative intelligente Transportsysteme (C-ITS), die mindestens einen ungeschützten Verkehrsteilnehmer (VRU) und eine ITS-Station mit einer VRU-Anwendung umfassen. Die ITS-S kann eine Fahrzeug-ITS-Station oder eine Straßenrand-ITS-Station sein, die die VRU-Anwendungslogik basierend auf den Diensten verarbeitet, die durch die niedrigeren Kommunikationsschichten (Facilities-, Netzwerk- & Transport- und Zugangsschicht (siehe z.B. ETSI EN 302 665 V1.1.1 (2010-09) („[EN302665]“), zugehörige Hardwarekomponenten, andere stationäre Dienste und Sensorsubsysteme bereitgestellt werden. Ein VRU-System kann mit anderen VRUs, anderen ITS-S und anderen Verkehrsteilnehmern, die an einem Szenario beteiligt sind, wie etwa Fahrzeugen, Motorrädern, Fahrrädern und Fußgängern, erweitert werden. VRUs können mit ITS-S oder mit anderen Technologien (z.B. IoT) ausgestattet sein, die es ihnen ermöglichen, eine Warnung zu senden oder zu empfangen. Das betrachtete VRU-System ist somit ein heterogenes System. Eine Definition eines VRU-Systems wird verwendet, um die Systemkomponenten zu identifizieren, die aktiv an einem Anwendungsfall- und Verhaltensszenario teilnehmen. Die aktiven Systemkomponenten sind mit ITS-Stationen ausgestattet, während alle anderen Komponenten passiv sind und einen Teil der Umgebung des VRU-Systems bilden.
  • Die VRU-ITS-S 117 kann eine oder mehrere VRU-Anwendungen betreiben. Eine VRU-Anwendung ist eine Anwendung, die das Bewusstsein (awareness) über und/oder in Bezug auf VRUs und/oder VRU-Cluster in oder um andere Verkehrsteilnehmer herum erweitert. VRU-Anwendungen können in einer beliebigen ITS-S existieren, was bedeutet, dass VRU-Anwendungen entweder im VRU selbst oder in Nicht-VRU-ITS-Stationen, zum Beispiel Autos, Lastwagen, Bussen, Straßenrandstationen oder Zentralstationen, zu finden sind. Diese Anwendungen zielen darauf ab, VRU-relevante Informationen an Akteure wie etwa Menschen direkt oder an automatisierte Systeme bereitzustellen. VRU-Anwendungen können das Bewusstsein für ungeschützte Verkehrsteilnehmer erhöhen, VRU-Kollisionsrisiko-Warnungen an jeden anderen Verkehrsteilnehmer liefern oder eine automatisierte Aktion in einem Fahrzeug auslösen. VRU-Anwendungen nutzen Daten, die von anderen ITS-Ss über das C-ITS-Netz empfangen werden, und können zusätzliche Informationen verwenden, die durch die ITS-S-eigenen Sensorsysteme und andere integrierte Dienste bereitgestellt werden.
  • Im Allgemeinen gibt es vier Arten von VRU-Geräten 117, nämlich nicht ausgestattete VRUs (z.B. ein VRU 116, der über keine Vorrichtung verfügt); VRU-Tx (z.B. ein VRU 116, der mit einer ITS-S 117 ausgestattet ist, die nur eine Übertragungs- (Tx-), aber keine Empfangs- (Rx-) Fähigkeiten aufweist und die Bewusstmachungs- (awareness) Nachrichten oder -Baken über den VRU 116 sendet); VRU-Rx (z.B. ein VRU 116, der mit einer ITS-S 117 ausgestattet ist, die nur Rx- (aber keine Tx-) Fähigkeiten aufweist und die ausgestrahlte Bewusstmachungsnachrichten oder -Baken über die anderen VRUs 116 oder andere Nicht-VRU-ITS-Ss empfängt); und VRU-St (z.B. ein VRU 116, der mit einer ITS-S 117 ausgestattet ist, die die VRU-Tx- und VRU-Rx-Funktionalität beinhaltet). Die Anwendungsfälle und Verhaltensszenarien berücksichtigen einen breiten Satz von Konfigurationen von VRU-Systemen 117 basierend auf der Ausrüstung des VRU 116 und dem Vorhandensein oder Nichtvorhandensein der V-ITS-S 110 und/oder der R-ITS-S 130 mit einer VRU-Anwendung. Beispiele für die verschiedenen VRU-Systemkonfigurationen sind in Tabelle 2 von ETSI TR 103 300-1 v2,1.1 (2019-09) („[TR103300-1]“) dargestellt.
  • Die für VRUs 116/117 spezifizierte Nachricht ist die VRU-Bewusstmachungsnachricht (VAM, VRU awareness message). VAMS sind Nachrichten, die von VRU-ITSs 117 übertragen werden, um ein Bewusstsein für VRUs 116, die an dem VRU-/ITS-System teilnehmen, zu erzeugen und aufrechtzuerhalten. VAMS werden weitestgehend mit den existierenden Cooperative Awareness Messages (CAM, kooperative Bewusstmachungsnachrichten), die in [EN302637-2] definiert sind, harmonisiert. Die Übertragung der VAM ist auf die in Klausel 6.1 von [TS103300-2] spezifizierten VRU-Profile beschränkt, wobei die VAMs alle erforderlichen Daten in Abhängigkeit von dem VRU-Profil und den tatsächlichen Umgebungsbedingungen enthalten. Die Datenelemente in der VAM sollten wie in Tabelle 0-2 beschrieben sein. Tabelle 0-2: VAM-Datenelemente
    Parameter Anmerkungen
    VAM-Header mit VRU-Kennung Die VRU-ID ist eine eindeutige Kennung eines VRU 116/117 innerhalb des Abdeckungsgebiets einer ITS-S, wie etwa einer R-ITS-S 130.
    VRU-Position Die VRU-Position ist eine eindeutige Position, ein Koordinatensatz, eine Geolokalisierung, ein Geobereich usw., die einem physischen Standort eines VRU in 2D- oder 3D-Ebene zugeordnet ist
    (VAM)-Erzeugungszeit Ein Zeitstempel der VAM-Erzeugung; die Zeit, die für eine VAM-Erzeugung benötigt wird, bezieht sich auf die Zeitdifferenz zwischen der Zeit, zu der eine VAM-Erzeugung ausgelöst wird, und der Zeit, zu der die VAM an die Netzwerk- & Transportschicht geliefert wird.
    VRU-Profil Profile, die aus den Anwendungsfällen und der Analyse in Klausel 7.2 von [TR103300-1] abgeleitet sind
    VRU-Typ Beispielsweise ist das VRU-Profil ein Fußgänger, der VRU-Typ ist ein Säugling, ein Tier, ein Erwachsener, ein Kind usw.
    VRU-Cluster-Kennung (ID) Eine zufällige und/oder lokal eindeutige ID eines VRU-Clusters; insofern lokal eindeutig, als sie sich von jeder Clusterkennung in einer VAM unterscheidet, die vom VBS in der letzten zeitClusterEindeutigkeitsSchwellen-Zeit empfangen wird.
    VRU-Clusterposition Die Referenzposition eines VRU-Clusters, die sich auf eine Bodenposition am Mittelpunkt der Stirnseite des ersten VRU-Begrenzungsrahmens bezieht.
    VRU-Clusterabmessung Geografische Größe und/oder Begrenzungsrahmengröße
    VRU-Clustergröße Anzahl der Elemente im Cluster
    VRU-Größenklasse zwingend erforderlich, wenn außerhalb eines VRU-Clusters, optional, wenn innerhalb eines VRU-Clusters
    VRU-Gewichtsklasse zwingend erforderlich, wenn außerhalb eines VRU-Clusters, optional, wenn innerhalb eines VRU-Clusters
    VRU-Geschwindigkeit Geschwindigkeitsvektor eines einzelnen VRU oder kohärente Geschwindigkeit eines VRU-Clusters; Geschwindigkeit in Bewegungsrichtung und/oder Geschwindigkeitsgenauigkeit der Ursprungs-ITS-S,
    VRU-Richtung Kurs und/oder Kursgenauigkeit der Ursprungs-ITS-S in Bezug auf geografisch Nord oder eine andere geodätische Richtung.
    VRU-Orientierung/Ausrichtung Der Winkel eines VRU bezüglich seiner Längsachse in Bezug auf WGS84 Nord oder geografisch Nord.
    Vorhergesagte Trajektorie Folge von Wegpunkten
    Vorhergesagter Geschwindigkeitsvektor einschließlich 3D-Kurs und Durchschnittsgeschwindigkeit
    Kursänderungsindikatoren Indikatoren für Linksabbiegen oder Rechtsabbiegen
    Indikator für hartes Bremsen Indikator, der Fahrer über jegliches harte Bremsen benachrichtigt, das von vorausfahrenden Fahrzeugen oder Fahrzeug-VRUs ausgeführt wird.
    HINWEIS: „M“ steht für „zwingend“ (mandatory), was bedeutet, dass das Datenelement stets in der VAM-Nachricht enthalten ist. „O“ steht für „optional“, was bedeutet, dass das Datenelement in der VAM-Nachricht enthalten sein kann. „C“ steht für „bedingt“ (conditional), was bedeutet, dass das Datenelement unter bestimmten Bedingungen in der VAM-Nachricht enthalten ist
  • Das VRU-System 117 unterstützt das flexible und dynamische Auslösen von Nachrichten mit Erzeugungsintervallen von X Millisekunden (ms) bei maximaler Frequenz, wobei X eine Zahl ist (z.B. X = 100ms). Die VAMS-Frequenz steht in Zusammenhang mit der VRU-Bewegungsdynamik und der gewählten Kollisionsrisikometrik wie in Klausel 6.5.10.5 von [TS103300-3] erörtert.
  • Die Anzahl an VRUs 116, die in einem gegebenen Bereich arbeiten, kann sehr hoch werden. In einigen Fällen kann der VRU 116 mit einem VRU-Fahrzeug (z.B. Fahrer auf einem Fahrrad oder dergleichen) kombiniert sein. Um das Kommunikationsaufkommen und die assoziierte Ressourcennutzung (z.B. Spektrumanforderungen) zu reduzieren, können VRUs 116 in einen oder mehrere VRU-Cluster gruppiert werden. Ein VRU-Cluster ist ein Satz von zwei oder mehr VRUs 116 (z.B. Fußgängern) derart, dass sich die VRUs 116 auf kohärente Weise bewegen, beispielsweise mit kohärentem Geschwindigkeitsvektor oder kohärenter Richtung und innerhalb eines VRU-Begrenzungsrahmens. Ein „kohärenter Clustergeschwindigkeitsvektor“ bezieht sich auf den Geschwindigkeitsvektorbereich von VRUs 116 in einem Cluster derart, dass die Geschwindigkeits- und Kursdifferenzen zwischen beliebigen der VRUs in einem Cluster unter einem vordefinierten Schwellenwert liegen. Ein „VRU-Begrenzungsrahmen“ ist ein rechteckiger Bereich, der alle VRUs 116 in einem VRU-Cluster derart enthält, dass alle VRUs in dem Begrenzungsrahmen die Oberfläche bei näherungsweise gleicher Elevation kontaktieren.
  • VRU-Cluster können homogene VRU-Cluster (z.B. eine Gruppe von Fußgängern) oder heterogene VRU-Cluster (z.B. Gruppen von Fußgängern und Fahrrädern mit menschlichen Bedienern) sein. Diese Cluster werden als ein einziges Objekt/eine einzige Entität betrachtet. Die Parameter des VRU-Clusters werden unter Verwendung von VRU-Bewusstmachungsnachrichten (VAMS) kommuniziert, wobei nur der Clusterkopf kontinuierlich VAMS überträgt. Die VAMS enthalten ein optionales Feld, das angibt, ob der VRU 116 einen Cluster anführt, und das für einzelne VRUs nicht vorhanden ist (z.B. sollten andere VRUs im Cluster keine VAMs übertragen oder VAMs mit sehr langer Periodizität übertragen). Der führende VRU zeigt in der VAM auch an, ob es sich um einen homogenen Cluster oder einen heterogen handelt, wobei letzterer aus einer beliebigen Kombination von VRUs besteht. Die Angabe, ob der VRU-Cluster heterogen und/oder homogen ist, kann nützliche Informationen über Trajektorie- und Verhaltensvorhersage liefern, wenn der Cluster aufgelöst wird.
  • Die Verwendung eines Fahrrads oder eines Motorrads wird das Verhalten und den Parametersatz des VRU, der dieses Nicht-VRU-Objekt (oder VRU-Fahrzeug wie etwa ein „Fahrrad“/„Motorrad“) verwendet, erheblich ändern. Eine Kombination eines VRU 116 und eines Nicht-VRU-Objekts wird als „kombinierter VRU“ bezeichnet. VRUs 116 mit VRU-Profil 3 (z.B. Motorradfahrer) sind üblicherweise nicht an der VRU-Clusterbildung beteiligt.
  • Eine VAM enthält Status- und Attributinformationen der Ursprungs-VRU-ITS-S 117. Der Inhalt kann in Abhängigkeit vom Profil der VRU-ITS-S 117 variieren. Typische Statusinformationen beinhalten Zeit, Position, Bewegungszustand, Clusterstatus und andere. Typische Attributinformationen beinhalten Daten über das VRU-Profil, den Typ, die Abmessungen und andere. Die Erzeugung, Übertragung und der Empfang von VAMs werden durch den VRU-Basisdienst (VBS) verwaltet (siehe z.B. 10-11). Der VBS ist eine Entität der Facilities-Schicht, die das VAM-Protokoll betreibt. Der VBS stellt die folgenden Dienste bereit: Handhabung der VRU-Rolle, Senden und Empfangen von VAMs, um die VRU-Sicherheit zu verbessern. Der VBS spezifiziert und/oder verwaltet zudem VRU-Clusterbildung in Gegenwart einer hohen VRU-116/117-Dichte, um den VAM-Kommunikationsaufwand zu reduzieren. Bei der VRU-Clusterbildung bilden eng beieinander lokalisierte VRUs mit kohärenter Geschwindigkeit und Kurs auf der Facilities-Schicht einen VRU-Cluster, und nur der Clusterkopf-VRU 116/117 überträgt die VAM. Andere VRUs 116/117 im Cluster überspringen die VAM-Übertragung. Aktive VRUs 116/117 (z.B. VRUs 116/117, die sich nicht in einem VRU-Cluster befinden) senden individuelle VAMs (als Einzel-VRU-VAM oder dergleichen bezeichnet). Eine „individuelle VAM“ ist eine VAM, die Informationen über einen individuellen VRU 116/117 beinhaltet. Eine VAM ohne Qualifizierung kann eine Cluster-VAM oder eine individuelle VAM sein.
  • Die Funkzugangstechnologien (RATs), die durch den NAN 130, die V-ITS-Ss 110 und die VRU-ITS-S 117 eingesetzt werden, können eine oder mehrere V2X-RATs beinhalten, die es den V-ITS-Ss 110 ermöglichen, direkt miteinander, mit Infrastrukturgeräten (z.B. dem NAN 130) und mit VRU-Vorrichtungen 117 zu kommunizieren. In dem Beispiel aus 1 kann eine beliebige Anzahl von V2X-RATs für die V2X-Kommunikation verwendet werden. In einem Beispiel können mindestens zwei distinkte V2X-RATs verwendet werden, einschließlich WLAN-V2X-(W-V2X-) RAT basierend auf IEEE-V2X-Technologien (z.B. DSRC für die USA und ITS-G5 für Europa) und 3GPP-C-V2X-RAT (z.B. LTE, 5G/NR und darüber hinaus). In einem Beispiel kann die C-V2X-RAT eine Luftschnittstelle 112a nutzen und die WLAN-V2X-RAT kann eine Luftschnittstelle 112b nutzen. Die Zugangsschicht für die ITS-G5-Schnittstelle ist in ETSI EN 302 663 V1.3.1 (2020-01) (im Folgenden „[EN302663]“) skizziert und beschreibt die Zugangsschicht der ITS-S-Referenzarchitektur 1000. Die ITS-G5-Zugangsschicht umfasst IEEE 802.11-2016- (im Folgenden „[IEEE80211]“-) und IEEE 802.2-LLC- (Logical Link Control) (im Folgenden „[IEEE8022]“) Protokolle. Die Zugangsschicht für 3GPP-LTE-V2X-basierte Schnittstelle(n) ist unter anderem in ETSI EN 303 613 V1.1.1 (2020-01), 3GPP TS 23.285 v16.2.0 (2019-12) umrissen; und 3GPP 5G/NR-V2X ist unter anderem in 3GPP TR 23.786 v16.1.0 (2019-06) und 3GPP TS 23.287 v16.2.0 (2020-03) umrissen. In einigen Ausführungsformen kann der NAN 130 oder ein Edge-Rechenknoten 140 eine/n oder mehrere Dienste/Fähigkeiten 180 bereitstellen.
  • In V2X-Szenarien kann eine V-ITS-S 110 oder ein NAN 130 eine RSU oder R-ITS-S 130 sein oder als diese fungieren, was sich auf eine beliebige Transportinfrastrukturentität bezieht, die für V2X-Kommunikationen verwendet wird. In diesem Beispiel kann die RSU 130 eine stationäre RSU, wie etwa eine RSU vom gNB/eNB-Typ oder eine andere ähnliche Infrastruktur, oder ein relativ stationäres UE sein. In anderen Ausführungsformen kann die RSU 130 eine mobile RSU oder eine RSU vom UE-Typ sein, die durch ein Fahrzeug (z.B. die V-ITS-Ss 110), einen Fußgänger oder andere Vorrichtung mit solchen Fähigkeiten implementiert sein kann. In diesen Fällen können Mobilitätsprobleme verwaltet werden, um eine ordnungsgemäße Funkabdeckung der Übersetzungsentitäten sicherzustellen.
  • In einer beispielhaften Implementierung ist die RSU 130 eine Rechenvorrichtung, die mit einer Funkfrequenzschaltungsanordnung gekoppelt ist, die sich an einem Straßenrand befindet, die Konnektivitätsunterstützung für vorbeigehende/-fahrende V-ITS-Ss 110 bereitstellt. Die RSU 130 kann zudem interne Datenspeicherungsschaltungsanordnungen beinhalten, um Kreuzungskartengeometrie, Verkehrsstatistiken, Medien sowie Anwendungen/Software zu speichern, um laufenden Fahrzeug- und Fußgängerverkehr zu erfassen und zu steuern. Die RSU 130 stellt verschiedene Dienste/Fähigkeiten 180 bereit, wie etwa zum Beispiel Kommunikationen mit sehr niedriger Latenz, die für Hochgeschwindigkeitsereignisse erforderlich sind, wie etwa Kollisionsvermeidung, Verkehrswarnungen und dergleichen. Zusätzlich oder alternativ kann die RSU 130 andere Dienste/Fähigkeiten 180 bereitstellen, wie etwa zum Beispiel zellulare/WLAN-Kommunikationsdienste. In einigen Implementierungen können die Komponenten der RSU 130 in einem wetterfesten Gehäuse verpackt sein, das zur Installation im Freien geeignet ist, und können eine Netzwerkschnittstellensteuerung beinhalten, um eine drahtgebundene Verbindung (z.B. Ethernet) zu einer Verkehrssignalsteuerung und/oder einem Backhaul-Netzwerk bereitzustellen. Ferner kann die RSU 130 drahtgebundene oder drahtlose Schnittstellen zum Kommunizieren mit anderen RSUs 130 (in 1 nicht gezeigt) beinhalten.
  • Bei der Anordnung 100 kann die V-ITS-S 110a mit einem ersten V2X-RAT-Kommunikationssystem (z.B. C-V2X) ausgestattet sein, wohingegen die V-ITS-S 110b mit einem zweiten V2X-RAT-Kommunikationssystem (z.B. W-V2X, wobei es sich um DSRC, ITS-G5 oder dergleichen handeln kann) ausgestattet sein kann. In anderen Ausführungsformen können die V-ITS-S 110a und/oder die V-ITS-S 110b jeweils mit einem oder mehreren V2X-RAT-Kommunikationssystemen eingesetzt werden. In diesen Ausführungsformen kann die RSU 130 V2X-RAT-Übersetzungsdienste unter einem oder mehreren Diensten/Fähigkeiten 180 bereitstellen, so dass einzelne V-ITS-Ss 110 miteinander kommunizieren können, selbst wenn die V-ITS-Ss 110 unterschiedliche V2X-RATs implementieren. Gemäß verschiedenen Ausführungsformen kann die RSU 130 (oder der Edge-Rechenknoten 140) VRU-Dienste unter dem einen oder den mehreren Diensten/Fähigkeiten 180 bereitstellen, bei denen die RSU 130 CPMs, MCMs, VAMs, DENMs, CAMs usw. mit V-ITS-Ss 110 und/oder VRUs für VRU-Sicherheitszwecke, einschließlich RSS-Zwecken, gemeinsam nutzt. Die V-ITS-Ss 110 können solche Nachrichten zudem miteinander, mit der RSU 130 und/oder mit VRUs teilen. Diese Nachrichten können die verschiedenen Datenelemente und/oder Datenfelder beinhalten, die vorliegend erörtert werden.
  • In diesem Beispiel kann der NAN 130 eine stationäre RSU, wie etwa eine RSU vom gNB/ENB-Typ, oder eine andere ähnliche Infrastruktur sein. In anderen Ausführungsformen kann der NAN 130 eine mobile RSU oder eine RSU vom UE-Typ sein, die durch ein Fahrzeug, einen Fußgänger oder andere Vorrichtung mit solchen Fähigkeiten implementiert sein kann. In diesen Fällen können Mobilitätsprobleme verwaltet werden, um eine ordnungsgemäße Funkabdeckung der Übersetzungsentitäten sicherzustellen. Der NAN 130, der die Verbindungen 112 ermöglicht, kann als ein „RAN-Knoten“ oder dergleichen bezeichnet werden. Der RAN-Knoten 130 kann Bodenstationen (z.B. terrestrische Zugangspunkte) oder Satellitenstationen umfassen, die Abdeckung innerhalb eines geografischen Gebiets (z.B. einer Zelle) bereitstellen. Der RAN-Knoten 130 kann als eine dedizierte physische Vorrichtung, wie eine Makrozellenbasisstation, und/oder eine Niederleistungsbasisstation zum Bereitstellen von Femtozellen, Pikozellen oder anderen ähnlichen Zellen mit kleineren Abdeckungsbereichen, kleinerer Benutzerkapazität oder höherer Bandbreite als Makrozellen implementiert sein. In diesem Beispiel ist der RAN-Knoten 130 als ein NodeB, ein evolved NodeB (eNB) oder ein NodeB der nächsten Generation (gNB), ein oder mehrere Relaisknoten, verteilte Einheiten oder Straßenrandeinheiten (RSUs) umgesetzt. Eine beliebige andere Art von NANs kann verwendet werden. Zusätzlich kann der RAN-Knoten 130 verschiedene logische Funktionen für das RAN erfüllen, einschließlich unter anderem RAN-Funktion(en) (z.B. Funknetzsteuer- (RNC)-Funktionen und/oder NG-RAN-Funktionen) für Funkressourcenverwaltung, Zulassungssteuerung, dynamische Uplink- und Downlink-Ressourcenzuweisung, Funkträgerverwaltung, Datenpaketplanung usw.
  • Das Netzwerk 158 kann ein Netzwerk wie beispielsweise das Internet, ein drahtloses lokales Netzwerk (WLAN) oder ein drahtloses Weitverkehrsnetz (WWAN), einschließlich proprietärer und/oder Unternehmensnetzwerke für eine Firma oder Organisation, ein zellulares Kernnetz (z.B. ein EPC- (Evolved Packet Core) Netzwerk, ein NPC- (NextGen Packet Core) Netzwerk, ein 5GC- (5G-Kern-) oder irgendeine andere Art von Kernnetz), eine Cloud-Computing-Architektur/-Plattform, die einen oder mehrere Cloud-Computing-Dienste bereitstellt, und/oder Kombinationen davon repräsentieren. Als Beispiele können das Netzwerk 158 und/oder die Zugangstechnologien zellulare Technologie, wie etwa LTE, MuLTEfire und/oder NR/5G (wie z.B. durch den RAN- (Funkzugangsnetz-) Knoten 130 bereitgestellt), WLAN- (z.B. WiFi®-) Technologien (wie z.B. durch einen Zugangspunkt (AP) 130 bereitgestellt) und/oder dergleichen beinhalten. Unterschiedliche Technologien weisen Vorteile und Beschränkungen in unterschiedlichen Szenarien auf, und die Anwendungsleistung in unterschiedlichen Szenarien hängt von der Wahl der Zugangsnetze (z.B. WiFi, LTE usw.) und der verwendeten Netzwerk- und Transportprotokolle (z.B. Transfer Control Protocol (TCP), Virtual Private Network (VPN), Multi-Path TCP (MPTCP), Generic Routing Encapsulation (GRE) usw.) ab.
  • Die Remote/Cloud-Server 160 können einen oder mehrere Anwendungsserver, eine Cloud-Computing-Architektur/-Plattform, die Cloud-Computing-Dienste bereitstellt, und/oder eine andere entfernte Infrastruktur darstellen. Die Remote/Cloud-Server 160 können beliebige einer Reihe von Diensten und Fähigkeiten 180 beinhalten, wie etwa zum Beispiel ITS-bezogene Anwendungen und Dienste, Fahrassistenz (z.B. Mapping/Navigation), Inhaltsbereitstellung (z.B. Multimedia-Infotainment-Streaming) und/oder dergleichen.
  • Zusätzlich ist der NAN 130 zusammen mit einem Edge-Rechenknoten 140 (oder einer Sammlung von Edge-Rechenknoten 140) angeordnet, der eine beliebige Anzahl von Diensten/Fähigkeiten 180 für Fahrzeuge 110 bereitstellen kann, wie etwa ITS-Dienste/- Anwendungen, Fahrassistenz und/oder Inhaltsbereitstellungsdienste 180. Der Edge-Rechenknoten 140 kann ein Edge-Netzwerk oder eine „Edge-Cloud“ beinhalten oder Teil davon sein. Der Edge-Rechenknoten 140 kann auch als „Edge-Host 140“, „Edge-Server 140“ oder „Rechenplattformen 140“ bezeichnet werden. Die Edge-Rechenknoten 140 können Ressourcen (z.B. Speicher, CPU, GPU, Interruptsteuerungen, E/A-Steuerungen, Speichersteuerung, Bussteuerungen, Netzwerkverbindungen oder -sitzungen usw.) partitionieren, wobei jeweilige Partitionierungen Sicherheits- und/oder Integritätsschutzfähigkeiten enthalten können. Edge-Knoten können zudem Orchestrierung mehrerer Anwendungen über isolierte Benutzerrauminstanzen, wie etwa Container, Partitionen, virtuelle Umgebungen (VEs), virtuelle Maschinen (VMs), Servlets, Server und/oder andere ähnliche Berechnungsabstraktionen bereitstellen. Der Edge-Rechenknoten 140 kann in einem Datenzentrum oder einer Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmensserver, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert, implementiert sein. Der Edge-Rechenknoten 140 kann den Fahrzeugen 110 eine beliebige Anzahl von Fahrassistenz- und/oder Inhaltsbereitstellungsdiensten 180 bereitstellen. Der Edge-Rechenknoten 140 kann in einem Datenzentrum oder einer Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmensserver, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert, implementiert sein. Zu Beispielen für solche anderen Edge-Computing-/Networking-Technologien, die den Edge-Rechenknoten 140 und/oder das Edge-Computing-Netzwerk/die Cloud implementieren können, zählen Mehrfachzugriffs-Edge-Computing (MEC, multi-access edge computing), Inhaltslieferungsnetzwerke (CDNs, content delivery networks) (auch als „Inhaltsverteilungsnetzwerke“ (content distribution networks) oder dergleichen bezeichnet); Mobilitätsdienstanbieter- (MSP-, mobility service provider) Edge-Computing und/oder MaaS- (Mobility as a Service) Anbietersysteme (die z.B. in AECC-Architekturen verwendet werden); Nebula-Edge-Cloud-Systeme; Fog-Computing-Systeme; Cloudlet-Edge-Cloud-Systeme; MCC- (Mobile Cloud Computing) Systeme; CORD- (Central Office Re-Architected as a Datacenter), Mobile-CORD (M-CORD) und/oder Converged-Multi-Access-and-Core- (COMAC-) Systeme; und/oder dergleichen. Ferner können vorliegend offenbarte Techniken andere IoT-Edge-Netzwerksysteme und -konfigurationen betreffen und andere zwischengeschaltete Verarbeitungsentitäten und Architekturen können ebenfalls verwendet werden, um die vorliegend beschriebenen Ausführungsformen umzusetzen.
  • 1. AUSFÜHRUNGSFORMEN FÜR WAHRNEHMUNG ÜBER DYNAMISCHE KONTEXTBEZOGENE STRABENBELEGUNGSKARTEN
  • Für die VRU-bezogenen Funktionen in der ITS-Stations- (ITS-S-) Architektur, die in [TS103300-2] dargestellt sind, können unter anderem die Funktionen wie das Sensorsystem VRU 116/117, lokale Sensordatenfusion und -betätigung, lokale Wahrnehmung und bewegungsdynamische Vorhersage die Daten, die für das Gesamtkontextbewusstsein der Umgebung benötigt werden, an einem Ego-VRU 116/117 in Bezug auf Standort, Geschwindigkeit, Geschwindigkeitsvektor, Kurs, Absicht und andere Merkmale anderer ITS-Ss auf oder in der Nähe eines Straßensegments bereitstellen. Die anderen ITS-Ss auf der Straße beinhalten neben dem Ego-VRU 116/117 die R-ITS-Ss 130, V-ITS-S 110 und VRUs 116/117, die sich in der unmittelbaren Betriebsumgebung des Ego-VRU 116/117 befinden. Eine solche kontextbezogene Bewusstseinsdatenerzeugung und ein -austausch zwischen den beteiligten ITS-Ss ist somit der Schlüssel zum Ermöglichen einer robusten Kollisionsrisikoanalyse und zum anschließenden Ergreifen von Maßnahmen zur Kollisionsrisikovermeidung an der ITS-S-Anwendungsschicht. Neben dem Vorstehenden ist die ITS-S-Anwendungsschicht zudem für Funktionalitäten verantwortlich, die kooperative Wahrnehmung, Ereignisdetektion, Manöverkoordination und anderes beinhalten. Andererseits ist der in der Facilities-Schicht befindliche VRU-Basisdienst dafür zuständig, die für VRU spezifischen Funktionalitäten zusammen mit den Schnittstellen, die auf die ITS-S-Architektur abgebildet werden, zu ermöglichen. Die Schnittstellen sind für Datenaustausch unter verschiedenen anderen Diensten zuständig, die sich in der Facilities-Schicht befinden, wie etwa Position und Zeit (POTI, position and time), lokale dynamische Karte (LDM, local dynamic map), Datenanbieter und anderes. Zusätzlich beruht der VRU-Basisdienst auch auf anderen Anwendungsunterstützungseinrichtungen, wie etwa Cooperative Awareness Service (CAS, Dienst für kooperatives Bewusstsein), Decentralized Environmental Notification (DEN) Service (Dienst für dezentralisierte Umgebungsbenachrichtigung), Collective Perception Service (CPS, Dienst für kollektive Wahrnehmung), Maneuver Coordination Service (MCS, Dienst für Manöverkoordinierung), Infrastrukturdienst usw.
  • Des Weiteren ist der VRU-Basisdienst (VBS), der sich in der Facilities-Schicht befindet, mit anderen Anwendungsunterstützungseinrichtungen verknüpft, von denen eine der Manöverkoordinationsdienst (MCS) ist, wie in VRU-bezogenen Funktionen in der ITS-Stationsarchitekturdefinition durch [TS103300-2] dargestellt ist. Wie MCS in einem Fahrzeugsubsystem von ITS sollten MCS in VRU-Subsystemen auch für das Teilen, Verhandeln und Koordinieren von Manövern, einschließlich Trajektorieplanung auf koordinierte Weise, ausgelöst durch eine Kollisionsrisikoanalyse, zuständig sein, so dass jegliche mögliche Kollision vermieden werden kann. Der VRU-Basisdienst ist zudem dafür zuständig, die VRU-Bewusstmachungsnachricht (VAM) zu übertragen, um die Beurteilung des möglichen Kollisionsrisikos des VRU 116/117 mit den anderen Straßenbenutzern zu ermöglichen, die andere VRUs, Nicht-VRUs, Hindernisse, die plötzlich auf der Straße erscheinen, und anderes sein können.
  • MCS ermöglicht nahegelegenen ITS-Ss (einschließlich zwischen V-ITS-Ss 110 und Infrastruktur), Informationen auszutauschen, die Fahrautomatisierungsfunktionen automatisierter und verbundener V-ITS-Ss 110 erleichtern und unterstützen. Insbesondere ermöglicht MCS, dass nahegelegene V-ITS-Ss 110 ihre Manöverabsichten (z.B. Spurwechsel, Fahrspurdurchgänge, Überholvorgänge, Einfädelvorgänge, Drift in die Ego-Fahrspur und dergleichen), geplante Trajektorie, erkannte Verkehrssituationen, ITS-S-Zustand und/oder andere ähnliche Informationen teilen. MCS stellt eine Art der Manöverhandlung und Interaktion zwischen nahen V-ITS-Ss 110 für sicheres, zuverlässiges, effizientes und komfortables Fahren bereit. MCS kann einen Nachrichtentyp nutzen, der als Manöverkoordinationsnachricht (MCM) bezeichnet wird. MCMs beinhalten einen Satz von DEs und/oder DFs zum Übertragen von Status, Trajektorie und Manöverabsicht der V-ITS-S 110. Beispiele für MCMs sind ausführlicher in der vorläufigen US-Anmeldung Nr. 62/930,354, „Maneuver Coordination Service For Vehicular Networks“ („Manöverkoordinationsdienst für Fahrzeugnetzwerke“), eingereicht am 4. November 2019 („[a1]“), und der vorläufigen US-Anmeldung Nr. 62/962,760 , „Maneuver Coordination Service For Intelligent Transportation System“ („Manöverkoordinationsdienst für intelligentes Transportsystem“), eingereicht am 17. Januar 2020 („[a2]“), beschrieben. MCS unterstützt eine Verkehrsüberlastungsvermeidungskoordination (z.B. wenn eine V-ITS-S 110 aufgrund von parallelen langsamen Fahrzeugen vor ihr auf allen Fahrspuren blockiert wird), Verkehrseffizienzverbesserung (z.B. Auffahren auf eine Autobahn, Verlassen einer Autobahn, Einfahren/Ausfahren in/aus Kreisverkehren, Bestätigen der Absicht des Fahrzeugs, wie etwa irrtümliches Rechtsblinken eines sich nähernden Fahrzeugs usw.), eine Sicherheitsverbesserung im Manöver (z.B. sicherer und effizienter Spurwechsel, Überholvorgang usw.), intelligente Kreuzungsverwaltung, Notfall-Trajektoriekoordination (z.B. falls ein Hindernis, ein Tier, Kind plötzlich auf eine Spur läuft und mehr als ein Fahrzeug sich auf einen kollektiven Manöverplan einigen muss) usw. MCS kann zudem beim Verbessern des Benutzererlebnisses helfen, indem häufige harte Bremsvorgänge vermieden werden, da vordere und andere (nahe) V-ITS-Ss 110 ihre Absicht im Voraus angeben, wann immer dies möglich ist.
  • Zum Realisieren einer Kollisionsrisikoanalyse und anschließender Kollisionsvermeidung stellt die vorliegende Offenbarung Facilities-Schicht-Lösungen bereit, um das Problem durch kontextbezogenes Bewusstsein der VRU-116/117-Umgebung anzusprechen, die statische Hindernisse, dynamisches/sich bewegende Objekte, statische Hindernisse, andere VRUs und Pufferzonen um fatale Hindernisse herum beinhalten kann, um im Wesentlichen das Bewusstsein der umgebenden statischen/dynamischen Umgebung/Personen am Ego-VRU zu verbessern. Andererseits ist ein Bewusstsein für den Ego-VRU 116/117 unter den umgebenden ITS-Ss ebenso wichtig.
  • Somit weisen in verschiedenen Ausführungsformen eine oder mehrere ITS-S in der Nähe des Ego-VRU 116/117 (einschließlich des Ego-VRU 116/117 selbst) die erforderliche Rechenfähigkeit zum Erzeugen, Aktualisieren und Beibehalten solcher Informationen auf, die vorliegend als dynamische kontextbezogene Straßenbelegungskarte (DCROM) zur Wahrnehmung definiert sind. Andererseits kann der VRU 116/117 in Abhängigkeit von Vorrichtungsfähigkeiten des VRU 116/117 die Fähigkeit aufweisen, eine solche DCROM zu erzeugen, bei der es sich um eine Karte handeln kann, die durch Aggregieren der Wahrnehmungsdaten erhalten wird, die von verschiedenen Klassen von Sensoren erhalten werden (z.B. resultierend aus einer geschichteten Belegungskarte, wie nachstehend erläutert). Somit existieren in Abhängigkeit von VRU-Vorrichtungsfähigkeiten zwei Möglichkeiten, nämlich VRUs (HC-VRUs) 116/117 mit hoher Komplexität und VRUs (LC-VRUs) 116/117 mit niedriger Komplexität.
  • HC-VRUs 116/117 sind VRUs 116/117 mit hochentwickelten Sensor- oder Wahrnehmungsfähigkeiten. HC-VRUs 116/117 können VRU-Typen wie etwa Motorräder und dergleichen (z.B. Profil 3) beinhalten. Die Fähigkeit sollte jedoch nicht ausschließlich auf Profiltypen beschränkt sein, da auch andere VRUs 116/117 als die im Profil 3 (z.B. Mopeds) in der Lage sein können, einige hochentwickelte zusätzliche Vorrichtungen wie etwa GPU-fähige Kameras mitzuführen. Solche Möglichkeiten werden durch die vorliegend erörterten Ausführungsformen nicht ausgeschlossen. Die VRU kann eine Berechnungsfähigkeit mit Sensoren mit höherer Komplexität (z.B. Lidar, Kameras, Radar usw.) und/oder Aktoren für die Umgebungswahrnehmungsfähigkeit aufweisen, und solche VRUs 116/117 können DCROM alleine erzeugen. Des Weiteren könnte eine solche DCROM an einem Ego-VRU 116/117 durch kollaboratives Austauschen von VAMs mit DCROM-bezogenen Feldern erweitert werden.
  • LC-VRUs 116/117 sind VRUs 116/117 ohne hochentwickelte Sensoren oder Wahrnehmungsfähigkeiten. LC-VRUs 116/117 können VRU-Typen wie etwa Fußgänger, Fahrräder und dergleichen (z.B. Profil 1, Profil 2 usw.) beinhalten, die möglicherweise nicht die Rechenfähigkeit aufweisen, um DCROM allein zu erzeugen. Daher müssen die LC-VRUs 116/117 möglicherweise eine DCROM von der nahegelegenen rechenfähigen ITS-S über einen VAM-Austausch beziehen.
  • Zu diesem Zweck lauten die durch die vorliegende Offenbarung adressierten Fragen, die hinsichtlich der Sicherheit des VRU 116/117 in ITS bisher nicht adressiert wurden, wie folgt: Wie soll das kontextbezogene Straßenbelegungsbewusstsein der VRU-116/117-Umgebung repräsentiert werden? Was sind die Mechanismen zum Erzielen, Aufrechterhalten und Aktualisieren eines solchen kontextbezogenen Straßenbelegungsbewusstseins der umliegenden Straßenumgebung bei VRUs 116/117 (sowohl HC-VRUs 116/117 als auch LC-VRUs 116/117) und Nicht-VRUs (z.B. R-ITS-Ss 130, V-ITS-S 110)? Welche Art von Nachrichtenaustauschprotokoll oder -mechanismen zwischen den VRU-ITS-Ss 117 und den benachbarten ITS-Ss werden benötigt, um ein solches kontextbezogenes Straßenbelegungsbewusstsein in der VRU-Funktionsarchitektur zu integrieren? Welche entsprechenden Datenfelder und Bitmaps müssen in den VAM-Container [TS103300-2] eingeführt werden, um DCROM-basierten Umgebungsbewusstseinsaustausch zwischen ITS-Ss zu unterstützen? Was sind die Auswirkungen eines solchen kontextbezogenen Bewusstseins auf Kollisionsrisikoanalyse und Kollisionsrisikoreduktion, einschließlich Trajektorieabfangbewusstsein und Manöveraktionsempfehlungen, vorläufige U. S Anmeldung Nr. 62/967,874, eingereicht am 30. Januar 2020 (AC7761-Z) und _Anmeldung Nr._(AC7386-US/PCT) (gemeinsam „[AC7386]“)[AC7386] in der VRU-ITS-S 117?
  • Die vorliegenden Ausführungsformen betreffen Erhöhen des dynamischen kontextbezogenen Bewusstseins in der VRU-ITS-S 117. Die DCROM ermöglicht allgemein die folgenden Dienste/Funktionalitäten innerhalb der Funktionsarchitektur des VRU-Systems in Bezug auf Kollisionsrisikoanalyse und Kollisionsvermeidung: Verbesserte Wahrnehmung bei HC-VRUs 116/117, LC-VRUs 116/117 sowie benachbarten R-ITS-Ss 130 und V-ITS-Ss 110 über kooperativen Nachrichtenaustausch zwischen den ITS-Ss. Robuste bewegungsdynamische Vorhersage des VRU 116/117, die über verbessertes Bewusstsein über den VRU 116/117 in der ITS aufgrund einer zusätzlichen Wahrnehmungseingabe möglich ist, die durch die DCROM bereitgestellt wird. Ereignisdetektion, wie etwa: Kollisionsrisiko zwischen VRUs 116/117 oder VRUs 116/117, die mit Nicht-VRU-ITS-Ss kollidieren; Änderung der Bewegungsdynamik des VRU 116/117 (Trajektorie, Geschwindigkeitsvektor, Absicht); und plötzliches Auftreten von Hindernissen, Objekten, Personen, statischen Hindernissen, Straßeninfrastrukturteil und dergleichen in der Nähe des VRU 116/117. Trajektorieabfangwahrscheinlichkeitsberechnung und entsprechende Manöveraktion sowie Manöverkoordination zwischen VRUs 116/117 (siehe z.B. [AC7386]).
  • Vorliegend erörterte Ausführungsformen stellen auf kontextbezogenem Straßenbelegungsbewusstsein beruhende VRU-116/117-Sicherheitsermöglichungskonzepte und - mechanismen bereit, darunter, ohne jedoch hierauf eingeschränkt zu sein, Nachrichtenaustauschprotokoll- und Datenfelderweiterungen der VAMs. Vorliegend besprochene Ausführungsformen beinhalten: (1) Dynamische kontextbezogene Straßenbelegungskarte (DCROM) zur Wahrnehmung (DCROMP) einer VRU-116/117-Umgebung, die basierend auf dem Prinzip geschichteter Kostenkarten abgeleitet wird (siehe z.B. Lu et al., „Layered Costmaps for Context-Sensitive Navigation“ (geschichtete Kostenkarten für kontextsensitive Navigation), IEEE/RSJ International Conference on Intelligent Robots and Systems (IROS), Chicago, IL, IEEE, S. 709-715 (Sept. 2014) („[LU]“); (2) Format zum Darstellen der DCROM der VRU-116/117-Umgebung hinsichtlich einer Einzelschicht-Belegungsgitterkarte; (3) VAM-Nachrichtenaustauschprotokoll und -mechanismen zum kollaborativen Teilen von DCROM unter VRUs 116/117 sowie zwischen VRUs 116/117 und benachbarten ITS-Ss; und (4) Einzelheiten von VAM-Datenfeldern und Bitmaps, um den Austausch von DCROM-bezogenen Daten hinsichtlich zweier neuer Datenfelder, (i) probabilistischer Belegungsstatusindikator (OSI) und (ii) Gitterstandortindikator (GLI), zu unterstützen. Die vorliegenden Ausführungsformen ermöglichen die Sicherheit des VRU 116/117 in ITS, was die Robustheit der V-ITS-S 110 bei der rechtzeitigen Kollisionsrisikoanalyse und Kollisionsvermeidung verbessert. Die vorliegenden Ausführungsformen eignen sich gut zum Ermöglichen der Sicherheit von Verkehrsteilnehmern auch in autonomen V-ITS-Ss 110.
  • 1.1. AUSFÜHRUNGSFORMEN ZUR ERZEUGUNG DYNAMISCHER KONTEXTBEZOGENER STRAßENBELEGUNGSKARTEN
  • In VRUs kann das Vorhandensein eines kontextbezogenen Bewusstseins der Straßenbelegungsumgebung verwendet werden, um die zuvor für das VRU-116/117-Kollisionsvermeidungssubsystem des ITS umrissenen Probleme zu behandeln und eine kooperative Kollisionsrisikoanalyse in der Nähe der Umgebung des VRU-116/117 und manöverbezogene Aktionen für den Ego-VRU 116/117 sowie für die benachbarten VRUs 116/117 (und Nicht-VRUs), die gefährdet sind, zu ermöglichen. In verschiedenen Ausführungsformen wird ein auf [LU] basierender Ansatz mit geschichteten Kostenkarten verwendet, um die DCROM aufzubauen. Die DCROM erzeugt das Bewusstsein der räumlichen VRU-116/117-Umgebungsbelegung.
  • 2 zeigt einen beispielhaften Ansatz 200 mit geschichteten Belegungskarten zum Erstellen einer dynamischen kontextbezogenen Straßenbelegungskarte (DCROM) 205 der VRU-116/117-Umgebung, die für HC-VRUs 116/117, R-ITS-Ss 130 und/oder V-ITS-Ss 110 anwendbar ist, gemäß verschiedenen Ausführungsformen. Die DCROM 205 entspricht der aggregierten Belegung, die durch die Master-Schicht (oder in 2 „Master-Gitter“) repräsentiert wird.
  • Eine Belegungskarte (oder „Kostenkarte“) ist eine Datenstruktur, die ein 2D-Gitter von Belegungswerten enthält, das bzw. die für Wegplanung verwendet wird/werden. Mit anderen Worten repräsentiert eine Belegungskarte den Planungssuchraum um eine V-ITS-S 110, eine VRU 116/117, einen Roboter oder ein anderes bewegliches Objekt herum. Die Belegungskarte ist eine gitterbasierte Darstellung eines Bereichs oder einer Region, der/die einen Satz von Zellen oder Blöcken umfasst. Eine oder mehrere der Zellen enthalten Werte, die eine Wahrscheinlichkeit angeben, dass ein spezifischer Typ von Hindernis, Objekt und/oder VRU 116/117 in einem durch diese Zelle dargestellten Bereich vorhanden ist. Die Gitter- oder Zellenwerte in der Belegungskarte werden als „Belegungswerte“ oder „Kostenwerte“ bezeichnet, die die Wahrscheinlichkeit repräsentieren, die mit dem Eintreten in oder Durchqueren jeweiliger Gitterzellen assoziiert ist. Belegungskarten werden zum Navigieren oder anderweitigen Fortbewegen durch dynamische Umgebungen verwendet, die Objekte enthalten. Für viele Anwendungsfälle, wie etwa CA/AD-Fahrzeuge und/oder (semi-)autonome Robotik, berücksichtigt der Fahrweg nicht nur die Start- und Endziele, sondern hängt auch davon ab, ob zusätzliche Informationen über die größeren Kontexte verfügbar sind. Informationen über die Umgebung, die die Wegplaner verwenden, werden in der Belegungskarte gespeichert.
  • ITS-Ss (z.B. V-ITS-Ss 110 und/oder VRU-ITS-Ss 117) können einem globalen Gitter mit gleicher Größe der Zellendarstellung folgen. Einzelne ITS-Ss bereiten ihre eigenen Belegungskarten mit einer vordefinierten Form und Größe vor. In einigen Implementierungen ist die Belegungskarte eine rechteckige Form mit einer Größe mit spezifizierten Abmessungen (z.B. n Zellen mal m Zellen, wobei n und m Zahlen sind) im Sichtfeld (FOV, field of view) eines oder mehrerer Sensoren oder Antennenelemente. Wenn das Teilen von Belegungskarten aktiviert ist, kann eine ITS-S eine Belegungskarte mit größerer Größe oder eine Belegungskarte mit gleicher Größe wie für die eigene Verwendung der ITS-S vorbereiten. Das Teilen der Belegungskarte kann Änderungen in den Abmessungen der Belegungskarte erfordern, die zur eigenen Verwendung vorbereitet wurde, da Nachbar-ITS-Ss unterschiedliche Fähigkeiten aufweisen und/oder sich an unterschiedlichen Standorten/Spuren befinden und sich in verschiedenen Richtungen bewegen.
  • Der Belegungswert (oder „Kostenwert“) in jeder Zelle der Belegungskarte stellt eine Wahrscheinlichkeit (oder „Kosten“) des Navigierens durch diese Gitterzelle dar. Mit anderen Worten bezieht sich der Belegungswert auf eine Wahrscheinlichkeit, dass eine gegebene Zelle frei (unbelegt), durch ein Objekt belegt oder unbekannt ist. In einigen Implementierungen kann der Zustand jeder Gitterzelle entweder frei (unbelegt), belegt oder unbekannt sein, wobei berechnete Wahrscheinlichkeiten in eine der zuvor genannten Kategorien umgewandelt oder übersetzt werden. In anderen Implementierungen können die berechneten Wahrscheinlichkeiten selbst in jeweilige Zellen eingefügt oder hinzugefügt werden.
  • Die Belegungswerte der Belegungskarte können von der ITS-S zu einem aktuellen Zeitpunkt wahrgenommene Kosten und/oder Kosten sein, die zu einem spezifischen zukünftigen Zeitpunkt vorhergesagt werden (z.B. zu einem zukünftigen Zeitpunkt, zu dem die Station beabsichtigt, sich unter einem Spurwechselmanöver auf eine neue Spur zu bewegen). Falls die ursprüngliche Belegungskarte die zum aktuellen Zeitpunkt wahrgenommenen Kosten enthält, ist sie entweder in der MCM oder einer CPM enthalten, aber nicht in beiden, um den Aufwand zu reduzieren. Eine differenzielle Kostenkarte kann jedoch entweder in einer MCM, einer CPM oder beiden gleichzeitig enthalten sein, um schnelle Aktualisierungen der Kostenkarte zu ermöglichen. Falls zum Beispiel eine Kostenkartenaktualisierung durch ein Ereignis ausgelöst wird und die Station für MCM-Übertragung geplant ist, kann die aktualisierte Kostenkarte in der MCM enthalten sein.
  • Eine geschichtete Belegungskarte verwaltet eine geordnete Liste von Schichten, von denen jede die Daten in Bezug auf eine spezifische Funktionalität und/oder einen spezifischen Sensortyp verfolgt. Die Daten für jede Schicht werden dann in eine Master-Belegungskarte akkumuliert, was zwei Durchläufe durch die geordnete Liste von Schichten erfordert. In dem veranschaulichten Beispiel weist die geschichtete Belegungskarte anfänglich vier Schichten und die Master-Belegungskarte („Master-Schicht“ in 2) auf. Die statische Schicht („statische Karte“), die Hindernisschicht, die Proxemikschicht und die Aufweitungsschicht behalten ihre eigenen Kopien des Gitters bei. In anderen Implementierungen behalten die statische, die Hindernis- und die Proxemik-Schicht ihre eigenen Kopien des Gitters bei, während dies bei der Aufweitungsschicht nicht der Fall ist. Um die Belegungskarte zu aktualisieren, wird ein updateBounds-(aktualisiereGrenzen-) Verfahren aufgerufen und auf jeder Schicht durchgeführt, beginnend mit der ersten Schicht in der geordneten Liste. Das updateBounds-Verfahren fragt jede Schicht ab, um zu bestimmen, wie viel der Belegungskarte sie aktualisieren muss. Um die neuen Grenzen zu bestimmen, aktualisieren die Hindernis-, die Proxemik- und die Aufweitungsschicht ihre eigenen Belegungskarten mit neuen Sensordaten. Bei diesem Beispiel verwendet jede Schicht einen jeweiligen Sensordatentyp, während in anderen Ausführungsformen jede Schicht mehrere Arten von Sensordaten nutzen kann. Das Ergebnis ist ein Begrenzungsrahmen, der alle Bereiche enthält, die jede Schicht aktualisieren muss. Es wird über die Schichten der Reihe nach iteriert, wobei jeder Schicht der Begrenzungsrahmen bereitgestellt wird, den die vorherigen Schichten aktualisieren müssen (anfänglich einen leeren Rahmen). Jede Schicht kann den Begrenzungsrahmen nach Bedarf erweitern. Dieser erste Durchlauf führt zu einem Begrenzungsrahmen, der bestimmt, wie viel von der Master-Belegungskarte aktualisiert werden muss. Als Nächstes aktualisiert jede Schicht wiederum die Master-Belegungskarte in dem Begrenzungsrahmen unter Verwendung eines update Values- (aktualisiereWerte-) Verfahrens, beginnend mit der statischen Schicht, gefolgt von der Hindernisschicht, der Proxemikschicht und dann der Aufweitungsschicht. Während dieses zweiten Durchlaufs wird das update Values- Verfahren aufgerufen, während dessen jede nachfolgende Schicht die Werte innerhalb des Bereichs des Begrenzungsrahmens der Master-Belegungskarte aktualisiert. In einigen Implementierungen arbeitet das updateValues-Verfahren direkt mit der Master-Belegungskarte, ohne eine lokale Kopie zu speichern. In anderen Ausführungsformen können andere Verfahren zum Aktualisieren der Belegungskarte verwendet werden.
  • In 2 beinhaltet die geschichtete Belegungskarte eine statische Kartenschicht, eine Hindernisschicht, eine Proxemikschicht, eine Aufweitungsschicht und die Master-Belegungskartenschicht. Die statische Kartenschicht beinhaltet eine statische Karte verschiedener statischer Objekte/Hindernisse, die für die globale Planung verwendet wird. Die statische Karte kann mit einem SLAM- (simultaneous localization and mapping, simultane Lokalisierung und Kartierung) Algorithmus a priori erzeugt werden oder kann aus einem Architekturschema erzeugt werden. Wenn die statische Kartenschicht die statische Karte empfängt, liefert updateBounds einen Begrenzungsrahmen zurück, der die gesamte Karte abdeckt. Bei anschließenden Iterationen nimmt die Größe des Begrenzungsrahmens nicht zu. Da die statische Karte die unterste Schicht der globalen geschichteten Belegungskarte ist, können die Werte in der statischen Karte direkt in die Master-Belegungskarte kopiert werden. Wenn der Roboter (z.B. V-ITS-S 110, VRU 116/117, Drohne, UAV, usw.) unter Verwendung der erzeugten Karte für Navigation SLAM ausführt, ermöglicht der Ansatz mit geschichteter Belegungskarte, dass die statische Kartenschicht aktualisiert wird, ohne Informationen in den anderen Schichten zu verlieren. In monolithischen Belegungskarten würde die gesamte Belegungskarte überschrieben werden.
  • Die Hindernisschicht sammelt Daten von hochpräzisen Sensoren wie etwa Lasern (z.B. LiDAR), Rot-Blau-Grün-und-Tiefe- (RGB-D-) Kameras und/oder dergleichen, und platziert die gesammelten Hochpräzisionssensordaten in ihrem eigenen 2D-Gitter. Der Raum zwischen dem Sensor und dem Sensormesswert wird als „frei“ markiert und der Standort des Sensormesswerts wird als „belegt“ markiert. Während des updateBounds-Teils jedes Zyklus werden neue Sensordaten in der Belegungskarte der Hindernisschicht platziert und der Begrenzungsrahmen wird erweitert, um ihn anzupassen. Das genaue Verfahren, das die Werte der Hindernisschicht mit denen kombiniert, die sich bereits in der Belegungskarte befinden, kann in Abhängigkeit von dem gewünschten Vertrauensniveau für die Sensordaten variieren. In einigen Implementierungen können die statischen Kartendaten mit den gesammelten Sensordaten übergeschrieben werden, was für Szenarien vorteilhaft sein kann, in denen die statische Karte ungenau sein kann. In anderen Implementierungen kann die Hindernisschicht dazu konfiguriert sein, der Master-Belegungskarte nur fatale oder VRU-bezogene Hindernisse hinzuzufügen.
  • Die Proxemikschicht wird verwendet, um VRUs 116/117 und/oder Räume, die einzelne VRUs 116/117 umgeben, zu detektieren. Die Proxemikschicht kann zudem Daten von Sensoren mit hoher Genauigkeit wie etwa Lasern (z.B. LiDAR), RGB-D-Kameras usw. sammeln. In einigen Implementierungen kann die Proxemikschicht Kameras oder andere ähnliche Sensoren mit geringerer Genauigkeit verwenden. Die Proxemikschicht kann die gleichen oder andere Sensordaten oder Sensortypen als die Hindernisschicht verwenden. Die Proxemikschicht verwendet den Standort/die Position und den Geschwindigkeitsvektor detektierter VRUs 116/117 (z.B. extrahiert aus den Sensordaten, die einzelne VRUs 116/117 repräsentieren), um Werte in die Belegungskarte der Proxemikschicht zu schreiben, die dann zusammen mit den Belegungskartenwerten der anderen Schichten in die Master-Belegungskarte hinzugefügt werden. In einigen Implementierungen verwendet die Proxemikschicht eine Mischung aus Gauß-Modellen (siehe z.B. Kirby et al., „COMPANION: A Constraint-Optimizing Method for Person-Acceptable Navigation“ (COMPANION: Einschränkungsoptimierungsverfahren für personenakzeptable Navigation, Proceedings of the 18th IEEE Symposium on Robot and Human Interactive Communication (Ro-Man), Toyama, Japan, S. 607-612 (2009) und/oder Goncalves et al., „Human-aware Navigation for autonomous Mobile Robots for Intra-Factory Logistics“ (Menschen erkennende Navigation für autonome mobile Roboter für Betriebslogistik), International Workhop on Symbiotic Interaction, Lecture Notes in Computer Science, Bd. 10727, S. 79-85, Springer (23. Mai 2018)) und schreibt die Gaußschen Werte für jeden VRU 116/117 in die private Belegungskarte der Proxemikschicht. In einigen Implementierungen können die erzeugten Werte gemäß der Amplitude, der Varianz und/oder einem oder mehreren anderen geeigneten Parametern skaliert werden.
  • Die Aufweitungsschicht implementiert einen Aufweitungsprozess, der eine Pufferschicht um fatale Hindernisse herum einfügt. Standorte, an denen die V-ITS-S 110 sicher kollidieren würde, sind mit einem fatalen Wahrscheinlichkeitswert/Belegungswert markiert und die unmittelbar umliegenden Bereiche weisen geringe nicht-fatale Kosten auf. Diese Werte stellen sicher, dass die V-ITS-S 110 nicht mit fatalen Hindernissen kollidiert und versucht, solche Objekte zu vermeiden. Das updateBounds-Verfahren erweitert den vorherigen Begrenzungsrahmen, um sicherzustellen, dass neue fatale Hindernisse aufgeweitet werden, und dass alte fatale Hindernisse außerhalb des vorherigen Begrenzungsrahmens, die sich in den Begrenzungsrahmen aufweiten könnten, ebenfalls aufgeweitet werden.
  • Aus 2 können die VRU-ITS-Ss 117 (wie etwa die HC-ITS-Ss 117), die R-ITS-Ss 130 und/oder die V-ITS-Ss 110 ihre verschiedenen Sensoren (z.B. Laser/LiDAR, Kameras, Radar usw.) zusammen mit einer statischen Karte nutzen, die apriori bestimmt wird, um eine aggregierte Master-Belegungskarte des Straßennetzes zu erhalten. Des Weiteren kann eine solche Master-Belegungskarte zudem periodisch über eine Zusammenarbeit zwischen den HC-ITS-Ss 117, den LC-ITS-Ss 117, den R-ITS-Ss 130 und den V-ITS-Ss 110 erweitert werden, was eine periodische Aktualisierung und Wartung einer solchen robusten aktuellen aggregierten Karte (z.B. der DCROM 205) ermöglicht. Sobald eine solche genaue Master-Schicht-Karte erhalten wurde, kann sie umfassend die gemeinsame Wirkung eines Kontextbewusstseins darstellen, das aus verschiedenen Schichten gewonnen wird und zu einer genauen Straßenbelegungskarte (z.B. der DCROM 205) führt. Die Rolle der DCROM 205 beim Ermöglichen einer Sicherheitsrobustheit des VRU 116/117, einschließlich der Rolle der DCROM 205 innerhalb des in [TS103300-2] bereitgestellten Sicherheitsmechanismenprozesses des VRU 116/117, wird im Folgenden erörtert.
  • 1.2. DYNAMISCHE KONTEXTBEZOGENE STRABENBELEGUNGSKARTE IN VRU-SICHERHEITSMECHANISMEN
  • 3 zeigt einen beispielhaften VRU-Sicherheitsmechanismenprozess 300 gemäß [TS103300-2], der Detektion von VRUs 116/117, Kollisionsrisikoanalyse (CRA) und Kollisionsrisikoreduktion beinhaltet, gemäß verschiedenen Ausführungsformen. Der Prozess 300, einschließlich wo der DCROM-Ansatz zum Ermöglichen der Sicherheit des VRU 116/117 angewendet werden kann, beginnt bei Schritt 301, bei dem die Detektion des potentiell gefährdeten VRU(s) 116/117 erfolgt. Die Detektion von potentiell gefährdeten VRU(s) 116/117 kann über die Ego-VRU-ITS-S 117, andere Verkehrsteilnehmer (z.B. Nicht-VRUs, wie etwa die V-ITS-S 110, andere VRUs 116/117 usw.) und/oder die R-ITS-S 130 erfolgen. In einigen Ausführungsformen ermöglicht die DCROM 205 eine Detektion potentiell gefährdeter VRU(s) 116/117. Die Detektion des potentiell gefährdeten VRU 116/117 kann leicht über die Verfügbarkeit der DCROM 205 an den HC-VRUs 116/117, R-ITS-Ss 130 und/oder den V-ITS-Ss 110 erweitert werden, um die Szene zu analysieren und festzustellen, wo der Ego-VRU 116/117 aktuell in der Belegungsgitterkarte detektiert wird, zusammen mit der umliegenden Umgebung, die (für den VRU 116/117) potentiell gefährliche V-ITS-Ss 110, Hindernisse und andere Entitäten umfassen kann. Es wird angemerkt, dass zusätzlich zu den HC-VRUs 116/117, R-ITS-Ss 130 oder V-ITS-Ss 110, die die Rechenfähigkeit aufweisen, selbst LC-VRUs 116/117 ebenfalls eine frühere DCROM 205 zur Verfügung haben können (aufgrund kollaborativer gemeinsamer Nutzung von DCROM 205-bezogenen Informationen durch die HC-VRUs 116/117, RSEs oder V-ITS-Ss 110 in vorherigen Ereignissen), die sie verwenden können, um zu detektieren, ob sie potentiell gefährdet sind.
  • Schritt 302a beinhaltet VAM-Vorübertragungs-Auslösebedingungsbewertungen. In einigen Ausführungsformen beinhalten VAM-Vorübertragungs-Auslösebedingungsbewertungen eine Vorbereitung einer Übertragung einer auf Kollisionsrisiko- und Nachrichtenauslösebedingungsbewertung basierenden VAM (oder dergleichen) mit Informationen über beispielsweise eine Ego-VRU-Position; einen dynamischen Zustand des Ego-VRU 116/117 und anderer VRUs 116/117 oder Nicht-VRUs; Vorhandensein anderer Verkehrsteilnehmer; Straßenlayout und -umgebung und/oder dergleichen. In einigen Ausführungsformen ermöglicht die DCROM 205 VAM-Vorübertragungsbedingungsbewertungen. Nachdem der potentiell gefährdete VRU 116/117 detektiert wurde, kann die verfügbare DCROM 205 verwendet werden, um die Auslösebedingungen zu bestimmen. Beispielsweise kann eine DRCOMP-Analyse verwendet werden, um zu identifizieren, ob sich eine sich nähernde V-ITS-S 110 oder ein anderes sich schnell bewegendes Objekt zu nahe am Ego-VRU 116/117 befindet oder nicht. Falls dies der Fall ist, dient dies als VAM-Übertragungsauslösung (z.B. bei R-ITS-Ss 130, V-ITS-Ss 110 und/oder VRUs 116/117, die Zugriff auf eine solche DRCOMP haben), um den Ego-VRU 116/117 über die entgegenkommende Gefahr zu benachrichtigen. Schritt 302b beinhaltet eine VAM-Übertragung (Tx) aufgrund gefährdeter Verkehrsteilnehmer durch den Ego-VRU 116/117, Nicht-Ego-VRUs 116/117, V-ITS-Ss 110, R-ITS-Ss 130 und/oder andere ähnliche Elemente.
  • Schritt 303 beinhaltet Aufbauen/Aktualisieren einer LDM (lokalen dynamischen Karte) und Trajektorieabfangwahrscheinlichkeitsberechnung. VAM-Rx- und Kollisionsrisikobeurteilung an den VAM-Empfänger-ITS-Ss unter Verwendung von beispielsweise Sensordatenfusion am Ego-VRU 116/117; empfangene Daten von anderen Verkehrsteilnehmern: V-ITS-Ss 110, R-ITS-Ss 130, gefährdete VRU(s) 116/117 oder andere VRU-ITS-S 117; Aufbauen oder Aktualisieren der LDM, um Standort, Geschwindigkeitsvektor, Absicht, Trajektorie anderer Verkehrsteilnehmer wiederzugeben (z.B. über Trajektorieabfangwahrscheinlichkeit). Trajektorieabfangung wird in [AC7386] besprochen. Die DCROM 205 ermöglicht das Aufbauen/Aktualisieren der LDM und die Trajektorieabfangwahrscheinlichkeitsberechnung. Die DCROM 205 ist in der Lage, bei der Bewertung der Kollisionsrisikoauslösebedingungen, die aus der Position des Ego-VRU 116/117 oder seinem dynamischen Zustand relativ zu anderen VRUs 116/117, dem Status von Verkehrsteilnehmern in der Umgebung sowie den Aktualisierungen der Straßenverlaufsumgebung resultieren, zu helfen. Nach der Auslösebedingungsbeurteilung erfolgt die VAM-Übertragung, falls der VRU 116/117 gefährdet ist. Der Ego-VRU 116/117 und die anderen ITS-S-Benutzer in der Nähe sind an ihren jeweiligen Enden an der Nachrichtenübertragung beteiligt.
  • Schritt 304 beinhaltet Manöveraktionsempfehlungen und Kollisionsvermeidungsmaßnahmen. Die Manöveraktionsempfehlungen basieren auf den erweiterten Daten, die aus der gemeinsamen Nutzung der DCROM 205 verfügbar sind, wobei das Kollisionsrisikoanalysemodul (z.B. am Ego-VRU 116/117, anderen VRUs 116/117, V-ITS-Ss 110, R-ITS-Ss 130 und/oder anderen Nicht-VRUs 116/117 in der Nähe) ausgelöst wird, um über ein etwaiges potentiell hohes Kollisionsrisiko zu entscheiden. Falls ein hohes Kollisionsrisiko detektiert wird, führt das Kollisionsvermeidungsmodul eine oder mehrere manöverbezogene Aktionen (z.B. Kollisionsvermeidungsaktionen) durch, wie etwa Notbremsung, Abbremsen, Beschleunigung, Trajektorieänderung sowie auf dynamische Bewegungen/Impulse des VRU 116/117 bezogene Aktionen. Solche Aktionen müssen rechtzeitig ausgeführt werden, um potentielle Kollisionen zu vermeiden. Zusätzlich oder alternativ kann die Kollisionsvermeidungsaktion Warnnachrichten an den gefährdeten VRU; Warnnachrichten an andere benachbarte ITS-Ss; Manöveraktionsempfehlung für den gefährdeten VRU; Manöveraktionsempfehlung für den sich nähernden Verkehrsteilnehmer; Audiovisuelle Warnung (z.B. Sirenen, blinkende Lichter an der R-ITS-S 130 oder der V-ITS-S 110) beinhalten. Die DCROM 205 ermöglicht die Manöveraktionsempfehlungen.
  • 1.3. VRU-SICHERHEITSMECHANISMUS EINSCHLIEßLICH AUF VAM-AUSTAUSCH BASIERENDER AKTIVIERUNG VON DCROM-BASIERTER ERMÖGLICHUNG
  • Um VRUs 116/117 zu ermöglichen, sich der DCROM 205 zum Verbessern einer Kollisionsrisikoanalyse und Auslösen von rechtzeitigen Kollisionsvermeidungsmaßnahmen bewusst zu werden, beinhalten Ausführungsformen DCROM-basierte Ermöglichung der Sicherheit des VRU 116/117 einschließlich VAM-Austauschmechanismen.
  • 4 veranschaulicht eine beispielhafte Prozedur 400 für VRU-Sicherheitsmechanismen einschließlich Erzeugung einer DCROM 205 an nahegelegenen HC-VRUs ITS-Ss 117, R-ITS-Ss 130 und/oder V-ITS-Ss 110, und VAM-Austauschmechanismen einschließlich eines Belegungsstatusindikators (OSI) und eines Gitterstandpunktindikators (GLI) zum Erweitern der Kollisionsrisikobeurteilung und Auslösen von Kollisionsrisikovermeidung.
  • Die Prozedur 400 aus 4 zeigt die Operationen, die durch eine LC-VRU-ITS-S 401, eine Ego-VRU-ITS-S 402 und eine HC-VRU-ITS-S 403 durchgeführt werden, die jeweils einer vorliegend besprochenen LC- oder HC-VRU-ITS-S 117 entsprechen können. In 4 kann die HC-VRU-ITS-S 403 eine beliebige Kombination einer oder mehrerer HC-VRU-ITS-Ss 117, einer oder mehrerer V-ITS-Ss 110 und/oder einer oder mehrerer R-ITS-Ss 130 repräsentieren, die jeweils hochentwickelte Sensorfähigkeiten aufweisen und sich in der Nähe der Ego-VRU-ITS-S 402 befinden. Die Ego-VRU-ITS-S 402 ist in diesem Beispiel eine LC-VRU-ITS-S 117, die keine hochentwickelten Sensorfähigkeiten aufweist. Außerdem repräsentiert die LC-VRU-ITS-S 401 in 4 eine oder mehrere andere LC-VRUs 116/117, die sich von der Ego-VRU-ITS-S 402 unterscheiden und die sich in der Nähe der Ego-VRU-ITS-S 402 befinden können. Die Prozedur 400 aus 4 kann wie folgt arbeiten.
  • Unter Bezugnahme auf die LC-VRU-ITS-S 401 sammelt und verarbeitet die LC-VRU-ITS-S 401 in Schritt 0 ihre eigenen LC-VRU-ITS-S 401-Sensordaten, die von ihren eingebetteten, angeschlossenen, peripheren oder anderweitig zugänglichen Sensoren gesammelt werden. Die Sensordaten können zum Beispiel ID, Position, Profil, Geschwindigkeit, Richtung, Orientierung, Trajektorie, Geschwindigkeitsvektor, usw. beinhalten. In Schritt 1 führt die LC-VRU-ITS-S 401 eine anfängliche VAM-Konstruktion zur Unterstützung des OMP-Bewusstseins an einer oder mehreren benachbarten rechenfähigen ITS-Ss durch. In Schritt 2a empfängt die LC-VRU-ITS-S 401 eine VAM von der Ego-VRU-ITS-S 402. Bei Schritt 2b überträgt die LC-VRU-ITS-S 401 die konstruierte VAM an die Ego-VRU-ITS-S 402, und in Schritt 2c erfolgt ein VAM/CAM/DENM-Austausch zwischen der LC-VRU-ITS-S 401 und der HC-VRU-ITS-S 403. In Schritt 3 aktualisiert die LC-VRU-ITS-S 401 ein oder mehrere DCROM 205-Merkmale basierend auf OSI- und GLI-Daten, die von anderen ITS-Ss (z.B. der Ego-VRU-ITS-S 402, der HC-VRU-ITS-S 403 und/oder anderen ITS-Ss) eintreffen (z.B. erhalten werden). In Schritt 4 führt die LC-VRU-ITS-S 401 eine Kollisionsrisikoanalyse (CRA) durch, um zu bestimmen, ob ein Kollisionsrisiko hoch ist (z.B. sehr wahrscheinlich oder wahrscheinlicher als nicht; oder bei oder über einer Schwellenkollisionsrisikowahrscheinlichkeit oder innerhalb eines Bereichs von Wahrscheinlichkeiten). Falls das Kollisionsrisiko nicht hoch ist (z.B. unterhalb einer Schwellenkollisionsrisikowahrscheinlichkeit), kehrt die LC-VRU-ITS-S 401 zurück, um bei Schritt 0 weitere Sensordaten zu sammeln. Falls das Kollisionsrisiko hoch ist (z.B. bei oder über einer Schwellenkollisionsrisikowahrscheinlichkeit), geht die LC-VRU-ITS-S 401 zu Schritt 5 über. In Schritt 5 löst die LC-VRU-ITS-S 401 ein/e Kollisionsvermeidungsaktionsmodul/funktion (oder Manöverkoordinierungsdienst- (MCS-) Modul/Funktion) aus, um über einen Kollisionsvermeidungsaktions- und/oder Manövertyp (oder Aktionstyp) zu entscheiden/bestimmen. In Schritt 6 löst die LC-VRU-ITS-S 401 einen MCS für MCC- (Maneuver Coordination Context, Manöverkoordinationskontext) Nachrichtenaustausch aus. In einigen Ausführungsformen ist MCC Teil der Kollisionsrisikovermeidungsfunktionalität, die verwendet wird, um die möglichen Manöveroptionen an der gefährdeten Ego-VRU-ITS-S 402 oder benachbarten VRUs 116/117 anzugeben, wie in [AC7386] erläutert. In Schritt 7 konstruiert oder erzeugt die LC-VRU-ITS-S 401 eine VAM mit einem MCC-Datenfeld. In Schritt 8a empfängt die LC-VRU-ITS-S 401 eine VAM von der Ego-VRU-ITS-S 402. In Schritt 8b überträgt die LC-VRU-ITS-S 401 die erzeugte VAM an die Ego-VRU-ITS-S 402. In Schritt 8c erfolgt ein VAM/DENM-Austausch zwischen der LC-VRU-ITS-S 401 und der HC-VRU-ITS-S 403. In Schritt 9 kehrt die LC-VRU-ITS-S 401 zu Schritt 0 zurück.
  • Unter Bezugnahme auf die Ego-VRU-ITS-S 402 sammelt in Schritt 0 die Ego-VRU-ITS-S 402 Ego-VRU-Sensordaten von ihren eingebetteten, angeschlossenen, peripheren oder anderweitig zugänglichen Sensoren. Die Sensordaten können beispielsweise ID, Position, Profil, Geschwindigkeit, Richtung, Orientierung, Trajektorie, Geschwindigkeitsvektor usw. beinhalten. In Schritt 1 führt die Ego-VRU-ITS-S 402 eine anfängliche VAM-Anfrage zur Unterstützung des DRCOMP 205-Bewusstseins an benachbarten/nahegelegenen rechenfähigen (oder DCROMfähigen) ITS-Ss durch. In Schritt 2a überträgt die Ego-VRU-ITS-S 402 die VAM mit der Anfrage nach DCROM 205-Unterstützung an die LC-VRU-ITS-S 401 und an die HC-VRU-ITS-S 403 (oder sendet die VAM an benachbarte/nahe ITS-Ss aus). In Schritt 2b empfängt die Ego-VRU-ITS-S 402 eine VAM von der LC-VRU-ITS-S 401 und empfängt eine VAM, CAM und/oder DENM von der HC-VRU-ITS-S 403. In Schritt 3 aktualisiert die Ego-VRU-ITS-S 402 DRCOMP 205-Merkmale basierend auf OSI- und GLI-Daten, die von anderen ITS-Ss (z.B. von der LC-VRU-ITS-S 401 und/oder der HC-VRU-ITS-S 403) eintreffen (erhalten werden). In Schritt 3 führt die Ego-VRU-ITS-S 402 eine Kollisionsrisikoanalyse (CRA) durch, um zu bestimmen, ob ein Kollisionsrisiko hoch ist (z.B. sehr wahrscheinlich oder wahrscheinlicher als nicht; oder bei oder über einer Schwellenkollisionsrisikowahrscheinlichkeit oder innerhalb eines Bereichs von Wahrscheinlichkeiten). Falls das Kollisionsrisiko nicht hoch ist (z.B. unterhalb einer Schwellenkollisionsrisikowahrscheinlichkeit), kehrt die Ego-VRU-ITS-S 402 zurück, um bei Schritt 0 weitere Sensordaten zu sammeln. Falls das Kollisionsrisiko hoch ist (z.B. bei oder über einer Schwellenkollisionsrisikowahrscheinlichkeit), geht die Ego-VRU-ITS-S 402 zu Schritt 5 über. In Schritt 5 löst die Ego-VRU-ITS-S 402 ein/e Kollisionsvermeidungsaktionsmodul/funktion (oder MCS-Modul/Funktion) aus, um über einen Kollisionsvermeidungsaktions- und/oder Manövertyp (oder Aktionstyp) zu entscheiden/bestimmen. In Schritt 6 löst die Ego-VRU-ITS-S 402 einen MCS für Manöverkoordinationskontext- (MCC-) Nachrichtenaustausch aus. In einigen Ausführungsformen ist MCC Teil der Kollisionsrisikovermeidungsfunktionalität, die verwendet wird, um die möglichen Manöveroptionen an der gefährdeten Ego-VRU-ITS-S 402 oder benachbarten VRU(s) 116/117 anzugeben, wie in [AC7386] erläutert. In Schritt 7 konstruiert oder erzeugt die Ego-VRU-ITS-S 402 eine VAM mit einem MCC-DF (Datenfeld). In Schritt 8a überträgt die Ego-VRU-ITS-S 402 die VAM mit dem MCC-DF 402 an die LC-VRU-ITS-S 401 und an die HC-VRU-ITS-S 403. In Schritt 8b empfängt die Ego-VRU-ITS-S 402 eine VAM mit einem MCC-DF von der LC-VRU-ITS-S 401 und empfängt eine CAM/DENM mit einem MCC-DF von der HC-VRU-ITS-S 403. Bei Schritt 9 kehrt die Ego-VRU-ITS-S 402 zu Schritt 0 zurück.
  • Unter Bezugnahme auf die HC-VRU-ITS-S 403 extrahiert und/oder sammelt die HC-VRU-ITS-S 403 bei Schritt 0 HC-VRU-ITS-S-Sensordaten von ihren eingebetteten, angeschlossenen, peripheren oder anderweitig zugänglichen Sensoren. In einigen Ausführungsformen kann die HC-VRU-ITS-S 403 Sensordaten von anderen ITS-Ss über ein geeignetes Kommunikations-/Schnittstellenmittel sammeln. Die Sensordaten können beispielsweise Bilddaten (z.B. von Kamera(s)), LIDAR-Daten, Radardaten und/oder andere ähnliche Sensordaten beinhalten. In Schritt 0,5 erzeugt oder erstellt die HC-VRU-ITS-S 403 eine DRCOMP 205 basierend auf den extrahierten/gesammelten Sensordaten: OSI- und GLI-Berechnung. In Schritt 1 konstruiert die HC-VRU-ITS-S 403 eine VAM, CAM und/oder DENM zum Übertragen von DRCOMP 205-Merkmalen einschließlich berechnetem OSI und GLI. In Schritt 2a empfängt die HC-VRU-ITS-S 403 eine VAM von der Ego-VRU-ITS-S 402. In Schritt 2b überträgt die HC-VRU-ITS-S 403 eine VAM/CAM/DENM an die Ego-VRU-ITS-S 402. In Schritt 2c erfolgt ein VAM/CAM/DENM-Austausch zwischen der LC-VRU-ITS-S 401 und der HC-VRU-ITS-S 403. In Schritt 3 aktualisiert die HC-VRU-ITS-S 403 DRCOMP 205-Merkmale basierend auf Daten, die von ihren eigenen Sensoren und/oder zugänglichen Sensoren (z.B. „Eigensensoren“) und Sensoren, die durch andere ITS-Ss implementiert werden, eintreffen (z.B. erhalten werden). In Schritt 4 führt die HC-VRU-ITS-S 403 eine CRA durch, um zu bestimmen, ob ein Kollisionsrisiko hoch ist (z.B. sehr wahrscheinlich oder wahrscheinlicher als nicht; oder bei oder über einer Schwellenkollisionsrisikowahrscheinlichkeit oder innerhalb eines Bereichs von Wahrscheinlichkeiten). Falls das Kollisionsrisiko nicht hoch ist (z.B. unterhalb einer Schwellenkollisionsrisikowahrscheinlichkeit), kehrt die HC-VRU-ITS-S 403 zurück, um bei Schritt 0 weitere Sensordaten zu sammeln. Falls das Kollisionsrisiko hoch ist (z.B. bei oder über einer Schwellenkollisionsrisikowahrscheinlichkeit), geht die HC-VRU-ITS-S 403 zu Schritt 5 über. In Schritt 5 löst die HC-VRU-ITS-S 403 ein/e Kollisionsvermeidungsaktionsmodul/funktion (oder MCS-Modul/Funktion) aus, um über einen Kollisionsvermeidungsaktions- und/oder Manövertyp (oder Aktionstyp) zu entscheiden/bestimmen. In Schritt 6 löst die HC-VRU-ITS-S 403 einen MCS für Manöverkoordinationskontext- (MCC-) Nachrichtenaustausch aus. In einigen Ausführungsformen ist MCC Teil der Kollisionsrisikovermeidungsfunktionalität, die verwendet wird, um die möglichen Manöveroptionen an der gefährdeten Ego-VRU-ITS-S 402 und/oder benachbarten VRU(s) 116/117 anzugeben, wie in [AC7386] erläutert. In einigen Implementierungen kann der MCC einen Trajektorienabfangindikator (trajectory interception indicator, TII) und eine Manöverkennung (maneuver identifier, MI) beinhalten, wobei der TII widerspiegelt, wie wahrscheinlich die Trajektorie der Ego-VRU-ITS-S 402 durch die benachbarten ITSs (z.B. andere VRUs und/oder Nicht-VRUs) abgefangen werden wird, und die MI zeigt die Art des VRU-Manövers an, die zur Vermeidung der vorhergesagten Kollision benötigt wird. In Schritt 7 konstruiert oder erzeugt die HC-VRU-ITS-S 403 eine CAM-, DENM- und/oder VAM-ähnliche Nachricht mit einem MCC-DF. In einigen Ausführungsformen ist MCC (z.B. Schritt 6 in 4) Teil der CRA-Funktionalität, die verwendet wird, um die möglichen Manöveroptionen an der gefährdeten Ego-VRU-ITS-S 402 und/oder benachbarten VRUs 116/117 anzugeben, wie in [AC7386] erläutert. In Schritt 8a empfängt die HC-VRU-ITS-S 403 eine VAM mit dem MCC-DF 402 von der Ego-VRU-ITS-S 402. In Schritt 8b überträgt die HC-VRU-ITS-S 403 die CAM/DENM/VAM einschließlich eines MCC-DF an die Ego-VRU-ITS-S 402. In Schritt 8c erfolgt ein VAM/DENM/CAM-Austausch zwischen der LC-VRU-ITS-S 117 und der HC-VRU-ITS-S 403. Bei Schritt 9 kehrt die Ego-VRU-ITS-S 402 zu Schritt 0 zurück.
  • Wie in 4 gezeigt, beinhaltet die Prozedur 400 zur DCROM-basierten Ermöglichung von VRU-Sicherheit einen VAM-Austausch, wie durch Schritt 1 bis 7 angegeben. Einige Ausführungsformen beinhalten zudem ein Nachrichtenaustauschprotokoll mit zwei neuen DFs, die den OSI und den GLI enthalten. Die DCROM beeinflusst die Funktions-, System- und Betriebsarchitektur und Anforderungsaktualisierungen, die für das VRU-System/die ITS-S 117 benötigt werden. Zusätzlich kann in verschiedenen Ausführungsformen das/die Kollisionsvermeidungsaktions- (oder MCS-) Modul/Funktion eine Manöverkennung (MI) bestimmen oder identifizieren, bei der es sich um eine Kennung eines in MCS verwendeten Manövers handelt. Die Wahl des Manövers kann lokal basierend auf den verfügbaren Sensordaten an der VRU-ITS-S 117 erzeugt werden und kann mit benachbarten ITS-S (z.B. VRUs 116/117 oder Nicht-VRUs) in der Nähe der Ego-VRU-ITS-S 117 geteilt werden, um eine gemeinsame Manöverkoordination zwischen den VRUs 116/117 zu initiieren (vgl. z.B. Klausel 6.5.10.9 von [TS103300-2]).
  • 1.4. BEISPIELHAFTER ANWENDUNGSFALL FÜR DCROM-ERZEUGUNG
  • Zusätzlich zum Erzeugen der DCROM 205 beinhalten einige Ausführungsformen Erzeugen einer entsprechenden VAM mit neuen DFs, um einen DCROM 205-Austausch zu ermöglichen. Die neuen DFs beinhalten ein OSI-Feld und ein GLI-Feld, um die Merkmale der DCROM 205 von einer rechenintensiven ITS-S aus kollaborativ mit LC-VRUs-ITS-Ss 117 zu teilen, wie etwa einer rechenbegrenzten Ego-VRU 116/117 und/oder anderen VRU-Knoten 116/117. Die Konzepte sind durch 5a, 5b und 5c basierend auf beispielhaften Anwendungsfällen veranschaulicht, die in [TS103300-2] erörtert werden.
  • 5a veranschaulicht einen VRU-zu-VRU-bezogenen Anwendungsfall 500a aus [TR103300-1], für den das Konzept von DCROM veranschaulicht ist. In 5a fährt ein Fahrradfahrer auf dem Gehweg (Fußgängerweg), wobei mehrere Fußgänger entlang der Trajektorie des Fahrradfahrers zu sehen sind. Zudem gibt es andere Objekte wie etwa einen Lichtmast, Bäume, Bänke, Gebäude und sich nähernde Autos in der Szene. Die rechenfähige ITS-S muss in der Lage sein, eine solche Szene genau zu erfassen. Zu diesem Zweck sollte die DCROM 205, die die Belegungskarte des Bereichs wiedergibt, so dargestellt werden, dass sie die Szene genau erfasst, indem beispielsweise der Bereich in Gitterplatten unterteilt wird, die durch (X, Y) - Koordinaten spezifiziert und mit einer Kennzeichnung versehen sind, das angibt, ob die Gitterplatte unter anderem „belegt“ oder „frei“ von Objekten, Menschen, Autos ist (z.B. dynamisch oder statisch).
  • 5b veranschaulicht eine beispielhafte 6x6-Gitter-basierte Darstellung einer Ground-Truth- („Bodenwirklichkeits“-) Belegungskarte 500b für die in 5a gezeigte Anwendungsfallumgebung. Hierbei bezieht sich „Ground Truth“ auf Informationen/Daten, die durch direkte Beobachtung (z.B. empirische Evidenz) bereitgestellt werden, im Gegensatz zu Informationen, die durch Inferenz bereitgestellt werden. Die Ground-Truth-DCROM 500b umfasst „freie“ und „belegte“ Gitterzellen (vorliegend manchmal als „Gitterplatten“ bezeichnet) in dem (X, Y) -Ebenen-Raumbereich, die als Gittermatrix im Sichtfeld (FOV) einer rechenfähigen ITS-S, wie etwa einer HC-VRU 116/117 oder einer R-ITS-S 130, dargestellt wird. In 5b ist der Fahrradfahrer als Ego-VRU 116/117 zusammen mit anderen Objekten auf der Straße (z.B. Mast, Gebäude usw.) und anderen VRUs 116/117 (z.B. Personen/Fußgänger) dargestellt, wenn „belegt“ dargestellt wird, während die leeren Raumgitterplatten als „frei“ dargestellt werden.
  • Das Szenario in 5a wird dargestellt durch den Fahrradfahrer der Ego-VRU 116/117 als Referenzpunkt im Gitter, der versuchen kann, die DRCOMP 500b von nahegelegenen rechenfähigen ITS-S(s) zu erhalten, so dass er die Umgebung für eine Kollisionsrisikoanalyse wahrnehmen und sich darauf vorbereiten kann, geeignete Manöveraktionen zur Kollisionsvermeidung zu ergreifen. In einigen Ausführungsformen sollten die rechenfähigen ITS-S(s) in der Lage sein, die wahre DCROM 500b wie in 5b gezeigt zu schätzen. Da die tatsächliche Situation mit den Sensoren jedoch nicht ideal wäre, assoziieren die rechenfähigen ITS-S(s) in verschiedenen Ausführungsformen ein Konfidenzniveau mit jeder Gitterbelegungsschätzungsentscheidung (frei oder belegt), wie in 5c gezeigt ist.
  • 5c zeigt eine geschätzte Belegungskarte 500c an der R-ITS-S 130 der wahren Belegungskarte 500b aus 5b zusammen mit der berechneten Belegungswahrscheinlichkeit, die für jedes Gitterelement (Zelle) gezeigt ist. Um eine solche in 5b gezeigte Ground-Truth-Belegungskarte 500b zu schätzen, ist die DCROM-basierte Schätzung der Belegungskarte 500b zusammen mit der assoziierten Wahrscheinlichkeit einer Belegung für jedes Gitterelement (Zelle) in 5c veranschaulicht. Die Gitterdarstellung ist eine aggregierte Master-Schicht (z.B. die in 2 gezeigte Master-Schicht), die aus einer Fusion der geschichteten Belegungskarte resultiert.
  • Jede Gitterzelle in dem Gitter 500c von 5c beinhaltet eine Wahrscheinlichkeitskennzeichnung PXY, die die Wahrscheinlichkeit einer Belegung der Gitterelementposition in Bezug auf eine X-Position und eine Y-Position relativ zur linken unteren Ecke des Gitters angibt. 4c zeigt ein zweistufiges Gitter, wobei die erste Stufe um die Ego-VRU-116/117-Gitterplatte 8 benachbarte Gitterplatten beinhaltet, während die zweite Stufe 16 benachbarte Gitterplatten beinhaltet. Die Definition einer Stufe wird mit Bezug auf 5d ausführlicher erläutert. Zusätzlich weist jede Gitterplatte (oder jede Gitterzelle) einen eindeutigen Standort hinsichtlich der differentiellen (X, Y)-Koordinaten auf, die ihm implizit zugewiesen sind, und somit wird eine solche Kennzeichnung verwendet, um das Gitterstandortindikator- (GLI-) DF in der VAM zu definieren, wie nachstehend erörtert wird. Die berechneten Wahrscheinlichkeitswerte und ihre Rolle bei der Definition und Zuweisung des Belegungsstatusindikators (OSI) werden ebenfalls nachstehend erläutert.
  • 1.5. VAM-DATENFELDERUND VAM-KONSTRUKTION zum TEILEN VON DCROM IN VBS 1.5.1. BELEGUNGSSTATUSINDIKATOR-DATENFELDKONSTRUKTION UND BITMAP
  • In verschiedenen Ausführungsformen wird die VAM-Formatstruktur so angepasst, dass sie ein Belegungsstatusindikator- (OSI-) DF als einen probabilistischen Indikator der Schätzunsicherheit der benachbarten Gitterkartenelemente um den Ego-VRU 116/117 herum beinhaltet. Der OSI hilft dabei, zu bestimmen, ob die Trajektorie des Ego-VRU 116/117 von statischen Objekten, sich bewegenden Objekten, anderen VRUs 116/117, Nicht-VRUs sowie plötzlich auftretenden Objekten abgefangen werden wird (die z.B. von einem nahegelegenen Auto oder Gebäude herunterfallen oder vom Wind getragen werden usw.). In Abhängigkeit von der Analyse der Szene hinsichtlich der sensorischen sowie der geteilten Eingaben an beispielsweise einer hochrechenfähigen ITS-S wird der OSI als eine Darstellung der Wahrscheinlichkeit definiert, ob eine nahegelegene Gitterplatte möglicherweise belegt ist oder nicht.
  • In einigen Ausführungsformen weist der OSI-Index eine 2-Bit-Konstruktion mit einem Wertebereich und Klassifizierungsebenenindizes auf, wie in Tabelle 1.5.1-1 dargestellt. Die entsprechende Einbindung des OSI als eines der neuen Datenfelder in einen VAM-Container ist in 6a gezeigt. Auch wenn die Erzeugung des DCROM eine rechenfähige ITS-S erfordert, stellt der OSI die Belegungswahrscheinlichkeit des Straßennetzes in der Nähe des VRU 116/117 dar. Der OSI ist nur eine leichtgewichtige 2-Bit-Darstellung, die leicht über eine VAM mit dem Ego-VRU 116/117 sowie seiner benachbarten ITS-S ausgetauscht werden kann. In einigen Ausführungsformen ist der OSI nicht allein als DF in der VAM und ist ein Indikator, der mit dem Standort in dem betreffenden Gitter assoziiert ist, gegeben durch GLI, wie nachstehend erläutert. Tabelle 1.5.1–1: Beispielhafte OSI-Konstruktion
    Belegungsstatusindikator (OSI) OSI-Bit-Bezeichnung für VAM-Container (2 Bits) OSI-Bereich OSI-Ebene Gitterbelegungsentscheidung (konservativ)
    1 00 0 bis 0,25 1: NIEDRIG Frei
    2 01 0,25 bis 0,5 2: MITTEL Belegt
    3 10 0,5 bis 0,75 3: HOCH Belegt
    4 11 0,75 bis 1 4: SEHR HOCH Belegt
  • Tabelle 1.5.1-1 dient dazu, die in 5c gezeigten Wahrscheinlichkeitswerte PXY basierend auf dem definierten beispielhaften OSI-Bereich in eine der OSI-Ebenen abzubilden. Falls beispielsweise die Wahrscheinlichkeit einer Belegung eines Gitters 0,37 ist, dann ist die entsprechende OSI-Ebene „MITTEL“, was mit OSI = 2 erfasst werden kann. Auch wenn der Gitterbelegungsgrad MITTEL ist, kann jedoch ein konservativer Ansatz verwendet werden, um das Gitter als „belegt“ zu erklären, da die Einbuße eines Nichtdetektierens der Belegung des Gitters, wenn dieses in Wahrheit belegt ist, mehr wiegt als das Gitter als leer zu erklären, was zu einer potentiellen Kollision zwischen Verkehrsteilnehmern führen kann. Ein Beispiel für diese konservative Entscheidungsfindung ist durch das vorstehende Beispiel gezeigt, das basierend auf der erhöhten Robustheit der Gitterbelegungsdetektionsmaßnahmen, die verfügbar sein können, aktualisiert werden kann.
  • 1.5.2. GITTERSTANDORTINDIKATOR-DATENFELDKONSTRUKTION UND BITMAP
  • 5d zeigt eine beispielhafte Gitterbelegungskarte 500d der an dem Ego-VRU 116/117 wahrgenommenen Umgebung hinsichtlich OSI-Werten für ein 2-stufiges DCROM-Modell. 5d zeigt eine 2-stufige Darstellung der DCROM hinsichtlich einer Gitterkarte um die Referenzgitterplatte herum, in dem sich der Ego-VRU 116/117 befindet. Dies stellt eine Darstellung der relativen Gitterplattenstandorte um eine Referenz-Ego-VRU-116/117-Gitterplatte in Bezug auf eine logische Darstellung sowie eine Bitmap-Darstellung bereit, die in dem VAM-Container enthalten sein soll. Das Beispiel ist nützlich zum Verständnis der Konstruktion und Darstellung für GLI, die in Tabelle 1.5.2-1 gezeigt sind. Tabelle 1.5.2-1: Beispielhafte GLI-Konstruktion nur unter Berücksichtigung der Belegungskarte der ersten Stufe
    Gitterstandortindikator GLI-Bit-Bezeichnung für VAM-Container (3 Bits) Gitterplattenstandortrichtung relativ zur Ego-VRU-Gitterplatte
    1 000 Nord (N)
    2 001 Süd (S)
    3 010 Ost (O)
    4 011 West (W)
    5 100 Nordwest (NW)
    6 101 Nordost (NO)
    7 110 Südost (SO)
    8 111 Südwest (SW)
  • In dem Beispiel von 5d ist die nächstgelegene 8-Gitterplatten-Schicht um die Ego-VRU-116/117-Gitterplatte 500d herum als Stufe-1-Gitterplatten (oder Stufe-1-Zellen oder - Gitterblöcke) und die nächstäußere Schicht einer 16-Gitterplatten-Schicht als Stufe-2-Gitterplatten (oder Stufe-2-Zellen oder -Gitterblöcke) definiert. Für das Stufe-1-Gitter bezeichnet GLI Indizes, um die 8 möglichen Standorte der Belegungsgitterplatten relativ zu der des Ego-VRU-116/117 widerzuspiegeln, die unter Verwendung einer 3-Bit-Darstellung klassifiziert werden können. Die Konstruktion von GLI zur Einbindung in den VAM-Container ist in Tabelle 1.5.2-1 gezeigt, wobei 3 Bits verwendet werden, um die relativen Standorte der 8 Gitterplatten um die Ego-VRU-116/117-Gitterplatte herum zu kennzeichnen.
  • Für das Stufe-2-Gitter bezeichnet GLI Indizes, um die 16 möglichen Standorte der Belegungsgitterplatten relativ zu der des Ego-VRU 116/117 widerzuspiegeln, die beispielsweise unter Verwendung einer 4-Bit-Darstellung klassifiziert werden können. In einigen Implementierungen kann die 4-Bit-Darstellung die 3-Bit-Darstellungen der Tabelle 2 als zum Beispiel die niedrigstwertigen Bits der 4-Bit-Darstellungen einbinden. Andere Implementierungen sind bei anderen Ausführungsformen möglich.
  • Wie in 5d gezeigt, beinhaltet das Gitter „freie“ Gitterzellen und „belegte“ Gitterzellen. Die „freien“ Gitterzellen beinhalten eine NIEDRIGE Wahrscheinlichkeit einer Belegung, wie etwa OSI = 1. Die „belegten“ Gitterzellen beinhalten MITTLERE, HOHE oder SEHR HOHE Belegungswahrscheinlichkeit, wie etwa OSI = {2, 3, 4}. Die „frei“ - bzw. „belegt“-Entscheidung ergibt sich aus Gründen der Klarheit aus dem in Tabelle 1 gegebenen Beispiel und ist nicht durch die Beispielfälle beschränkt. Auch wenn die Erzeugung der DCROM eine R-ITS-S 130, eine HC-VRU- 116/117 oder eine ähnliche rechenfähige ITS-S erfordert, ist der GLI zudem leichtgewichtig und besteht aus 3 Bits und kann dementsprechend ohne Weiteres über eine VAM mit dem Ego-VRU 116/117 sowie seiner benachbarten ITS-S ausgetauscht werden.
  • 1.5.3. BEISPIELE FÜR OSI- UND GLI-FELDER IM VAM-CONTAINER
  • 6a zeigt ein beispielhaftes VAM-Containerformat 6a00 gemäß verschiedenen Ausführungsformen. Die VAMs enthalten Daten in Abhängigkeit vom VRU-Profil und den tatsächlichen Umgebungsbedingungen. Das VAM-Containerformat aus 6a beinhaltet zusätzliche Datenfelder (DFs), um das Teilen von DRCOMP zwischen VRU-ITS-Ss 117 und/oder benachbarten ITS-Ss, wie etwa der V-ITS-S 110 und/oder der R-ITS-S 130, zu unterstützen. Zu diesen zusätzlichen Datenfeldern zählen ein Gitterstandortindikator-(GLI-) DF und ein Belegungsstatusindikator-(OSI-) DF zusätzlich zu den existierenden VAM-Feldern, wie nachstehend erörtert und/oder wie in [TS103300-2] definiert.
  • Das beispielhafte VAM-Containerformat 6a00 beinhaltet die folgenden DFs/Container: VAM-Header mit VRU-Kennung (ID); VRU-Position (VRU_P); VAM-Erzeugungs- (Erz.-) Zeit; VRU-Profil, wie etwa eines der vorliegend erörterten VRU-Profile. VRU-Typ, der eine Art von Entität oder System ist, die/das mit dem VRU-Profil assoziiert ist (wenn z.B. das VRU-Profil ein Fußgänger ist, ist der VRU-Typ Säugling, Tier, Erwachsener, Kind usw. (zwingend)). VRU-Parameter (Param.), wie etwa zum Beispiel VRU-Clusterparameter, sind optional. Beispielhafte VRU-Clusterparameter/-Datenelemente können beinhalten: VRU-Cluster-ID, VRU-Clusterposition, VRU-Clusterabmessung (z.B. geografische oder Begrenzungsrahmengröße/- form), VRU-Clustergröße (z.B. Anzahl von Elementen im Cluster), VRU-Größenklasse (z.B. zwingend, wenn außerhalb eines VRU-Clusters, und optional, wenn innerhalb eines VRU-Clusters), VRU-Gewichtsklasse (z.B. zwingend erforderlich, wenn außerhalb eines VRU-Clusters, optional, wenn innerhalb eines VRU-Clusters) und/oder andere VRU-bezogene und/oder VRU-Clusterparameter; VRU-Geschwindigkeit (z.B. Geschwindigkeit des VRU in Kilometern pro Stunde (km/h) oder Meilen pro Stunde (m/h); in einigen Ausführungsformen soll die Geschwindigkeit vier Varianten aufweisen: NIEDRIG, MITTEL und HOCH, wie durch die in Tabelle 1.5.3-2 angegebenen Bereiche definiert); VRU-Richtung (z.B. eine Kursrichtung oder ein Kurswinkel des VRU, gemessen relativ zu einer der globalen Referenzkoordinatenebenen, beispielsweise der Y-Ebene); VRU-Orientierung; vorhergesagte Trajektorie (z.B. Folge von Wegpunkten); vorhergesagter Geschwindigkeitsvektor (z.B. einschließlich 3D-Kurs und Durchschnittsgeschwindigkeit); Kursänderungsindikator(en) (HCI) (z.B. Indikatoren für Linksabbiegen und Rechtsabbiegen); Hartbremsungsindikator (HBI); das OSI-DF mit einem oder mehreren OSIs, wie vorliegend erörtert; und das GLI-DF mit einem oder mehreren GLIs wie vorliegend erläutert. Abgesehen von dem OSI- und dem GLI-DF werden diese DFs/DEs ausführlicher vorstehend mit Bezug auf Tabelle 0-2 besprochen.
  • Das VRU-Profil-DF kann eine anfängliche Profil-ID oder aktualisierte Profil-ID [2 Bits] beinhalten: Wenn eine VRU-ITS-S-Vorrichtung bereit ist, zum ersten Mal für einen VRU verwendet zu werden, wird sie zuerst für eine Standardprofilkategorie konfiguriert. Zum Beispiel würde bei einer Person, die eine VRU-ITS-S-Vorrichtung erhält, ihre VRU-ITS-S 117 standardmäßig auf ein Profil 1 konfiguriert, während ein Fahrrad und ein Motorrad selbst mit einer VRU-ITS-S-Vorrichtung ausgestattet und mit Profil 2 bzw. Profil 3 bezeichnet werden können. Falls das Fahrrad oder das Motorrad nicht mit einer ITS-S-Vorrichtung ausgestattet ist, würde die anfängliche ITS-S-Vorrichtung der fahrenden Person als Profil 1 konfiguriert, das einer späteren Aktualisierung unterliegt. Gleichermaßen würde für jedes mit einer ITS-S-Vorrichtung ausgestattete Heim-Haustier das anfängliche Profil standardmäßig auf Profil 4 konfiguriert, das auch hier basierend auf einem späteren Übergang einer Aktualisierung unterliegen kann. Die Bezeichnung einer VRU-Profilkategorieabbildung auf Bits ist in Tabelle 1.5.3-1 dargestellt. Tabelle 1.5.3-1: Anfängliche Profil-ID- oder Profil-ID-Bits-auf-VRU-Profil-Abbildung
    VRU-Profilkategorie Bit-Bezeichnung
    Profil-1 (Fußgänger) 00
    Profil-2 (Fahrradfahrer) 01
    Profil-3 (Motorradfahrer) 10
    Profil-4 (Tier) 11
  • Geschwindigkeitsbereich [2 Bits]: In Abhängigkeit von möglichen Geschwindigkeitswerten wird ein Klassifizieren der VRU-Geschwindigkeit in einen der verschiedenen Geschwindigkeitsbereiche innerhalb eines Profils vorgeschlagen, die definiert sind als: (i) NIEDRIG; (II) MITTEL; und (iii) HOCH. In einigen Ausführungsformen wird die Geschwindigkeit zum Definieren des Subprofils verwendet, da die Geschwindigkeit unter allen ein Schlüsselcharakteristik-Unterscheidungsparameter ist. Die Abbildungseinzelheiten für verschiedene VRU-Profilkategorien sind in Tabelle 1.5.3-2 zusammen mit einem beispielhaften Wertebereich veranschaulicht.
  • Umgebung [2-Bits]: Die Umgebung für die VRUs 116 ist typischerweise nur auf eines von Stadt/Vorort, Land und Autobahn [TS 103300-2] definiert. Eine solche Umgebungsdefinition kann jedoch zu breit sein und möglicherweise keine lokalisierten Umgebungsinformationen für den VRU bereitstellen. Dementsprechend können Subkategorien der Umgebung wie folgt definiert werden: Fußgängerweg (auf oder in der Nähe), Zebrastreifen (auf oder in der Nähe) und Fahrbahn (auf oder in der Nähe). Tabelle 1.5.3-2 zeigt die Bitzuordnungen für verschiedene VRU-Profilkategorien zusammen mit einem beispielhaften Wertebereich.
  • Gewichtsklasse [2 Bits]: Abhängig vom Gewicht des VRU werden 2 Bits verwendet, um 3 Grade anzugeben, die von NIEDRIGEN, MITTLEREN bis HOHEN Gewichten reichen, wie in Tabelle 1.5.3-2 gezeigt. Tabelle 1.5.3-2: VRU-Profil- und -Subprofil-Parameterdefinitionen und Bitabbildunskonstruktion
    VRU-Profilkategorie Subprofil Bits Bezeichnung des Subprofils Beispielhafter Wertebereich
    Profil-1 (Fußgänger) Geschwindigkeitsbereich 00 NIEDRIG Weniger als 3 km/h
    01 MITTEL 3 km/h bis 5 km/h
    10 HOCH 5 km/h bis 10 km/h
    11 N/A (reserviert für Zukunft) -
    Umgebung 00 Auf oder nahe des Fußgängerwegs -
    01 Auf oder nahe Zebrastreifen -
    10 Auf oder nahe der Fahrbahn -
    11 N/A (reserviert für Zukunft) -
    Gewichtskategorie 00 NIEDRIG Weniger als 10 kg
    01 MITTEL 10 kg bis 30 kg
    10 HOCH Über 30 kg
    11 N/A (reserviert für Zukunft) -
    Profil-2 (Fahrradfahrer) Geschwindigkeitsbereich 00 NIEDRIG Weniger als 15 km/h
    01 MITTEL 15 km/h bis 25 km/h
    10 HOCH 25 km/h bis 30 km/h
    11 N/A (reserviert für Zukunft) -
    Umgebung 00 Auf oder nahe des Fußgängerwegs -
    01 Auf oder nahe Zebrastreifen -
    10 Auf oder nahe der Fahrbahn -
    11 N/A (reserviert für Zukunft) -
    Gewichtskategorie 00 Niedrig Weniger als 15 kg
    01 MITTEL 15 kg bis 40 kg
    10 HOCH Über 40 kg
    11 N/A (reserviert für Zukunft) -
    Profil-3 (Motorradfahrer) Geschwindigkeitsbereich 00 NIEDRIG Weniger als 30 km/h
    01 MITTEL 30 km/h bis 45 km/h
    10 HOCH 45 km/h bis 55 km/h
    11 N/A (reserviert für Zukunft) -
    Umgebung 00 Auf oder nahe des Fußgängerwegs -
    01 Auf oder nahe Zebrastreifen -
    10 Auf oder nahe der Fahrbahn -
    11 N/A (reserviert für Zukunft) -
    Gewichtskategorie 00 NIEDRIG Weniger als 25 kg
    01 MITTEL 25 kg bis 140 kg
    10 HOCH 140 kg bis 300 kg
    11 N/A (reserviert für Zukunft) -
    Profil-4 (Tiere) Geschwindigkeitsbereich 00 NIEDRIG Weniger als 5 km/h
    01 MITTEL 5 km/h bis 20 km/h
    10 HOCH 20 km/h bis 40 km/h
    11 N/A (reserviert für Zukunft) -
    Umgebung 00 Auf oder nahe des Fußgängerwegs -
    01 Auf oder nahe Zebrastreifen -
    10 Auf oder nahe der Fahrbahn -
    11 N/A (reserviert für Zukunft) -
    Gewichtskategorie 00 NIEDRIG Weniger als 15 kg
    01 MITTEL 15 kg bis 40 kg
    10 HOCH Über 40 kg
    11 N/A (reserviert für Zukunft) -
  • Um den Nachrichtenaustauschmechanismus für DCROM zu ermöglichen, werden zwei zusätzliche DFs 6a01, das OSI- und das GLI-DF, in dem VAM-Container 6a00 bereitgestellt. Erzeugung und Konstruktion des OSI und des GLI wurden vorstehend besprochen. Diese DFs 6a01 ermöglichen, dass die DCROM von der rechenfähigen ITS-S mit dem Ego-VRU 116/117 und anderen benachbarten Verkehrsteilnehmern geteilt wird.
  • In verschiedenen Ausführungsformen kann der VAM-Container 6a00 mehrere OSI- und GLI-DFs oder OSI-GLI-Paare beinhalten. Für jedes OSI-GLI-Paar gibt der GLI eine Gitterzelle in der DCROM an und gibt der OSI eine Wahrscheinlichkeit einer Belegung der Gitterelementposition hinsichtlich Z-Position und Y-Position relativ zur linken unteren Ecke des Gitters an. Auf diese Weise kann die LC-VRU 116/117 ihre eigene DCROM konstruieren oder anderweitig die Belegungswahrscheinlichkeiten für Kollisionsvermeidungszwecke nutzen.
  • In einigen Ausführungsformen können VAMs mit den OSI- und GLI-Feldern periodisch ausgetauscht werden, um ein Bewusstsein für die VRU-116/117-Umgebung und den -Kontext an die benachbarten ITS-Ss rundzusenden. Zum Beispiel kann die VAM-Übertragungsfrequenz 1 T V A M ≥ 1 Hz
    Figure DE112020006966T5_0001
    betragen, wobei TVAM die Periodizität in Sekunden (oder einer anderen Zeiteinheit) ist. Die Periodizität kann in Abhängigkeit von a-priori-Bedingungen konfigurierbar sein.
  • In anderen Ausführungsformen kann die VAM mit den OSI- und GLI-Feldern ereignisgesteuert ausgetauscht werden. Zum Beispiel kann eine VAM-Übertragung aufgrund des Auftretens (oder Detektierens) einer potentiellen Notfallsituation ausgelöst werden.
  • 1.5.4. AUSFÜHRUNGSFORMEN DES VAM-FORMATS
  • 6b zeigt beispielhafte eine VRU-Bewusstmachungsnachricht (VAM) 6b00 gemäß verschiedenen Ausführungsformen. Die VAM-Parameter beinhalten mehrere Datencontainer, Datenfelder (DFs) und/oder Datenelemente (DEs). Aktuelle ETSI-Standards (z.B. [TR103300-1], [TS103300-2], [TS103300-3]) können verschiedene Container als eine Folge optionaler oder obligatorischer Datenelemente (DEs) und/oder Datenrahmen (DFs, data frames) umfassend definieren. Es versteht sich jedoch, dass die Anforderungen eines beliebigen bestimmten Standards die hier besprochenen Ausführungsformen nicht beschränken sollten und daher eine beliebige Kombination von Containern, DFs, DEs, Werten, Aktionen und/oder Merkmalen in verschiedenen Ausführungsformen möglich ist, einschließlich einer beliebigen Kombination von Containern, DFs, DEs, Werten, Aktionen und/oder Merkmalen, die streng befolgt werden müssen, um derartigen Standards zu entsprechen, oder einer beliebigen Kombination von Containern, DFs, DEs, Werten, Aktionen und/oder Merkmalen, die stark empfohlen werden und/oder mit oder in Anwesenheit/Abwesenheit optionaler Elemente verwendet werden. Die im CPM-Format enthaltenen DEs und DFs basieren auf dem ETSI Common Data Dictionary (CDD), ETSI TS 102 894-2 („[TS102894-2]“) und/oder verwenden bestimmte Elemente, die in CEN ISO/TS 19091 definiert sind.
  • 6b zeigt eine beispielhafte VAM 6b00 mit Datencontainern, DEs und/oder DFs gemäß verschiedenen Ausführungsformen. Die VAM 6b00 beinhaltet einen gemeinsamen ITS-PDU-Header, einen Erzeugungszeit-Container/DF, einen Basis-Container, einen VRU-Hochfrequenz-Container mit dynamischen Eigenschaften des VRU 116/117 (z.B. Bewegung, Beschleunigung usw.), einen VRU-Niederfrequenz-Container mit physischen Eigenschaften des VRU 116/117 (z.B. bedingt zwingend bei höherer Periodizität, vgl. Klausel 7.3.2 von [TS103300-3]), einen Clusterinformations-Container, einen Clusterbetrieb-Container und einen Bewegungsvorhersage-Container.
  • Der ITS-PDU-Header ist ein Header-DF der VAM 6b00. Der ITS-PDU-Header beinhaltet DEs für die VNM-ProtokollVersion, die VAM-Nachrichtentypkennung NachrichtenID und die Stationskennung StationID der Ursprungs-ITS-S. Das DE ProtokollVersion wird verwendet, um den geeigneten Protokolldecodierer an der empfangenden ITS-S auszuwählen. Dieses DE - NachrichtenID sollte mit anderen C-ITS-Nachrichtenkennungsdefinitionen harmonisiert sein. In einigen Implementierungen wird der Wert des DE-ProtokollVersion auf 1 gesetzt. Für den VAM wird das DE Nachrichten-ID auf vam(14) gesetzt. Die StationID ist lokal eindeutig. Dieses DF wird wie in Klausel E.3 von [TS103300-3] spezifiziert dargestellt.
  • Der ITS-PDU-Header ist wie in [TS102894-2] spezifiziert. Ausführliche Datendarstellungsregeln des ITS-PDU-Headers im Kontext von VAM sind wie im Anhang B von [TS103300-3] spezifiziert. Das StationId-Feld im ITS-PDU-Header ändert sich, wenn sich das signierende Pseudonymzertifikat ändert oder wenn der VRU beginnt, einzelne VAMs zu übertragen, nachdem er ein Element eines Clusters war (z.B. entweder wenn er als führender VRU den Cluster aufbricht oder wenn er als ein beliebiges Clusterelement den Cluster verlässt). Ausnahme: Wenn an der VRU-Vorrichtung ein „fehlgeschlagener Beitritt“ zu einem Cluster auftritt, wie in Klausel 5.4.2.2 von [TS 103300-3] definiert, sollte diese weiterhin die StationId und andere Kennungen verwenden, die sie vor dem fehlgeschlagenen Beitritt verwendet hat. Die Erzeugungszeit in der VAM ist eine ErzeugungsDeltaZeit, wie sie in der CAM verwendet wird. Dabei handelt es sich um ein Maß der Anzahl von Millisekunden, die seit der ITS-Epoche verstrichen ist, Modulo 216 (zum Beispiel 65536).
  • Die VAM-Nutzlast vam beinhaltet eine Angabe des Zeitstempels der VAM und der Container BasisContainer und vruHochFrequenz-Container. Die VAM-Nutzdaten können die zusätzlichen Container vruNiederFrequenzContainer, vruClusterlnformationsContainer, vruClusterBetriebContainerund vruBewegungs Vorhersage Container beinhalten. Die Auswahl der zusätzlichen Container hängt von den Verbreitungskriterien ab, z.B. einer Verfügbarkeit von vruCluster oder BewegungsDynamikVorhersage. Dieses DF wird wie in Anhang A von [TS103300-3] spezifiziert dargestellt.
  • Das ErzeugungsDeltaZeit-DF ist oder beinhaltet eine Zeit, die der Zeit der Referenzposition in der VAM entspricht, die als Zeit der VAM-Erzeugung betrachtet wird. Der Wert des DE wird durch Wrapping auf 65 536 gesetzt. Dieser Wert wird als der Rest des entsprechenden Werts von Zeitstempellts geteilt durch 65 536 wie nachstehend gesetzt. ErzeugungsDeltaZeit = Zeitstempellts mod 65 536. Zeitstempellts stellt einen ganzzahligen Wert in Millisekunden seit 2004-01-01T00:00:00:000Z dar, wie in X definiert. Das DE wird wie in Anhang A von [TS103300-3] spezifiziert dargestellt.
  • Das vamParameter-DF gibt die Folge von obligatorischen und optionalen VAM-Containern an. Andere Container können künftig hinzugefügt werden. Dieses DF wird wie in Anhang A von [TS103300-3] spezifiziert dargestellt.
  • Der BasisContainer ist der (obligatorische) Basis-Container einer VAM. Der Basis-Container stellt (beinhaltet Angaben über) Basisinformationen der Ursprungs-ITS-S bereit. Typ der Ursprungs-ITS-S; dieses DE überlappt das VRU-Profil irgendwie, auch wenn sie nicht vollständig übereinstimmen (z.B. entsprechen sowohl das Moped(3) als auch das Motorrad(4) einem VRU-Profil 3). Um eine zukünftige Möglichkeit zu schaffen, die VAM durch die Nicht-VRU-ITS-S zu übertragen (siehe Klausel 4.1 und Anhang I), werden beide Datenelemente unabhängig gehalten. Die aktuellste geografische Position der Ursprungs-ITS-S, wie durch den VBS bei der VAM-Erzeugung erhalten. Dieses DF ist in [TS102894-2] definiert und beinhaltet eine PositionsKonfidenzEllipse, die die Genauigkeit der gemessenen Position mit dem Konfidenzniveau von 95 % bereitstellt. Der Basis-Container ist für eine VAM vorhanden, die durch alle ITS-SS erzeugt wird, die denVBS implementieren. Wenngleich der Basis-Container die gleiche Struktur wie der Basis-Container in anderen ETSI-ITS-Nachrichten aufweist, enthält das Typ-DE VRU-spezifische Typwerte, die nicht vom Basis-Container für Fahrzeugnachrichten verwendet werden. Es ist vorgesehen, dass zu einem künftigen Zeitpunkt das Typenfeld im ITS Common Data Dictionary (CDD) in [TS102894-2] so erweitert wird, dass es die VRU-Typen beinhaltet. Zu diesem Zeitpunkt werden der VRU-BasisContainer und der Fahrzeug-BasisContainer identisch sein.
  • Das StationsTyp-DF beinhaltet Angaben zum Stationstyp der VAM-Ursprungsvorrichtung. Dieses DE nimmt den Wert Fußgänger(1), Fahrradfahrer(2), Moped(3), Motorrad(4), leichtesVRUFahrzeug(12) oder Tier(13) an. Andere Werte von StationsTyp werden in dem in der VAM übertragenen BasisContainer nicht verwendet. Dieses DF wird wie in Klausel E.2 von [TS103300-3] spezifiziert dargestellt.
  • Die Referenzposition DF beinhaltet Angaben über die Position und Positionsgenauigkeit, die am Referenzpunkt der Ursprungs-ITS-S gemessen wird. Die Messzeit entspricht ErzeugungsDeltaZeit. Falls der Stationstyp der Ursprungs-ITS-S auf einen der in Klausel B.2.2 von [TS103300-3] aufgelisteten Werte gesetzt ist, ist der Referenzpunkt die Bodenposition des Mittelpunkts der Vorderseite des Begrenzungsrahmens des VRU (vgl. z.B. ETSI EN 302 890-2 („[EN302890-2]“). Die PositionsKonfidenzEllipse stellt die Genauigkeit der gemessenen Position mit dem Konfidenzniveau von 95 % bereit. Andernfalls wird die PositionsKonfidenzEllipse auf nicht verfügbar gesetzt. Falls große Halbachsen Orientierung auf 0° Nord gesetzt ist, entspricht die großeHalbachsenKonfidenz der Positionsgenauigkeit in Nord/Süd-Richtung, während die kleineHalbachsen Konfidenz der Positionsgenauigkeit in Ost/West-Richtung entspricht. Diese Definition impliziert, dass die großeHalbachsenKonfidenz kleiner als die kleineHalbachsenkonfidenz sein könnte. Dieses DF wird wie in [TS102894-2] A. 124 ReferenzPosition spezifiziert dargestellt.
  • VAM-spezifische Container beinhalten einen VRU-Hochfrequenz- (VRU-HF-) Container und einen VRU-Niederfrequenz- (VRU-LF-) Container. Alle VAMs, die durch eine VRU-ITS-S erzeugt werden, beinhalten zumindest einen VRU-HF-Container. Der VRU-HF-Container enthält sich potentiell schnell ändernde Statusinformationen der VRU-ITS-S wie etwa Kurs oder Geschwindigkeit. Da die VAM nicht durch VRUs aus Profil 3 (Motorradfahrer) verwendet wird, ist keiner dieser Container für das Profil 3 des VRU anwendbar. Stattdessen übertragen Profil-3-VRUs nur den speziellen Motorrad-Container mit der CAM (vgl. Abschnitte 4.1, 4.4 und 7.4 in [TS103300-3]). Zusätzlich können VAMs, die durch eine VRU-ITS-S erzeugt werden, einen oder mehrere der Container beinhalten, wie in Tabelle 1.5.4-1 spezifiziert, falls relevante Bedingungen erfüllt sind. Tabelle 1.5.4-1: Bedingt obligatorische und optionale VAM-Container
    Container-Name Beschreibung Bedingung für Vorhandensein in der VAM
    VRU-Niederfrequenz-(VRU-LF-) Container Der VRU-LF-Container enthält statische oder sich langsam ändernde Fahrzeugdaten wie etwa das Profil oder den Status der Außenlichter. Obligatorisch bei höherer Periodizität (vgl. Klausel 6.2 von [TS103300-3]) oder wenn ein VRU-Clusterbetrieb-Container vorhanden ist
    VRU-Clusterinformations-Container Dieser Container stellt die für einen VRU-Cluster relevanten Informationen/Parameter bereit. Bedingt obligatorisch (vgl. Klausel 5.4.1 von [TS103300-31)
    VRU-Clusterbetrieb-Container Dieser Container stellt Informationen bereit, die für Änderungen des Clusterzustands im VBS relevant sind. Er kann von einem Cluster-VAM-Sender oder von einem Clusterelement (einem führenden bzw. gewöhnlichen Element) eingebunden sein. Bedingt obligatorisch (vgl. Klausel 5.4.1 von [TS103300-3])
    VRU-Bewegungsvorhersage-Container Wenn die Informationen in der VRU-ITS-S verfügbar sind, stellt dieser Container dynamische VRU-Bewegungsvorhersageinformationen sowie explizite Wegvorhersage bereit. Optional
  • Der VRU-HF-Container einer VAM (vruHochFrequenzContainer) wird wie in Anhang A von [TS103300-3] spezifiziert dargestellt. Der VRU-HF-Container der VAM enthält sich potenziell schnell ändernde Statusinformationen der VRU-ITS-S. Er beinhaltet die in Klausel B.3.1 von [TS103300-3] aufgeführten Parameter. Der VRU-HF-Container beinhaltet die folgenden Parameter: Kurs; Geschwindigkeit; LängsBeschleunigung; Krümmung OPTIONAL (empfohlen für VRU-Profil 2); KrümmungsBerechnungModus OPTIONAL (empfohlen für VRU-Profil 2); GierRate OPTIONAL (empfohlen für VRU-Profil 2); Querbeschleunigung OPTIONAL (empfohlen für VRU-Profil 2); VertikalBeschleunigung OPTIONAL; vruFahrspurPosition OPTIONAL (erweitert, um Fußgängerwege und Fahrradwege einzuschließen); Umgebung OPTIONAL; vruBewegungsSteuerung OPTIONAL (empfohlen für VRU-Profil 2); Orientierung OPTIONAL (empfohlen für VRU-Profil 2); Rollwinkel OPTIONAL (empfohlen für VRU-Profil 2); und/oder vruVorrichtungsNutzung OPTIONAL (empfohlen für VRU-Profil 1). Ein Teil der Informationen in diesem Container ist für einige VRU-Profile nicht sinnvoll, und sie werden daher als optional angegeben, aber zu spezifischen VRU-Profilen empfohlen.
  • Das VRU-Profil kann in dem VRU-LF-Container enthalten sein und wird somit nicht so oft wie der VRU-HF-Container übertragen (vgl. Klausel 6.2 von [TS103300-3]). Der Empfänger kann jedoch das VRU-Profil aus dem vruStationsTyp-Feld ableiten: Der Fußgänger gibt das Profil 1 an, der Fahrradfahrer oder das LeichtVRUFahrzeug gibt das Profil 2 an, das Moped oder das Motorrad gibt das Profil 3 an, und Tiere geben das Profil 4 an.
  • Das VRU-HF-DF kann verwendet werden, um zu beschreiben, dass die Fahrspurposition in der CAM unter Berücksichtigung der VRUs 116/117 nicht ausreicht, da es keine Fahrradwege und Fußgängerwege beinhaltet. Dementsprechend wurde sie erweitert, um alle Positionen abzudecken, an denen sich ein VRU befinden könnte. Wenn vorhanden, beschreibt das vruFahrspurPosition-DF entweder eine Fahrspur auf der Straße (wie für ein Fahrzeug), eine Fahrspur außerhalb der Straße oder eine Insel zwischen zwei Fahrspuren der vorherigen Typen. Weitere Einzelheiten sind in der DF-Definition in Klausel B. 3.10 von [TS 103300-3] bereitgestellt.
  • Das VruOrientierung-DF ergänzt die Abmessungen des VRU-Fahrzeugs durch Definieren des Winkels zwischen der VRU-Fahrzeug-Längsachse in Bezug auf WGS84 Nord. Es ist auf VRUs von Profil 2 (Fahrradfahrer) und Profil 3 (Kraftfahrer) beschränkt. Wenn vorhanden, ist sie wie in Klausel B.3.17 definiert. Der VruOrientierungsWinkel unterscheidet sich vom Fahrzeugkurs, der sich auf die VRU-Bewegung bezieht, während sich die Orientierung auf die VRU-Position bezieht.
  • Das Rollwinkel-DT stellt eine Angabe eines um eine Kurve fahrenden Zweirads bereit. Er ist als der Winkel zwischen der Bodenebene und der aktuellen Orientierung der y-Achse eines Fahrzeugs mit Bezug auf die Bodenebene um die x-Achse definiert, wie in ISO 8855 spezifiziert ist. Das DF beinhaltet zudem die Winkelgenauigkeit. Beide Werte sind auf die gleiche Weise codiert wie DF Kurs, vgl. A. 101 in [TS102894-2], mit den folgenden Konventionen: positive Werte bedeuten ein Rollen zur rechten Seite (0...„500"), wobei 500 einem Rollwinkelwert nach rechts von 50 Grad entspricht; negative Werte bedeuten ein Rollen auf die linke Seite (3 600... „3 100“), wobei 3 100 einem Rollwinkelwert nach links von 50 Grad entspricht; Werte zwischen 500 und 3 100 werden nicht verwendet; Das DE vruVorrichtungsBenutzer stellt dem VAM-Empfänger Angaben über eine parallele Aktivität des VRU bereit. Dieses DE ähnelt dem in SAE J2945/9 spezifizierten DE PersonenVorrichtungsNutzungsStatus. Es ist auf VRUs des Profils 1 wie beispielsweise Fußgänger beschränkt. Wenn vorhanden, ist sie wie in Klausel B.2.19 von [TS103300-3] definiert und stellt die in Tabelle 1.5.4-2 angegebenen möglichen Werte bereit. Um die Wahl des Benutzers hinsichtlich Privatsphäre zu respektieren, sollte die Vorrichtungskonfigurationsanwendung ein Zustimmungsformular zum Übertragen dieser Informationen beinhalten. Wie dieses Zustimmungsformular implementiert wird, liegt außerhalb des Schutzumfangs des vorliegenden Dokuments. Falls die Option abgelehnt wird (Standard), sendet die Vorrichtung systematisch den Wert „nicht verfügbar (0)“. Tabelle 1.5.4-2: mögliche Werte vruVorrichtungsNutzung
    Aktivitätsdefinition Wert Beschreibung
    Nicht verfügbar 0 Nicht bestimmt oder VRU hat der Übertragung dieser persönlichen Daten in diesem DE nicht zugestimmt
    Andere 1 Für andere Zustände als nachstehend definiert verwendet
    Ruhe 2 Der Mensch interagiert nicht mit der Vorrichtung
    AnhörenvonAudio 3 Jegliche Audioquelle außer Anruf
    Tippen 4 Beinhaltet Schreiben von Text, Eingeben von Adressen und andere manuelle Eingabeaktivität
    Aufrufen 5
    SpieleSpielen 6
    Lesen 7
    Ansehen 8 Ansehen von dynamischem Inhalt, einschließlich dem Folgen von Navigationsaufforderungen, Ansehen von Videos oder anderen visuellen Inhalten, die nicht statisch sind
  • Das DE VruBewegungsSteuerung gibt den Mechanismus an, der vom VRU zum Steuern der Längsbewegung des VRU-Fahrzeugs verwendet wird. Es zielt hauptsächlich auf VRUs aus dem Profil 2 wie z.B. Fahrradfahrer ab. Wenn vorhanden, wird es wie in Klausel B.3.16 von [TS103300-3] definiert dargestellt und stellt die in Tabelle 1.5.4-3 angegebenen möglichen Werte bereit. Die Verwendung der unterschiedlichen in der Tabelle bereitgestellten Werte kann von dem Land abhängen, in dem sie gelten. Beispielsweise könnte in Abhängigkeit von dem Fahrrad in einigen Ländern eine Pedalbewegung zum Bremsen notwendig sein. Diese DE könnte auch als Information für die bordeigenen Systeme der umliegenden Fahrzeuge dienen, um den Fahrradfahrer (unter anderem) zu identifizieren und somit den „Abgleichprozess“ der bereits von dem VRU-Fahrzeug empfangenen Nachrichten (bevor es in das Sichtfeld des Autos eingetreten ist) und des Objekts, das durch die Kamera des anderen Fahrzeugs detektiert wird (sobald das VRU-Fahrzeug in das Sichtfeld eintritt) zu verbessern/beschleunigen. Tabelle 1.5.4-3: Mögliche Werte VruBewegungsSteuerung
    Angewendete Bewegungssteuerung Wert Beschreibung
    Nicht verfügbar 0 Nicht bestimmt oder VRU hat der Übertragung dieser persönlichen Daten in diesem DE nicht zugestimmt
    Bremsen 1 An VRU-Fahrzeugbremsen angewendete Aktion
    HartesBremsen 2 An VRU-Fahrzeugbremsen angewendete Aktion
    StoppenPedalbetätigung 3 An VRU-Fahrzeugpedalen angewendete Aktion
    BremsenUndStoppenPedalbetä tigung 4 Aktion, die sowohl an VRU-Fahrzeugpedalen als auch an Bremsen angewendet wird
    HartesBremsenUndStoppenPe dalbetätigung 5 Aktion, die sowohl an VRU-Fahrzeugpedalen als auch an Bremsen angewendet wird
    keineReaktion 6 Es wird keine Aktion auf das VRU-Fahrzeug angewendet
  • Das Kurs-DF beinhaltet oder gibt einen Kurs und eine Kursgenauigkeit der Ursprungs-ITS-S in Bezug auf geografisch Nord an. Die in dem DE-KursKonfidenz-Wert bereitgestellte Kursgenauigkeit stellt die Genauigkeit des gemessenen Fahrzeugkurses mit einem Konfidenzniveau von 95 % bereit. Andernfalls wird der Wert der Kurskonfidenz auf nicht verfügbar gesetzt. Das DE wird wie in [TS102894-2] A. 112 Kurs spezifiziert dargestellt.
  • Das Geschwindigkeit-DF beinhaltet oder gibt eine Geschwindigkeit in der Bewegungsrichtung und eine Geschwindigkeitsgenauigkeit der Ursprungs-ITS-S an. Die im DE GeschwindigkeitsKonfidenz bereitgestellte Geschwindigkeitsgenauigkeit stellt die Genauigkeit des Geschwindigkeitswerts mit einem Konfidenzniveau von 95 % bereit. Andernfalls wird die GeschwindigkeitsKonfidenz auf nicht verfügbar gesetzt. Das DE wird wie in [TS 102894-2] A. 126 Geschwindigkeit spezifiziert dargestellt.
  • Das DF Längsbeschleunigung beinhaltet eine Längsbeschleunigung der Ursprungs-ITS-S oder gibt diese an. Es beinhaltet die gemessene Längsbeschleunigung und ihren Genauigkeitswert mit dem Konfidenzniveau von 95 %. Andernfalls wird die Längsbeschleunigungskonfidenz auf nicht verfügbar gesetzt. Das Datenelement wird wie in [TS102894-2], A.116 Längsbeschleunigung spezifiziert dargestellt.
  • Das DF Krümmung bezieht sich auf die tatsächliche Trajektorie des VRU-Fahrzeugs. Es beinhaltet Folgendes: KrümmungsRadius, als Inverse des aktuellen VRU-Kurvenradius und der Wenderichtung der Kurve bezüglich der Bewegungsrichtung des VRU bezeichnet, wie in [TS102894-2] definiert. Krümmungskonfidenz wird als die Genauigkeit des bereitgestellten KrümmungsWerts für ein Konfidenzniveau von 95 % bezeichnet. Optional. Empfohlen für VRU-Profil 2. Das DF wird wie in [TS102894-2], A. 107 Krümmung spezifiziert dargestellt.
  • Der KrümmungsBerechnungsModus ist ein Flag-DE, das angibt, ob die Gierrate des Fahrzeugs bei der Berechnung der Krümmung der VRU-Fahrzeug-ITS-S, die aus der VAM stammt, verwendet wird. Optional. Empfohlen für VRU-Profil 2. Das DE wird wie durch [TS 102894-2], A. 13 KrümmungsBerechnungsModus spezifiziert dargestellt.
  • Das DF Gierrate ähnelt dem, das in der CAM verwendet wird, und beinhaltet: Gierratenwert, bezeichnet die VRU-Drehung um den Schwerpunkt des leeren Fahrzeugs oder des Lebewesen-VRU. Das Vorzeichen bezeichnet die Drehrichtung. Der Wert ist negativ, wenn die Bewegung von oben betrachtet (in Straßenkoordinaten) im Uhrzeigersinn verläuft. GierRatenKonfidenz bezeichnet die Genauigkeit für das 95 %-Konfidenzniveau für den gemessenen GierRatenWert. Andernfalls wird der Wert von GierRatenKonfidenz auf nicht verfügbar gesetzt. Optional. Empfohlen für VRU-Profil 2. Das DF wird wie in [TS102894-2], A. 132 GierRate spezifiziert dargestellt.
  • Das DF QuerBeschleunigung beinhaltet oder gibt eine seitliche VRU-FahrzeugBeschleunigung in der Straßenebene senkrecht zur Kursrichtung der Ursprungs-ITS-S im Schwerpunkt des leeren VRU-Fahrzeugs (für Profil 2) oder des menschlichen oder tierischen VRU an (für Profil 1 oder 4). Es beinhaltet die gemessene VRU-Querbeschleunigung und ihren Genauigkeitswert mit dem Konfidenzniveau von 95 %. Dieses DE ist vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Optional, aber empfohlen für VRU-Profil 2. Das DF ist wie in [TS102894-2], A. 115 DF_Querbeschleunigung spezifiziert dargestellt.
  • Das DF VertikalBeschleunigung beinhaltet oder gibt eine Vertikalbeschleunigung der Ursprungs-ITS-S an. Dieses DE ist vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Das DF wird wie in [TS102894-2], A. 129 VertikalBeschleunigung spezifiziert dargestellt.
  • Das DF vruFahrspurPosition beinhaltet oder gibt eine Fahrspurposition der Referenzposition eines VRU an, die entweder eine VRU-spezifische Nicht-Verkehrsspur oder eine Standard-Verkehrsspur ist. Dieses DF ist vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind (zusätzliche Informationen sind erforderlich, um die Fahrspurposition eindeutig zu identifizieren und die Korrelation zu einer Karte zu ermöglichen. Dies ist mit einer angemessenen Geolokalisierungspräzision verknüpft). Dieses DF beinhaltet eines oder mehrere der folgenden Felder: StraßenFahrspurPosition, GeländeFahrspurposition; VerkehrsInselPosition, und/oder KartenPosition. Das DF wird wie in Anhang A und Klausel F.3.1 von [TS103300-3] spezifiziert dargestellt.
  • Das DE GeländeFahrspur Position beinhaltet oder gibt eine Fahrspurposition des VRU an, wenn sich dieser auf einer VRU-spezifischen Nicht-Verkehrsspur befindet. Das DE wird wie in Klausel F.3.2 von [TS103300-3] spezifiziert dargestellt.
  • Die StraßenFahrspurPosition DE beinhaltet oder gibt eine Straßenfahrspurposition der ReferenzPosition eines VRU, die von der Außengrenze der Straße her gezählt wird, in Richtung des Verkehrsflusses an. Dieses DE ist vorhanden, falls die Daten an der Ursprungs-ITS-S verfügbar sind (vgl. Anmerkung: Zusätzliche Informationen werden benötigt, um die Fahrspurposition eindeutig zu identifizieren und die Korrelation zu einer Karte zu ermöglichen. Dies ist mit einer angemessenen Geolokalisierungspräzision verknüpft). Das DE wird wie in [TS102894-2], A.40 FahrspurPosition spezifiziert dargestellt.
  • Das DE VerkehrsInselPosition beinhaltet oder gibt eine Fahrspurposition des VRU an, wenn sich dieser auf einer VRU-spezifischen Verkehrsinsel befindet. Der VerkehrsInselPosition-Typ besteht aus zwei Fahrspurkennungen für die zwei Fahrspuren auf beiden Seiten der Verkehrsinsel. Jede Kennung kann eine GeländeFahrspurPosition, eine StraßenFahrspurPosition oder eine KartenPosition sein. Die Erweiterbarkeitsmarkierung ermöglicht künftige Erweiterungen dieses Typs für Verkehrsinseln mit mehr als zwei Seiten. Das DF wird wie in Klausel F.3.3 von [TS103300-3] spezifiziert dargestellt.
  • Das DE KartenPosition beinhaltet oder gibt eine Fahrspurposition des VRU wie durch eine MAPEM-Nachricht angegeben an, wie in ETSI TS 103 301 vl.1.1 (2016-11) spezifiziert. Das DF wird wie in Klausel F.3.5 von [TS103300-3] spezifiziert dargestellt.
  • Das DE Umgebung stellt kontextbezogenes Bewusstsein über den VRU unter anderen Verkehrsteilnehmern bereit. Dieses DE ist nur dann vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Das DE wird wie in Klausel F.3.6 von [TS103300-3] spezifiziert dargestellt.
  • Das DE vruBewegungsSteuerung gibt den Mechanismus an, der vom VRU zum Steuern der Längsbewegung des VRU-Fahrzeugs verwendet wird (vgl. z.B. BeschleunigungsSteuerung in [TS102894-2], A.2). Die Auswirkung dieses Mechanismus kann durch andere DEs im vruBewegungsVorhersageContainer (z.B. KursÄnderungsAnzeige, BeschleunigungsÄnderungsAnzeige) angegeben werden. Dieses DE ist nur dann vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Das DE wird wie in Klausel F.3.7 von [TS103300-3] spezifiziert dargestellt.
  • Das DF vruOrientierung ergänzt die Abmessungen des VRU-Fahrzeugs durch Definieren des Winkels der VRU-Fahrzeug-Längsachse in Bezug auf WGS84 Nord. Die Orientierung des VRU ist ein wichtiger Faktor, insbesondere, wenn der VRU nach einem Unfall zu Boden gefallen ist und für andere Verkehrsteilnehmer ein sich nicht bewegendes Hindernis darstellt. Dieses DE ist nur dann vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Optional. Empfohlen für VRU-Profil 2 und VRU-Profil 3. Das DE wird wie in Klausel F.3.8 von [TS103300-3] spezifiziert dargestellt.
  • Das RollWinkel-DF RollWinkel stellt den Winkel und die Winkelgenauigkeit zwischen der Bodenebene und der aktuellen Orientierung der y-Achse eines Fahrzeugs in Bezug auf die Bodenebene um die x-Achse gemäß ISO 8855 bereit. Das DF beinhaltet die folgenden Informationen: RollWinkelWert; RollWinkelKonfidenz. Dieses DF ist nur dann vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Optional. Empfohlen für VRU-Profil 2 und VRU-Profil 3. Das DF wird wie in [TS102894-2] für das Kurs-DF spezifiziert dargestellt, das ebenfalls als ein Winkel mit seiner Konfidenz ausgedrückt wird (vgl. A. 101 DF Kurs). Der RollWinkelWert wird wie in Klausel 7.3.3 von [TS103300-3] spezifiziert gesetzt.
  • Das DE vruVorrichtungsBenutzer stellt Angaben von der persönlichen Vorrichtung über die potentielle Aktivität des VRU bereit. Dieses ist mit dem SAE-PSM harmonisiert. Dieses DE ist nur dann vorhanden, wenn die Daten an der Ursprungs-ITS-S verfügbar sind. Optional, aber für VRU-Profil 1 empfohlen. Das DE wird wie in Klausel F.3.9 von [TS103300-3] spezifiziert dargestellt.
  • Der VRU-Niederfrequenz- (LF-) Container (vruNiederFrequenzContainer) einer VAM kann bei höherer Periodizität obligatorisch sein. Dieses DF wird wie in Anhang A von [TS103300-3] spezifiziert dargestellt. Der VRU-LF-Container beinhaltet die folgenden Parameter: VruProfilUndSubProfil, vruGräßenKlasse; vruAußenLichter (optional oder obligatorisch für VRU-Profil 2 und VRU-Profil 3).
  • Der VRU-LF-Container der VAM enthält potentielle sich langsam ändernde Informationen der VRU-ITS-S. Sie beinhaltet die in Klausel B.4.1 von [TS103300-3] aufgeführten Parameter. Einige Elemente sind obligatorisch, andere sind optional oder bedingt obligatorisch. Der VRU-LF-Container ist mit einer parametrisierbaren Frequenz in der VAM enthalten, wie in Klausel 6.2 von [TS 103300-3] spezifiziert. Der VAM-VRU-LF-Container weist den folgenden Inhalt auf. Das DE VruProfilUndSubProfil enthält die Identifikation des Profils und des Subprofils der Ursprungs-VRU-ITS-S, falls definiert. Tabelle 1.5.4-4 zeigt die im vorliegenden Dokument spezifizierte Liste von Profilen und Subprofilen. Tabelle 1.5.4-4: VruProfilUndSubProfil-Beschreibuns basierend auf Profilen
    Profil Profilindex Subprofilindex VruSubProfil-Beschreibung
    Fußgänger 1 0 Nicht Verfügbar
    1 Gewöhnlicher Fußgänger
    2 Straßenarbeiter
    3 Ersthelfer
    Fahrradfahrer 2 0 Nicht Verfügbar
    1 Fahrradfahrer
    2 Rollstuhlfahrer
    3 Pferd mit Reiter
    4 Rollschuhfahrer
    5 Stehender E-Roller
    6 Einpersonen-Transporter
    7 E-Fahrrad- (Pedelec-) Fahrer, bis zu 25 km/h in Europa
    8 E-Fahrrad- (Speed-Pedelec-) Fahrer, bis zu 45 km/h, jedoch mit einer Bewegungsdynamik ähnlich einem Fahrrad
    Motorradfahrer 3 0 Nicht Verfügbar
    1 Moped
    2 Motorrad
    3 Motorrad + Beiwagen rechts
    4 Motorrad + Beiwagen links
    5 E-Roller mit Sitz
    Tiere (vgl. Anmerkung) 4 0 Nicht Verfügbar
    1 Wildtier
    2 Nutztier
    3 Assistenztier
    ANMERKUNG: Im Zusammenhang mit sicherheitsbezogener Verkehrskommunikation wird Tieren eine höhere Priorität als unbelebten Objekten zugeordnet. Somit wurde ein spezifisches Profil definiert, um sie bei jeder Art von Entscheidungfindungsprozess korrekt zu behandeln.
  • Das DE VruProfilUndSubProfil ist OPTIONAL, falls der VRU-LF-Container vorhanden ist. Fehlt dieser, bedeutet dies, dass das Profil nicht verfügbar ist. Die Subprofile für das VRU-Profil 3 werden nur im CAM-Spezialcontainer verwendet. Das DE VRUSGrößenKlasse enthält Informationen über die Größe des VRU. Das DE VruGrößenKlasse hängt vom VRU-Profil ab. Diese Abhängigkeit ist in Tabelle 1.5.4-5 dargestellt. Ein Beispiel für das DE VruProfilUndSubProfil ist durch Tabelle 1.5.4-6 dargestellt. Tabelle 1.5.4-5:VruGrößenKlasse-Beschreibung basierend auf Profilen
    Profil Profilwert VruGrößenKlasse Wert VruGrößenKlassen-Beschreibung
    Nicht Verfügbar 0 0 N/A
    Fußgänger 1 0 Nicht Verfügbar
    1 Niedrig → 1 m Höhe oder weniger
    2 Mittel → größer als 1 m und 1,5 m oder geringere Höhe
    3 Hoch → größer als 1,5 m
    Fahrradfahrer 2 0 Nicht Verfügbar
    1 Niedrig → 1,5 m oder geringere Höhe
    2 Mittel → mehr als 1,5 m Höhe, 1 m oder weniger von vorne nach hinten
    3 Hoch → mehr als 1,5 m Höhe, mehr als 1 m von vorne nach hinten
    Motorradfahrer 3 0 Nicht Verfügbar
    1 Niedrig → 1,5 m oder geringere Höhe
    2 Mittel → mehr als 1,5 m Höhe, 1 m oder weniger von vorne nach hinten
    3 Hoch → mehr als 1,5 m Höhe, mehr als 1 m von vorne nach hinten
    Tiere 4 0 Nicht Verfügbar
    1 Niedrig → 60 kg oder weniger und 1,5 m Höhe oder weniger
    2 Mittel → mehr als 60 kg und 100 kg oder weniger und 1,5 m Höhe oder weniger
    3 Hoch → mehr als 100 kg oder mehr als 1,5 m Höhe
    ANMERKUNG: Eine Höhe von 1,5 m eines VRU als Grenze macht den Unterschied zwischen von einem geparkten Auto verdeckt und nicht von einem geparkten Auto verdeckt.
    Tabelle 1.5.4-6: DE_VruProfilUndSubProfil
    Beschreibungsname VruProfilUndSubProfil
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0002
    Definition Profil eines VRU mit Subprofilinformationen. Dieses DE wird im VRU-Niederfrequenz-Container-DF wie in Klausel B.4.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE VruAußenLicht gibt den Status der wichtigsten Außenlichtschalter der VRU-ITS-S an, von der die VAM stammt. Das DE VruAußenLicht ist für das Profil 2 und das Profil 3 obligatorisch, falls der Low-VRU-LF-Container vorhanden ist. Für alle anderen Profile ist es optional.
  • Das DE/DF vruProfilUndSubProfil DE/DF beinhaltet oder gibt ein Profil der ITS-S an, von der die VAM stammt, einschließlich Subprofilinformationen. Die Einstellregeln für diesen Wert können an anderer Stelle definiert oder erörtert werden (vgl. z.B. [TS103300-2] und/oder [TS103300-3]). Die Profil-ID identifiziert die vier Typen von VRU-Profilen, die in [TS103300-2] und/oder [TS103300-3] spezifiziert sind: Fußgänger, Fahrradfahrer, Motorradfahrer und Tier. Die Profiltypnamen sind beschreibend: Beispielsweise würde ein von Menschen angetriebenes Dreirad dem Fahrradfahrer-Profil entsprechen. Die SubProfil-ID identifiziert verschiedene Typen von VRUs 116/117 innerhalb eines Profils. Bedingt obligatorisch, falls vruNiederFrequenzContainer enthalten ist. Das DE wird wie in Klausel F.4.1 von [TS103300-3] spezifiziert dargestellt.
  • Das DE/DF vruSubProfilFußgänger beinhaltet oder gibt das Subprofil der ITS-S an, von der die VAM stammt. Die Einstellregeln für diesen Wert können an anderer Stelle definiert oder erörtert werden (vgl. z.B. [TS103300-2] und/oder [TS103300-3]). Das DE wird wie in Klausel F.4.2 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-7 gezeigt dargestellt. Tabelle 1.5.4–7:DE_VruSubProfilFußgänger
    Beschreibungsname VruSubProfilFußgänger
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0003
    Definition Subprofil eines VRU aus Profil 1. Der entsprechende Wert ist wie in Tabelle 1.5.4-4 und/oder Klausel 7.3.4 von [TS103300-3] zu setzen. Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen. Dieses DE wird im VRU-Niederfrequenz-Container-DF wie in Klausel B.4.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE/DF vruSubProfilFahrradfahrer beinhaltet oder gibt das Subprofil der ITS-S an, von der die VAM stammt. Die Einstellregeln für diesen Wert liegen außerhalb des Schutzumfangs des vorliegenden Dokuments (vgl. z.B. [TS103300-2]). Das DE wird wie in Klausel F.4.3 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-8 gezeigt dargestellt. Tabelle 1.5.4-8: DE_VruSubProfilFahrradfahrer
    Beschreibungsname VruSubProfilFahrradfahrer
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0004
    Definition Subprofil eines VRU aus Profil 2. Der entsprechende Wert ist wie in Tabelle 1.5.4-4 und/oder Klausel 7.3.4 von [TS103300-3] zu setzen. Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen. Dieses DE wird im VRU-Niederfrequenz-Container-DF wie in Klausel B.4.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE/DF vruSubProfilMotorradfahrer beinhaltet oder gibt das Subprofil der ITS-S an, von der die VAM stammt. Die Einstellregeln für diesen Wert liegen außerhalb des Schutzumfangs des vorliegenden Dokuments (vgl. z.B. [TS103300-2]). Das DE wird wie in Klausel F.4.4 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-9 gezeigt dargestellt. Tabelle 1.5.4-9: DE_VruSubProfilMotorradfahrer
    Beschreibungsname VruSubProfilMotorradfahrer
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0005
    Definition Subprofil eines VRU aus Profil 3. Der entsprechende Wert ist wie in Tabelle 1.5.4-4 und/oder Klausel 7.3.4 von [TS103300-3] zu setzen. Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen. Dieses DE wird im VRU-Niederfrequenz-Container-DF wie in Klausel B.4.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE/DF vruSubProfilTier beinhaltet oder gibt das Subprofil der ITS-S an, von der die VAM stammt. Die Einstellregeln für diesen Wert liegen außerhalb des Schutzumfangs des vorliegenden Dokuments (vgl. z.B. [TS103300-2]). Das DE wird wie in Klausel F.4.5 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-10 gezeigt dargestellt. Tabelle 1.5.4-10: DE_VruSubProfilTier
    Beschreibungsname VruSubProfilTier
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0006
    Definition Subprofil eines VRU aus dem Profil 4. Der entsprechende Wert ist wie in Tabelle 1.5.4-4 und/oder Klausel 7.3.4 von [TS103300-3] zu setzen. Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen. Dieses DE wird im VRU-Niederfrequenz-Container-DF wie in Klausel B.4.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE/DF vruGrößenKlasse beinhaltet oder gibt die Größenklasse der ITS-S an, von der die VAM stammt. Die Einstellregeln für dieses Feld sind in Tabelle 1,5.4-5 angegeben. Die Größenklasse wird in Kombination mit dem Profiltyp interpretiert, um den Abmessungsbereich des VRU zu erhalten. Obligatorisch, falls vruNiederFrequenzContainer enthalten ist. Das DE wird wie in Klausel F.4.6 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-11 gezeigt dargestellt. Tabelle 1.5.4-11: DE_VruGrößenKlasse
    Beschreibungsname VRUGrößenKlasse
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0007
    Definition Größe eines VRU einschließlich des verwendeten VRU-Fahrzeugs. Der entsprechende Wert ist wie folgt zu setzen:  Niedrig (1): Die VRU-Größenklasse ist abhängig vom VRU-Profil niedrig  Mittel (2): Die VRU-Größenklasse ist abhängig vom VRU-Profil mittel  Hoch (3): Die VRU-Größenklasse ist in Abhängigkeit vom VRU-Profil hoch  Nicht verfügbar(0): Es gibt keine abgeglichene Größenklasse oder aus Datenschutzgründen im Profil 1.  Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen.
    Dieses DE wird in dem VRU-Niederfrequenz-Container-DF wie in Klausel B.4.1 definiert verwendet. Die Abbildung der Größenwerte ist in Klausel 7.3.4 von [TS103300-3], Tabelle 1,5.4-5 gegeben.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE/DF vruAußenLichter beinhaltet oder zeigt den Status der wichtigsten Außenlichtschalter der VRU-ITS-S an, von der die VAM stammt. Bedingt obligatorisch (für VRU-Profil 2 und VRU-Profil 3). Das DE wird wie in Klausel F.4.7 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-11 gezeigt dargestellt. Tabelle 1.5.4-11: DE_VruAußenLichter
    Beschreibender Name VruAußenLichter
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0008
    Definition Dieses DE beschreibt den Status der Außenlichtschalter eines Fahrzeugs oder eines VRU. Das DE ist eine Erweiterung des existierenden Fahrzeug-DE-AußenLichts. Der Wert jedes Bits gibt den Zustand des Schalters an, der das entsprechende Licht betätigt. Das Bit, das einem bestimmten Licht entspricht, wird auf 1 gesetzt, wenn der entsprechende Schalter eingeschaltet wird, entweder manuell durch den Fahrer oder VRU oder automatisch durch ein Fahrzeug- oder VRU-System. Die Bitwerte geben nicht an, ob die entsprechenden Leuchten leuchten oder nicht. Wenn ein Fahrzeug oder ein VRU nicht mit einem bestimmten Licht ausgestattet ist oder wenn die Lichtschalterstatusinformationen nicht verfügbar sind, ist das entsprechende Bit auf 0 zu setzen.
    Einheit N/A
    Kategorie Fahrzeuginformationen, VRU-Informationen
  • Eine VAM, wie etwa die VAM 6b00, die Informationen über einen Cluster von VRUs 116/117 beinhaltet, kann als eine „Cluster-VAM“ bezeichnet werden (z.B. kann die VAM 6b00 als „Cluster-VAM 6b00“ bezeichnet werden). Die VRU-Cluster-Container einer VAM 6b00 enthalten die Clusterinformationen und/oder Operationen in Bezug auf die VRU-Cluster der VRU-ITS-S 117. Die VRU-Cluster-Container bestehen aus zwei Typen von Cluster-Containern gemäß den Eigenschaften der enthaltenen Daten/Parameter: Clusterinformations-Container und Clusterbetrieb-Container.
  • Ein VRU-Clusterinformations-Container wird zu einer VAM 6b00 hinzugefügt, die vom VRU-Clusterführer stammt. Dieser Container stellt die für den VRU-Cluster relevanten Informationen/Parameter bereit. Der VRU-Clusterinformations-Container ist vom Typ VruClusterlnformationsContainer. Ein VRU-Clusterinformations-Container umfasst Informationen über die Clusterkennung (ID), die Form des Clusterbegrenzungsrahmens, die Kardinalitätsgröße des Clusters und Profile der VRUs 116/117 im Cluster. Die Cluster-ID ist vom Typ ClusterID. ClusterID wird vom Clusterführer so ausgewählt, dass sie ungleich null und lokal eindeutig ist, wie in Klausel 5.4.2.2 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-1 gezeigt. Die Form des VRU-Clusterbegrenzungsrahmens wird durch das DF ClusterBegrenzungsRahmenForm spezifiziert. Die Form des Clusterbegrenzungsrahmens kann rechteckig, kreisförmig oder ein Polygon sein. Ein Beispiel für das DF ClusterBegrenzungsRahmenForm ist durch Tabelle 1.3-2 gezeigt. Tabelle 1.5.4-1: DE_ClusterID
    Beschreibender Name ClusterlD
    Kennung DatenTyp XX
    ASN.1-Darstellung ClusterID ::= INTEGER (0..255)
    Definition ID eines VRU-Clusters. Dieses DE wird im VRU-Clusterinformations-Container-DF wie in Klausel B.5.1 definiert verwendet.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
    Tabelle 1.3-2: DF_ClusterBegrenzungsRahmenForm
    Beschreibender Name ClusterBegrenzungsRahmenForm
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0009
    Definition Begrenzungsrahmen eines VRU-Clusters. Siehe Anhang E für Definitionen dieser Typen
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • BereichRechteck, BereichKreis und BereichPolygon, sind in Tabelle 1.5.4-3, Tabelle 1.5.4-4 bzw. Tabelle 1.5.4-5 gezeigt, und zusätzliche Aspekte dieser DEs/DFs sind durch Tabelle 1.5.4-6, Tabelle 1.5.4-7, Tabelle 1.5.4-8, Tabelle 1.5.4-9, Tabelle 1.5.4-10, Tabelle 1.5.4-11, Tabelle 1.5.4-12, Tabelle 1.5.4-13, Tabelle 1.5.4-14 und Tabelle 1.5.4-15 gezeigt. Tabelle 1.5.4-3: DF_BereichRechteck
    Beschreibender Name BereichRechteck
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0010
    Figure DE112020006966T5_0011
    Definition Beschreibt einen rechteckigen Bereich. Das Rechteck ist um den KnotenMittelPunkt zentriert, der stets bereitgestellt wird, wenn dies für die VAM verwendet wird. In dieser Struktur gilt:  KnotenMittelPunkt ist der Versatzpunkt, um den das Rechteck in Bezug auf die Position zentriert ist, die in dem Basis-Container erscheint.  großeHalbachseBereichLänge ist die halbe Länge des Rechtecks in Einheiten von 0,1 Metern.  kleineHalbachseBereichLänge ist die halbe Breite des Rechtecks in Einheiten von 0,1 Metern.  großeHalbachseBereichOrientierung ist die Orientierung der großeHalbachseBereichLänge des Rechtecks im WGS84-Koordinatensystem, das in Einheiten von 0,1 Grad gegeben ist.  HalbachseHöhe wird weggelassen, wenn dieser Typ verwendet wird, um eine VRU-Clusterbegrenzung anzugeben.
    Tabelle 1.5.4-4: DF_BereichKreis
    Beschreibender Name BereichKreis
    Kennung DatenTyp_ XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0012
    Definition Beschreibt einen kreisförmigen Bereich. Das Rechteck ist um den KnotenMittelPunkt zentriert, der stets bereitgestellt wird, wenn dies für die VAM verwendet wird. In dieser Struktur gilt:  KnotenMittelPunkt ist der Versatzpunkt, um den das Rechteck in Bezug auf die Position zentriert ist, die in dem Basis-Container erscheint.  Der Radius ist der Radius des Kreises in Einheiten von 0,1 Metern.
    Tabelle 1.5.4-5: DF_BereichPolygon
    Beschreibender Name BereichPolygon
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0013
    Definition Beschreibt einen polygonalen Bereich, der durch Verbinden der Versatzpunkte in der bereitgestellten Sequenz konstruiert wird. Der letzte Punkt ist mit dem ersten Punkt zu verbinden, um das Polygon zu schließen. Der erste Punkt ist relativ zu der Referenzposition im Basis-Container versetzt. Jeder nachfolgende Punkt ist relativ zu dem Punkt vor ihm in der Liste versetzt.
    Tabelle 1.5.4-6: DF_VersatzPunkt
    Beschreibender Name VersatzPunkt
    Kennung DatenTyp_ XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0014
    Definition Beschreibt einen Punktversatz in zwei und optional drei Dimensionen gegenüber einem Referenzpunkt. Siehe die Definition der einschließenden Struktur einer Spezifikation, wie der Referenzpunkt erhalten wird.  KnotenVersatzPunktXY ist der Versatz in 1-cm-Einheiten relativ zum Referenzpunkt entlang der Oberfläche des WGS84-Ellipsoids. Der Typ KnotenVersatzPunktXY ist in ISO/TS 19091 definiert.  KnotenVersatzPunktZ ist der Versatz in 1-cm-Einheiten gegenüber dem Referenzpunkt senkrecht zur Oberfläche des WGS84-Ellipsoids.
    Tabelle 1.5.4-7: DF_KnotenVersatzPunktZ
    Beschreibender Name KnotenVersatzPunktZ
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0015
    Definition Spezifiziert den Versatz in 1-cm-Einheiten gegenüber einem Referenzpunkt senkrecht zur Oberfläche des WGS84-Ellipsoids. Die Typen Versatz-Bxx sind in ISO/TS 19091 definiert.
    Tabelle 1.5.4-8: DE_Radius
    Beschreibender Name Radius
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0016
    Definition Spezifiziert den Radius eines Kreises in 10-cm-Einheiten.
    Tabelle 1.5.4-9: DF_PolyPunktListe
    Beschreibender Name PolyPunktListe
    Kennung DatenTyp_XX
    ASN.1-Darstellung PolyPunktListe ::= SEQUENZ (GRÖSSE(3..16, ...)) VON VersatzPunkt
    Definition Spezifiziert eine Liste von Punkten. Zum Definieren eines Polygons in DF_BereichPolygon verwendet.
    Tabelle 1.5.4-10: DE _HalbachseBereichLänge
    Beschreibender Name PolyPunktListe
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0017
    Definition Gibt eine Länge in Einheiten von 0,1 Meter an.
    Tabelle 1.5.4-11: DF_WGS84Winkel
    Beschreibender Name WGS84Winkel
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0018
    Definition Spezifiziert einen Winkel und eine Konfidenz relativ zu Nord auf dem WGS84-Ellipsoid.
    Tabelle 1.5.4-12: DE_WGS84WinkelWert
    Beschreibender Name WGS84WinkelWert
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0019
    Definition Spezifiziert einen Winkel relativ zu Nord auf dem WGS84-Ellipsoid in Einheiten von 0,1 Grad.
    Tabelle 1.5.4-13: DE_WinkelKonfidenz
    Beschreibender Name Winkel Konfidenz
    Kennung DatenTyp_XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0020
    Definition Spezifiziert den 95 %-Konfidenzbereich eines angegebenen Winkels relativ zu Nord auf dem WGS84-Ellipsoid. Der Bereich ist in Einheiten von 0,1 Grad angegeben. Der gegebene Wert ist der 95 %-Konfidenzbereich auf einer Seite des angegebenen Winkels, d.h. der volle 95 %-Konfidenzbereich deckt einen Winkel von zweimal dem in WinkelKonfidenz angegebenen Wert ab.  AußerhalbBereich gibt an, dass der 95 %-Konfidenzbereich einen Winkel abdeckt
    Tabelle 1.5.4-14: DE_ClusterKardinalitätGröße
    Beschreibender Name ClusterKardinalitätGröße
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0021
    Definition Kardinalitätsgröße eines VRU-Clusters. Der Maximalwert wird wie in Klausel 8 spezifiziert gesetzt. Dieses DE wird im VRU-Clusterinformations-Container-DF wie in Klausel B.5.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
    Tabelle 1.5.4-15: DE_ClusterProfile
    Beschreibender Name ClusterProfile
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0022
    Definition VRU-Profile codierende Bitmap, um zu ermöglichen, dass mehrere Profile in einem einzelnen Cluster (heterogener Cluster, falls mehr als ein Profil) angegeben werden.
    Das entsprechende Bit ist unter folgenden Bedingungen auf 1 zu setzen:  Fußgänger (0): Der VRU-Cluster enthält mindestens einen Fußgänger-VRU,  Fahrrad(1): Der VRU-Cluster enthält mindestens ein Fahrrad-VRU-Element,  Motorrad(2): Der VRU-Cluster wenigstens ein Motorrad-VRU-Element,  Tier(3): Der VRU-Cluster enthält mindestens ein Tier-VRU-Element, Andernfalls ist das entsprechende Bit auf 0 zu setzen. Dieses DE wird im VRU-Clusterinformations-Container-DF wie in Klausel B.5.1 von [TS103300-3] definiert verwendet.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • Ein VRU-Clusterbetrieb-Container enthält Informationen, die für eine Änderung des Clusterzustands und der Clusterzusammensetzung (Zusammens.) relevant sind. Dieser Container kann von einem Cluster-VAM-Sender oder von einem Clusterelement (z.B. Clusterführer/CH oder gewöhnliches Element) eingebunden sein. Ein Clusterführer/CH beinhaltet einen VRU-Clusterbetrieb-Container zum Durchführen von Clusteroperationen zum Auflösen (Aufbrechen) des Clusters. Ein Clusterelement beinhaltet einen VRU-Clusterbetrieb-Container in seiner individuellen VAM 6b00, um Clusteroperationen zum Beitreten zu einem VRU-Cluster und Verlassen eines VRU-Clusters durchzuführen. VRU-Clusterbetrieb-Container sind vom Typ VruClusterBetriebContainer.
  • VruClusterBetriebContainer stellt Folgendes bereit: DF Cluster BeitrittInfo für Clusterbetrieb zum Beitreten eines neuen Elements zu einem VRU-Cluster; DF ClusterAustrittInfo für ein bestehendes Clusterelement, um einen VRU-Cluster zu verlassen; DF ClusterAufbruchInfo zum Durchführen von Clusteroperationen zum Auflösen (Aufbrechen) jeweils durch den Clusterführer; und DE ClusterldÄnderungZeitInfo , um anzugeben, dass der Clusterleiter beabsichtigt, die Cluster-ID zu dem im DE angegebenen Zeitpunkt zu ändern. Die neue ID wird aus Datenschutzgründen nicht mit der Angabe versehen (siehe z.B. Klausel 5.4.2.3 und Klausel 6.5.4 von [TS103300-3]).
  • Eine VRU-Vorrichtung 117, die einem Cluster beitritt oder diesen verlässt, der in einer anderen Nachricht als einer VAM angekündigt ist, gibt dies unter Verwendung des ClusterId-Werts 0 an. Eine VRU-Vorrichtung 117, die einen Cluster verlässt, gibt den Grund, warum sie den Cluster verlässt, unter Verwendung des DE ClusterAustrittGrund an. Die verfügbaren Gründe sind in Tabelle 1.5.4-16 dargestellt. Eine VRU-Führer-Vorrichtung, die einen Cluster aufbricht, gibt den Grund, warum sie den Cluster aufbricht, unter Verwendung des ClusterAufbruchGrund an. Die verfügbaren Gründe sind in Tabelle 1.5.4-17 dargestellt. Falls der Grund für das Verlassen des Clusters oder das Aufbrechen des Clusters nicht exakt mit einem der verfügbaren Gründe übereinstimmt, sendet die Vorrichtung systematisch den Wert „nichtBereitgestellt(0)“. Tabelle 1.5.4-16: Beschreibung ClusterAustrittGrund
    Name Wert Beschreibung
    ClusterAustrittGrund 0 nichtBereitgestellt
    1 ClusterFührerVerloren
    2 ClusterDurchFührerAufgelöst
    3 außerhalbClusterBegrenzungsRahmen
    4 außerhalbClusterGeschwindigkeitsBerei ch
    5 BeitrittZuAnderemCluster
    6 StornierterBeitritt
    7 FehlgeschlagenerBeitritt
    8 SicherheitsBedingung
    Tabelle 1.5.4-17: Beschreibung ClusterAufbruchGrund
    Name Wert Beschreibung
    ClusterAufbruchGrund 0 nichtBereitgestellt
    1 ClusteringZweckErfüllt
    2 FührerHatClusterBegrenzungsRahmen Verlassen
    3 BeitrittZuAnderemCluster
    4 EintrittNiedrigRisikoBereichBasierendau fKARTEN
    5 EmpfangVonClusterEnthaltenderCPM
  • Insbesondere kann ein VRU 116/117 in einem Cluster bestimmen, dass ein oder mehrere neue Fahrzeuge oder andere VRUs 116/117 (z.B. VRU-Profil 3 - Motorradfahrer) seitlich näher als ein minimaler sicherer Seitenabstand(MSLaD, minimum safe lateral distance) und in Längsrichtung näher als ein minimaler sicherer Längsabstand (MSLoD, minimum safe longitudinal distance) und vertikal näher als ein minimaler sicherer Vertikalabstand (MSVD, minimum safe vertical distance) gekommen sind (die Bedingung des minimalen Sicherheitsabstands wird wie in Klausel 6.5.10.5 von [TS103300-3] erfüllt); Er verlässt den Cluster und tritt in einen VRU-AKTIV-EINZEL-VBS-Zustand ein, um eine sofortige VAM mit ClusterAustrittGrund „SicherheitsBedingung(8)“ zu übertragen. Das gleiche gilt, wenn irgendein anderes Sicherheitsproblem durch die VRU-Vorrichtung 117 detektiert wird. Vorrichtungsanbieter und/oder -hersteller können die Bedingungen erklären, unter denen die VRU-Vorrichtung 117 einem Cluster beitritt/diesen verlässt.
  • Der VruClusterBetriebContainer beinhaltet nicht die Erstellung eines VRU-Clusters durch den Clusterführer. Wenn der Clusterführer beginnt, eine Cluster-VAM 6b00 zu senden, gibt dieser an, dass er einen VRU-Cluster erstellt hat. Während der Clusterleiter eine Cluster-VAM 6b00 sendet, können beliebige einzelne VRUs 116/117 dem Cluster beitreten, falls die Beitrittsbedingungen erfüllt sind.
  • Der VRU-Clusterbetrieb-Container der VAM 6b00 ist vruClusterBetriebContainer. Der VRU-Clusterbetrieb-Container beinhaltet die folgenden Parameter: ClusterBeitrittInfo, ClusterAustrittInfo; ClusterAufbruchInfo; und ClusterldAnderungZeitInfo. Das ClusterBeitrittInfo -DF gibt die Absicht eines einzelnen VAM-Senders an, einem Cluster beizutreten. Das ClusterBeitrittInfo-DF beinhaltet Clusterld und BeitrittZeit. Die Clusterld ist die Clusterkennung für den Cluster, dem beigetreten werden soll (z.B. identisch mit dem ClusterId-Feld im vruInformationClusterContainer in der VAM 6b00, die den Cluster beschreibt, dem der Sender der ClusterBeitrittInfo beitreten möchte). Die BeitrittZeit ist die Zeit, nach der der Sender keine einzelnen VAMs 6b00 mehr sendet und/oder eine Zeit, nach der der VAM-Sender die Übertragung einzelner VAMs 6b00 stoppt. Sie wird wie in Klausel F.6.6 von [TS103300-3], VruClusterOpZeitstempel, und/oder wie durch Tabelle 1.5.4 spezifiziert präsentiert und interpretiert. Tabelle 1.5.4-18: DF_ClusterBeitrittInfo
    Beschreibender Name ClusterBeitrittlnfo
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0023
    Figure DE112020006966T5_0024
    Definition Dieses DF wird im VRU-Clusterbetrieb-Container-DF wie in Klausel B.6.1 von [TS103300-3] definiert verwendet. In diesem DF ist Clusterld die Clusterkennung für den Cluster, dem beigetreten werden soll, und BeitrittZeit ist die Zeit, nach der der Sender keine einzelnen VAMs mehr sendet.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • Das ClusterAustrittInfo-DF gibt an, dass ein einzelner VAM-Sender kürzlich den VRU-Cluster verlassen hat. Dieses DF wird wie in Klausel F.2.6 von [TS103300-3] unter ClusterAustrittinfo, ClusterId und ClusterAustrittGrund spezifiziert und/oder wie in Tabelle 1.5.4-19 gezeigt dargestellt. Die Clusterld ist identisch mit dem ClusterId-Feld im VruClusterInformationContainer in der VAM 6b00, die den Cluster beschreibt, den der Sender der ClusterAustrittinfo kürzlich verlassen hat. Der ClusterAustrittGrund gibt den Grund an, warum der Sender der ClusterAustrittInfo den Cluster kürzlich verlassen hat. Er wird wie in Klausel F.6.4 von [TS 103300-3], ClusterAustrittGrund, und/oder wie in Tabelle 1.5.4-19 gezeigt dargestellt und interpretiert. Dieses DF wird im VRU-Clusterbetrieb-Container-DF wie in Klausel B.6.1 von [TS 103300-3] definiert verwendet. In diesem DF ist Clusterld die Clusterkennung für den Cluster, den der VAM-Sender gerade verlassen hat, und ClusterAustrittGrund ist der Grund dafür, warum er diesen verlassen hat. Tabelle 1.5.4-19: DF_ClusterAustrittlnfo
    Beschreibender Name ClusterAustrittlnfo
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0025
    Definition Dieses DF wird in dem VRU-Cluster-Operation-Container-DF wie in Klausel B.6.1 von [TS103300-3] definiert verwendet. In diesem DF ist Clusterld die Clusterkennung für den Cluster, den der VAM-Sender gerade verlassen hat, und ClusterAustrittGrund ist der Grund, warum er diesen verlassen hat.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • Das DF ClusterAufbruchInfo gibt die Absicht eines Cluster-VAM-Senders an, das Senden von Cluster-VAMs zu stoppen. Dieses DF wird wie in Klausel B.6.1 und/oder Klausel F.6.3 von [TS103300-3], ClusterAufbruchInfo, ClusterAufbruchGrund; AufbruchZeit; und/oder wie in Tabelle 1.5.4-20 gezeigt dargestellt. Der ClusterAufbruchGrund gibt den Grund an, warum der Sender von ClusterAufbruchInfo beabsichtigt, den Cluster aufzubrechen. Er wird wie in Klausel F.6.5 von [TS103300-3], ClusterAufbruchGrund, spezifiziert dargestellt und interpretiert. Die AufbruchZeit gibt eine Zeit an, nach der der VAM-Sender das Übertragen von Cluster-VAMs stoppt. Sie wird wie in Klausel F.6.6 von [TS103300-3], VruClusterOpZeitstempel spezifiziert dargestellt und interpretiert. Tabelle 1.5.4-20: DF_ClusterAufbruchInfo
    Beschreibender Name ClusterAufbruchlnfo
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0026
    Definition Diese DF wird im VRU-Clusterbetrieb-Container-DF wie in Klausel B.6.1 von [TS103300-3] definiert verwendet. In diesem DF ist ClusterAufbruchGrund der Grund für das Aufbrechen, und AufbruchZeit ist die Zeit, nach der der Sender keine Cluster-VAMs mehr sendet.
    ANMERKUNG: Dieses DF enthält keine Clusterld, da diese im VruClusterinformationsContainer angegeben wird.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • Das DF ClusterldÄnderungZeitInfo gibt die Absicht eines Cluster-VAM-Senders an, die Cluster-ID zu ändern. Diese DE wird als in Klausel B.6.1 und/oder Klausel F.6.6 von [TS103300-3], VruClusterOpZeitstempel, präsentiert. VruClusterOpZeitstempel ist eine Zeiteinheit. In einer Implementierung beträgt die Zeiteinheit 256 Millisekunden und wird der VruClusterOpZeitstempel dargestellt als eine GANZZAHL (1..255). Sie kann als die ersten 8 Bytes einer ErzeugungsDeltaZeit interpretiert werden. Um einen VruClusterOpZeitstempel in eine ErzeugungsDeltaZeit umzuwandeln, wird mit 256 multipliziert (z.B. ein „00“-Byte angehängt).
  • Das DF ClusterAustrittGrund gibt den Grund für das Verlassen des VRU-Clusters durch einen einzelnen VAM-Sender an. Dieses DE gibt einen Grund an, warum der VAM-Sender kürzlich den Cluster verlassen hat und/oder begonnen hat, einzelne VAMs zu senden. Sie wird wie in Klausel B.6.1 und/oder Klausel F.6.4 von [TS103300-3], ClusterAustrittGrund, spezifiziert und/oder wie in Tabelle 1.5.4-21 gezeigt dargestellt und interpretiert. In einer Implementierung wird der Wert 15 auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen. Tabelle 1.5.4-21: DE_ClusterAustrittGrund
    Beschreibender Name ClusterAustrittGrund
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0027
    Definition Diese DE wird im VRU-Clusterbetrieb-Container-DF wie in Klausel B.6.1 von [TS103300-3] definiert verwendet. Es gibt den Grund an, warum eine VRU-Vorrichtung einen Cluster verlassen hat und begonnen hat, einzelne VAMs zu senden. Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • Das DF ClusterAufbruchGrund gibt den Grund für das Auflösen des VRU-Clusters durch einen Cluster-VAM-Sender an. Dieses DE gibt einen Grund dafür, warum ein Clusterführer-VRU den Cluster aufgebrochen hat, den er geführt hat, und/oder den Grund dafür an, warum der VAM- Sender das Übertragen von Cluster-VAMs stoppt. Sie wird wie in Klausel B.6.1 und/oder Klausel F.6.5 von [TS103300-3], ClusterAufbruchGrund, spezifiziert und/oder wie in Tabelle 1.5.4-22 gezeigt dargestellt und interpretiert. In einer Implementierung wird der Wert 15 auf „max" gesetzt, um die Größe des codierten Feldes zu begrenzen. Tabelle 1.5.4-22: DE_ClusterAufbruchGrund
    Beschreibender Name ClusterAufbruchGrund
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0028
    Definition Diese DE wird im VRU-Clusterbetrieb-Container-DF wie in Klausel B.6.1 von [TS103300-3] definiert verwendet. Dieses DE gibt den Grund an, warum ein Clusterführer-VRU den Cluster, den er angeführt hat, aufgebrochen hat. Der Wert 15 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen.
    Einheit N/A
    Kategorie VRU-Clusterinformationen
  • Die Parameter in Tabelle 1.5.4-23 regeln die VRU-Entscheidung, einen Cluster zu erstellen, diesem beizutreten oder diesen zu verlassen. Die Parameter können auf einzelnen Vorrichtungen oder systemweit eingestellt werden und können von externen Bedingungen abhängen oder von diesen unabhängig sein. Tabelle 1.5.4-23: Parameter für VRU-Clusterbildungsentscheidungen
    Parameter Typ Bedeutung Empfohlener Bereich
    anzErstelleCluster Ganzzahl Anzahl von VRU-Vorrichtungen, deren Beitritt zu einem Cluster ein potentieller Clusterführer antizipiert, falls einer erzeugt wird [3 bis 5]
    maxClusterAbstand Abstand (in m) maximaler Abstand zwischen dem Rand des Clusters und dem VRU, der die Bewertung durchführt. Dieser Wert schränkt zudem die Größe eines VRU-Clusters ein [3 bis 5]
    maxClusterGeschwindigkeitsve ktorDifferenz Prozentsatz maximale Geschwindigkeit-Geschwindigkeitsvektor-Differenz innerhalb eines Clusters 5 %
    maxKombinierterClusterAbstan d Abstand (in m) maximaler Abstand zwischen dem Rand des kombinierten VRU-Clusters und dem VRU, der die Bewertung durchführt. Dieser Wert schränkt zudem die Größe eines kombinierten VRU-Clusters ein [1 bis 2]
    minClusterGröße Ganzzahl Minimale Größe eines VRU-Clusters. Wird verwendet, um das Feld ClusterKardinalitätGröße direkt nach der Erstellung und vor dem Beitritt eines VRU zu füllen (siehe Anmerkung 1). 1
    maxClusterGröße Ganzzahl Maximale Größe (oder Anzahl aktiver ITS-S) eines VRU-Clusters. Wird wird von einem VRU verwendet, um zu prüfen, ob dieser dem Cluster beitreten kann. In der Praxis kann der Cluster größer sein und nicht-ausgestattete VRUs beinhalten, die nicht an der Clusterbildungsoperation teilnehmen können und als solche durch den Clusterführer identifiziert werden können. 20 (siehe Anmerkung 2)
    anzClusterVAMWiederholung Ganzzahl Anzahl von VAM-Wiederholungen mit früheren Kennungen im Fall eines Cluster-Aufhebens oder eines fehlgeschlagenen Teilnehmers 3
    ANMERKUNG 1: Die Minimalgröße von 1 für die Clusterkardinalitätsgröße bedeutet nicht, dass irgendein VRU ein eigener Cluster sein kann, da ein VRU die in Klausel 5.4.2.4 festgelegten Kriterien erfüllen sollte, bevor er einen Cluster erstellt. Dieser Wert wird auf 1 gesetzt, um den Clusterzustand unmittelbar nach dem Erstellen und bevor irgendein anderer VRU eine Möglichkeit zum Beitreten hatte, widerzuspiegeln.
    ANMERKUNG 2: Der im vorliegenden Dokument gegebene Wert ist ein anfänglicher indikativer Wert. Er kann in einer späteren Überarbeitung geändert werden, nachdem mehr Bewertungen der Clusterbildung durchgeführt wurden.
  • Die Parameter in Tabelle 1.5.4-24 regeln das Nachrichtenübermittlungsverhalten im Zusammenhang mit dem Beitreten zu und Verlassen von Clustern. Die Parameter können auf einzelnen Vorrichtungen oder systemweit eingestellt werden und können von externen Bedingungen abhängen oder von diesen unabhängig sein. Tabelle 1.5.4-24: Clusterzugehörigkeitsparameter
    Parameter Typ Bedeutung Empfohlener Standardwert
    ZeitClusterEindeutigkeitsSchwelle Zeitraum Wenn ein Clusterführer eine Cluster-ID auswählt, muss sich diese von jeder Cluster-ID unterscheiden, die von dem Clusterführer innerhalb dieser Zeit empfangen wird 30 Sekunden
    ZeitClusterAufbruchWarnung Zeitraum Wenn ein Clusterführer die Entscheidung getroffen hat, einen Cluster zu beenden, bindet er in seinen VAMs eine Angabe des bevorstehenden Endes des Clusters für diese Zeit ein. 3 Sekunden
    ZeitClusterbeitrittsBenachrichtigung Zeitraum Wenn eine VRU-Vorrichtung, die individuelle VAMs sendet, einem Cluster beizutreten beabsichtigt, bindet sie in ihren VAMs eine Angabe dieser Absicht für diese Zeit ein 3 Sekunden
    ZeitClusterbeitrittsErfolg Zeitraum Nachdem eine VRU-Vorrichtung einem Cluster beigetreten ist, wartet sie für diese Zeitdauer darauf, dass die Cluster-VAM den Umstand widerspiegelt, dass die VRU-Vorrichtung dem Cluster beigetreten ist, und verlässt diesen, falls nicht 0,5 Sekunden
    ZeitClusterÄnderungsBenachrichtigung Zeitraum Zeit, für die ein Clusterführer ankündigt, dass er seine ID ändern wird, bevor er sie ändert 3 Sekunden
    ZeitClusterldFortdauer Zeitraum Falls sich die Cluster-ID für eine bestimmte Vorrichtung ändert, ist dies die Zeit, für die sie weiterhin die alte ID in einer Clusteraustrittsanzeige verwenden kann 3 Sekunden
    ZeitClusterKontinuität Zeitraum Falls eine VRU-Vorrichtung, die ein Element eines Clusters ist, für diesen Zeitraum keine Cluster-VAM empfängt, verlässt sie den Cluster 2 Sekunden
    ZeitClusterAustrittsBenachrichtigung Zeitraum Nachdem eine VRU-Vorrichtung einen Cluster verlassen hat, bindet sie in ihre VAMs für diese Zeit eine Angabe des Clusters ein, den sie verlassen hat 1 Sekunden
    ZeitKombinierterVruClusterMöglichkeit Zeitraum Zeit, für die eine ITS-S ankündigt, dass sie anbietet, einen kombinierten VRU-Cluster zu bilden 15 Sekunden
  • Der VAM-VRU-Bewegungsvorhersage-Container trägt die vergangenen und künftigen Bewegungszustandsinformationen des VRU. Der VRU-Bewegungsvorhersage-Container des Typs VruBewegungVorhersageContainer enthält Informationen über die vergangenen Standorte des VRU des Typs WegHistorie, vorhergesagte künftige Standorte des VRU (formatiert als Sequenz Von Vru WegPunkt), eine Angabe eines sicheren Abstands zwischen VRU und anderen Verkehrsteilnehmern/Objekten des Typs SequenzVruSichererAbstandAngabe, eine mögliche Trajektorienabfangung des VRU durch einen anderen VRU/ein anderes Objekt ist vom Typ SequenzVonTrajektorieAbfangungAnzeige, die Änderung der Beschleunigung des VRU ist vom Typ BeschleunigungAnderungAngabe, die Kursänderungen des VRU sind vom Typ KursÄnderungAngabe, und Änderungen der Stabilität des VRU sind vom Typ StabilitätÄnderungAnzeige. Der VRU-Bewegungsvorhersage-Container beinhaltet die folgenden Parameter: WegHistorie; WegVorhersage; sichererAbstand; TrajektorieAbfangungAnzeige, BeschleunigungÄnderungAnzeige; KursÄnderungAnzeige; und StabilitätÄnderungAnzeige.
  • Das Weghistorie-DF (WegHistorie) ist vom Typ WegHistorie. Das DF WegHistorie umfasst die kürzliche Bewegung des VRU über eine vergangene Zeit und/oder eine vergangene Strecke. Das DF WegHistorie beinhaltet bis zu 40 vergangene Wegpunkte, die jeweils als DF WegPunkt dargestellt sind (vgl. [TS102894-2], A117 WegHistorie, A118; und/oder Klausel 7.3.6 von [TS103300-3]). Jeder WegPunkt beinhaltet PfadPosition (A109) und eine optionale WegDeltaZeit (A47) mit einer Granularität von 10 ms. Wenn ein VRU einen Cluster verlässt und seine vergangenen Standorte in der VAM übertragen will, kann der VRU das WegHistorie-DF verwenden.
  • Das WegVorhersage-DF (WegVorhersage) stellt den Satz von vorhergesagten Standorten der ITS-S, Konfidenzwerte und die entsprechenden zukünftigen Zeitpunkte bereit. Das WegVorhersage-DF ist vom Typ SequenzVonVruWegPunkt und definiert bis zu 40 künftige Wegpunkte, Konfidenzwerte und entsprechende Zeitinstanzen der VRU-ITS-S. Es enthält zukünftige Weginformationen für bis zu 10 Sekunden oder bis zu 40 Wegpunkte, je nachdem, was kleiner ist. Das DF wird wie in Klausel F.7.1 von [TS103300-3] und/oder wie in Tabelle 1.5.4-25 spezifiziert dargestellt. Es handelt sich um eine Sequenz von Vru WegPunkt. Das Vru WegPunkt-DE stellt den vorhergesagten Standort der ITS-S, den Konfidenzwert und den entsprechenden zukünftigen Zeitpunkt bereit. Das DE ist wie in Klausel F.7.2 von [TS103300-3] und/oder wie in Tabelle 1.5.4-26 spezifiziert darzustellen. Tabelle 1.5.4-25: DF_SequenzVonVruWegPunkt
    Beschreibungsname SequenzVonVruWegPunkt
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0029
    Definition Dieses DF stellt bis zu 40 vorhergesagte Wegpunkte der VRU-ITS-S bereit
    Einheit N/A
    Kategorie VRU-Informationen
    Tabelle 1.5.4-26: DF_VruWegPunkt
    Kennung DatenTyp XX
    Beschreibungsname VruWegPunkt
    ASN.1-Darstellung
    Figure DE112020006966T5_0030
    Definition Dieses DF stellt einen vorhergesagten Wegpunkt und ein Konfidenzniveau wie durch ReferenzPosition definiert (vgl. z.B. [TS102894-2]) und einen entsprechenden Zeitpunkt wie durch WegDeltaZeit definiert (siehe z.B. [TS102894-2]) der VRU-ITS-S bereit.
    Einheit N/A
    Kategorie VRU-Informationen
  • Die Sicherheitsabstandsanzeige (z.B. vruSicherAbstand) liefert eine Angabe eines sicheren Abstands zwischen einem Ego-VRU und bis zu 8 anderen ITS-Ss oder Entitäten auf der Straße, um anzugeben, ob sich das Ego-VRU in einem sicheren Abstand zu einer anderen ITS-S oder Entität auf der Straße befindet (d.h. weniger wahrscheinlich physisch kollidieren wird). Die Angabe des sicheren Abstands ist vom Typ SequenzVonVruSicherAbstandAnzeige und stellt einen Hinweis bereit, ob sich der VRU seitlich, in Längsrichtung und vertikal in einem empfohlenen sicheren Abstand zu bis zu 8 anderen Stationen in seiner Nähe befindet. Die gleichzeitigen Vergleiche zwischen Seitenabstand (Lad), Längsabstand (LoD) und Vertikalabstand (VD) und ihren jeweiligen Schwellen, minimalem sicherem Seitenabstand (MSLaD), minimalem sicherem Längsabstand (MSLoD) und minimalem sicherem Vertikalabstand (MSVD) wie in Klausel 6.5.10.5 von [TS103300-2] definiert, wird zum Einstellen des VruSicherAbstandAnzeige-DF verwendet. Andere beteiligte ITS-S sind als StationID-DE innerhalb des VruSicherAbstandAnzeige-DE angegeben. Das ZeitbisKollision- (TTC-, timetocollision) DE innerhalb des Containers gibt die geschätzte Zeit bis zur Kollision basierend auf den letzten Bordsensormessungen und VAMs wieder. Das DF wird wie in Klausel F.7.3 von [TS103300-3] spezifiziert dargestellt und ist eine Sequenz von VruSicherAbstandAnzeige.
  • Das VruSicherAbstandAnzeige-DE stellt eine Angabe eines sicheren Abstands zwischen einer Ego-VRU und ITS-S oder Entität auf der Straße bereit, um anzugeben, ob sich das Ego-VRU in einem sicheren Abstand zu einer anderen ITS-S oder Entität auf der Straße befindet (d.h. weniger wahrscheinlich physisch kollidieren wird). Es hängt von betreffendeStation; StationSicherAbstandAnzeige; und ZeitBisKollision ab. Dieses DF wird wie in Klausel F.7.4 von [TS103300-3] spezifiziert dargestellt.
  • Das StationSicherAbstandAnzeige-DE beinhaltet oder gibt eine Angabe an, wenn die bedingten Beziehungen LaD < MSLaD, LoD < MSLoD und VD < MSVD gleichzeitig erfüllt sind. Dieses DE ist bei einigen Implementierungen innerhalb der VruSicherAbstandAnzeige obligatorisch. Das DE ist wie in Klausel F.7.5 von [TS103300-3] spezifiziert darzustellen. Das ZeitBisKollision-DF beinhaltet oder gibt die Zeit bis zur Kollision (TTC). Das DE soll die geschätzte Zeit bis zur Kollision basierend auf den letzten Bordsensormessungen und VAMs wiedergeben. Dieses DF wird wie in Klausel F.7.14 von [TS103300-3] spezifiziert von DE_AktionDeltaZeit dargestellt.
  • Das TrajektorieAbfangung-DF stellt die Angabe für eine mögliche Trajektorienabfangung mit bis zu 8 VRUs 116/117 oder anderen Objekten auf der Straße bereit. Dieses DF wird wie in Klausel F.7.6 von [TS103300-3] und/oder Tabelle 1.5.4-27 spezifiziert dargestellt und ist eine Sequenz von VruTrajektorieAbfangungAnzeige. Die VruTrajektorieAbfangungAnzeige ist als ein Indikator der Ego-VRU-Trajektorie und ihrer potentiellen Abfangung mit einer anderen Station oder einem anderen Objekt auf der Straße definiert. Sie hängt von betreffendeStation; TrajektorieAbfangungWahrscheinlichkeit, und/oder TrajektorieAbfangungKonfidenz ab. Dieses DF wird wie in Klausel F.7.7 von [TS103300-3] und/oder wie in Tabelle 1.5.4-28 spezifiziert dargestellt. Tabelle 1.5.4-27: DF_SequenzVonTrajektorieAbfangungAnzeige
    Beschreibungsname TrajektorieAbfangungAnzeige
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0031
    Definition Dieses DF stellt die Trajektorieabfangungsanzeige der Ego-VRU-ITS-S mit 8 anderen ITS-Ss bereit
    Einheit N/A
    Kategorie VRU-Informationen
    Tabelle 1.5.4-28: DF_VruTrajektorieAbfangungAnzeige
    Beschreibungsname TrajektorieAbfangungAnzeige
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0032
    Definition Dieses DF stellt die Trajektorieabfangungsanzeige der Ego-VRU-ITS-S mit anderen ITS-Ss bereit. betreffendeStation ist vom Typ StationID und gibt die betreffende Station an. TrajektorieAbfangungWahrscheinlichkeit und TrajektorieAbfangungKonfidenz sind vom Typ TrajektorieAbfangungWahrscheinlichkeit bzw. TrajektorieAbfangungKonfidenz.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DE TrajektorieAbfangungWahrscheinlichkeit definiert die Wahrscheinlichkeit, dass die Trajektorie des Ego-VRU mit der Trajektorie eines beliebigen anderen Objekts auf der Straße abgefangen wird. In einigen Implementierungen ist dieses DE innerhalb von VruTrajektorieAbfangungAnzeige obligatorisch, und dieses DE wird wie in Klausel F.7.8 von [TS103300-3] und/oder Tabelle 1.5.4-29 spezifiziert dargestellt. Das DE TrajektorieAbfangungKonfidenz definiert das Konfidenzniveau von TrajektorieAbfangungWahrscheinlichkeit-Berechnungen und wird wie in Klausel F.7.9 von [TS103300-3] und/oder Tabelle 1.5.4-30 spezifiziert dargestellt. Tabelle 1.5.4-29: DF_TrajektorieAbfangungW ahrscheinlichkeit
    Beschreibungsname TrajektorieAbfangung
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0033
    Definition • Das DE TrajektorieAbfangungWahrscheinlichkeit spezifiziert die Trajektorieabfangwahrscheinlichkeits- (TIP-) Metrik, die in Bezug auf eine ITS-S im Weg einer potentiellen Trajektorieabfangung berechnet wird. Die TIP soll als probabilistischer Indikator für die Schätzunsicherheit der Ego-VRU-Trajektorie und ihrer potentiellen Abfangung mit einem anderen Objekt oder Personen auf der Straße, die von anderen Stationen auf der Straße reichen, berechnet werden. In Abhängigkeit von der Analyse der Szene hinsichtlich der sensorischen sowie gemeinsam genutzten Eingaben kann das Wahrscheinlichkeitsniveau, dass der Weg des Ego-VRU durch eine andere Station j = 1, 2, ... N abgefangen wird, berechnet werden.
    • Die TIP in Prozent wird auf die nächste gerade Zahl gerundet.
    Einheit 2 %
    Kategorie VRU-Informationen
    Tabelle 1.5.4-30: DE_TrajektoryAbfangungKonfidenz
    Beschreibungsname TrajektorieAbfangungKonfidenz
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0034
    Definition Bezeichnet die geschätzten Konfidenzniveaus der Trajektorieabfangwahrscheinlichkeitsberechnung. Die Konfidenzniveaus (CL) sind in vier Ebenen unterteilt. Diese sind CL < 50 %, 50 % <= CL < 70 %, 70 % <= CL < 90 % und CL>=90 %.
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DF Sequenz Von TrajektorieA bfangunganzeige enthält eine mögliche Trajektorieabfangung mit bis zu 8 anderen Stationen in der Nähe des Ego-VRU. Die Trajektorieabfangung eines VRU wird durch das DF VruTrajektorieAbfangungAnzeige angegeben. Die anderen beteiligten ITS-S werden durch das DE StationID bezeichnet. Die Trajektorieabfangwahrscheinlichkeit und ihre Konfidenzniveaumetriken werden durch TrajektorieAbfangungWahrscheinlichkeit und TrajektorieAbfangungKonfidenz angegeben. Das DF Trajektorieabfanganzeige (TII) entspricht der TII-Definition in [TS103300-2].
  • Das DF KursÄnderungAnzeige enthält Kursänderungen des Ego-VRU in der Zukunft (links oder rechts) für einen Zeitraum. Dieses DF stellt zusätzliche Datenelemente bereit, die mit Kursänderungsindikatoren wie etwa einer Änderung der Fahrtrichtung (links oder rechts) assoziiert sind. Das DE LinksOderRechts gibt die Wahl zwischen einer Kursänderung in der linken und der rechten Richtung. Die Richtungsänderungsaktion wird für einen Zeitraum von AktionDeltaZeit durchgeführt. Das DE AktionDeltaZeit gibt die Zeitdauer an. Wenn vorhanden, beinhaltet das DF die folgenden Datenelemente: LinksOderRechts; und AktionDeltaZeit. Das DF wird wie in Klausel F.7.10 von [TS103300-3] und/oder Tabelle 1.5.4-31 spezifiziert dargestellt. Tabelle 1.5.4-31: DF_KursÄnderungAnzeige
    Beschreibungsname Kursänderunglndikator
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0035
    Definition Dieses DF stellt zusätzliche Datenelemente bereit, die mit Kursänderungsindikatoren wie etwa einer Richtungsänderung assoziiert sind. Die Richtungsänderungsaktion wird für einen Zeitraum von AktionDeltaZeit durchgeführt
    Einheit N/A
    Kategorie VRU-Informationen
  • Das linksOderRechts-DE stellt die Linksabbiege- bzw. Rechtsabbiege-Aktionen bereit, die durch den VRU durchgeführt werden, wenn verfügbar. Ein Linksabbiegen oder Rechtsabbiegen wird für einen von AktionDeltaZeitraum spezifizierten Zeitraum durchgeführt. Dieses DE wird wie in Klausel F.7.11 von [TS103300-3] spezifiziert und/oder wie durch Tabelle 1.5.4-35 gezeigt dargestellt. Das DE AktionDeltaZeit stellt einen Satz gleichmäßig beabstandeter Zeitinstanzen bereit, falls verfügbar. Das DE definiert einen Satz von Zeitinstanzen mit 100 ms-Granularität beginnend von 0 (aktueller Zeitpunkt) bis zu 12,6 Sekunden. Das DE AktionDeltaZeit wird wie in Klausel F.7.14 von [TS103300-3] spezifiziert dargestellt. Tabelle 1.5.4-35: DE_LinksOderRechts
    Beschreibungsname LinksOderRechts
    Kennung DatenTyp XX
    ASN.1-Darstellung LinksOderRechts ::= AUFGEZÄHLT { links, rechts }
    Definition Dieses DE stellt die VRU-Aktionen Linksabbiegen bzw. Rechtsabbiegen bereit
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DF BeschleunigungÄnderungAnzeige stellt eine Beschleunigungsänderungsangabe der VRU bereit. Dieses DF enthält künftige Beschleunigungsänderungen des Ego-VRU (Beschleunigung oder Verlangsamung) für einen Zeitraum. Wenn vorhanden, gibt dieses DF eine erwartete Änderung der VRU-Geschwindigkeit an. Geschwindigkeitsänderungen können sein: Verlangsamen für den Zeitraum von AktionDeltaZeit, oder Beschleunigen für den Zeitraum von AktionDeltaZeit. Das DE BeschlOderVerlangs gibt die Wahl zwischen Beschleunigung und Verlangsamung. Das DE AktionDeltaZeit gibt die Zeitdauer an. Das DF ist wie in Klausel F.7.12 von [TS103300-3] spezifiziert und/oder wie in Tabelle 1.5.4-36. gezeigt darzustellen. Das DE BeschlOderVerlangs stellt die Aktionen Beschleunigung oder Verlangsamung bereit, die durch den VRU durchgeführt werden, wenn verfügbar. Beschleunigung oder Verlangsamung wird für den von AktionDeltaZeit spezifizierten Zeitraum durchgeführt. Dieses DE wird wie in Klausel F.7.13 von [TS103300-3] spezifiziert und/oder wie durch Tabelle 1.5.4-37 gezeigt dargestellt. Tabelle 1.5.4-36: DF_BeschleunigungÄnderungAnzeige
    Beschreibungsname BeschleunigungÄnderungAnzeige
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0036
    Definition Dieses DF stellt zusätzliche Datenelemente bereit, die mit einer Änderung der VRU-Beschleunigung assoziiert sind. Die Beschleunigungsänderungsaktion wird für einen Zeitraum von AktionDeltaZeit durchgeführt
    Einheit N/A
    Kategorie VRU-Informationen
    Tabelle 1.5.4-37: DE_BeschlOderVerlangs
    Beschreibungsname BeschlOderVerlangs
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0037
    Definition Dieses DF stellt die VRU-Aktionen Beschleunigen oder Verlangsamen bereit
    Einheit N/A
    Kategorie VRU-Informationen
  • Das DF StabilitätAnderungAnzeige stellt eine Schätzung der VRU-Stabilität bereit. Dieses DF enthält eine Stabilitätsänderung des Ego-VRU für einen Zeitraum. Falls vorhanden, stellt das DF StabilitätÄnderungAnzeige Informationen über die VRU-Stabilität bereit. Es wird in der geschätzten Wahrscheinlichkeit eines vollständigen VRU-Stabilitätsverlusts ausgedrückt, der zu einem VRU-Ausstieg aus seinem VRU-Fahrzeug führen kann. Das DE - StabilitätVerlustWahrscheinlichkeit oder vruStabilitätVerlustWahrscheinlichkeit gibt die Wahrscheinlichkeitsangabe über den Stabilitätsverlust des Ego-VRU. Der Stabilitätsverlust wird für einen Zeitraum AktionDeltaZeit projiziert. Das DE AktionDeltaZeit gibt die Zeitdauer an. Die Beschreibung des Containers ist in Klausel B.7 von [TS103300-3] bereitgestellt und die entsprechenden DFs und DEs, die zu [TS102894-2] hinzugefügt werden sollen, sind in Klausel F7.15 von [TS103300-3] bereitgestellt.
  • Das DE vruStabilitätVerlustWahrscheinlichkeit stellt eine Schätzung der VRU-Stabilitätswahrscheinlichkeit bereit. Wenn vorhanden, liefert dieses DE die Stabilitätsverlustwahrscheinlichkeit des VRU in den Schritten von 2% mit 0 für volle Stabilität und 100% Stabilitätsverlust. Dieses DE wird wie in Klausel F.7.16 von [TS103300-3] spezifiziert dargestellt.
  • Tabelle 1.5.4-38 zeigt die Parameter für eine VAM-Erzeugung. Die Parameter können auf einzelnen Vorrichtungen oder systemweit eingestellt werden und können von externen Bedingungen abhängen oder von diesen unabhängig sein. Tabelle 1.5.4-38: Parameter für VAM-Erzeugung
    Parameter Typ Bedeutung Empfohlener Wert
    T_ErzVamMin Zeit in ms Die minimale Zeit, die zwischen dem Beginn aufeinanderfolgender VAM-Erzeugungsereignisse verstrichen ist. 100
    Für einen VRU-LF-Container sind 2 000 ms zu verwenden
    T_ErzVamMax Zeit in ms Die maximale Zeit, die zwischen dem Beginn aufeinanderfolgender VAM-Erzeugungsereignisse verstrichen ist. 5000
    T_ZusammenstellungVAM Zeit in ms Zeit, die zum Zusammenstellen eines VAM-Pakets in der Facilities-Schicht zugeteilt ist 50
  • Die Parameter in Tabelle 1.5.4-39 regeln das Auslösen der VAM-Erzeugung. Die Parameter können auf einzelnen Vorrichtungen oder systemweit eingestellt werden und können von externen Bedingungen abhängen oder von diesen unabhängig sein. Tabelle 1.5.4-39: Parameter zum Auslösen der VAM-Erzeugung
    Parameter Typ Bedeutung Empfohlener Bereich
    minReferenzPunktPositionÄnderungSchwelle Abstand (in m) Minimaler euklidischer absoluter Abstand zwischen der aktuellen geschätzten Position des Referenzpunkts des VRU (oder des VRU-Clusters) und der geschätzten Position des Referenzpunkts, der zuletzt in einer VAM enthalten ist, um eine VAM-Erzeugung basierend auf einer Positionsänderung des VRU (oder VRU-Clusters) auszulösen. Dies schränkt das Auslösen einer VAM-Erzeugung ein. 4
    minBodenGeschwindigkeitÄnderungSchwelle Geschwindigkeit (In m/s) Minimale Differenz zwischen der aktuellen geschätzten Bodengeschwindigkeit des Referenzpunkts des VRU (oder des VRU-Clusters) und der geschätzten absoluten Geschwindigkeit des Referenzpunkts des VRU (oder des VRU-Clusters), der zuletzt in einer VAM enthalten ist, um eine VAM-Erzeugung basierend auf einer Geschwindigkeitsänderung des VRU (oder VRU-Clusters) auszulösen. Dies schränkt das Auslösen einer VAM-Erzeugung ein. ±0,5
    minBodenGeschwindigkeitsvektorOrientierungÄnderungSchwelle Orientierung (in Grad) Minimale Differenz zwischen der Orientierung des Vektors des aktuellen geschätzten Bodengeschwindigkeitsvektors des Referenzpunkts des VRU (oder des VRU-Clusters) und der geschätzten Orientierung des Vektors des Bodengeschwindigkeitsvektors des Referenzpunkts des VRU (oder des VRU-Clusters), der zuletzt in einer VAM enthalten ist, um eine VAM-Erzeugung basierend auf einer Orientierungsänderung des Vektors des Bodengeschwindigkeitsvektors des VRU (oder des VRU-Clusters) auszulösen. Dies schränkt das Auslösen einer VAM-Erzeugung ein. ±4
    minTrajektorieAbfangWahrschÄnderungSchwelle Wahrscheinlichkeit (in Prozent) Minimale Differenz zwischen der aktuellen geschätzten Trajektorieabfangwahrscheinlich keit des VRU (oder VRU-Clusters) mit Fahrzeug(en) oder anderen VRU(s) und der geschätzten Kollisionswahrscheinlichkeit des VRU (oder VRU-Clusters) mit Fahrzeug(en) oder anderen VRU(s), die zuletzt in einer VAM gemeldet werden, um eine VAM-Erzeugung basierend auf einer Trajektorienabfangwahrscheinlic hkeitsänderung des VRU (oder des VRU-Clusters) auszulösen. Dies schränkt das Auslösen einer VAM-Erzeugung ein. 10
    anzÜbersprungVamsFürRedundanzAbschwächung Anzahl von Wiederholun gen Falls Bedingungen zur Redundanzabschwächung erfüllt sind, soll eine Ursprungs-VRU-ITS-S eine aktuelle individuelle VAM anzÜbersprungVamsFürRedund anzAbschwächung-mal überspringen. [2 bis 10]
    minClusterAbstandÄnderungSchwelle Länge (in m) Minimale Differenz zwischen dem aktuellen geschätzten Abstand von der VRU-ClusterBegrenzung und dem geschätzten Abstand basierend auf der letzten übertragenen VAM, um eine VAM-Erzeugung basierend auf einer VRU-Clusterbegrenzungsrahmen-Größenänderung auszulösen. Dies schränkt das Auslösen einer VAM-Erzeugung ein. 2
    minimalSicherSeitenAbstand (MSLaD) Länge (in m) Minimaler sicherer Seitenabstand zwischen dem Ego-VRU und einem anderen Verkehrsteilnehmer (ausgestattet oder nicht). Dieser hängt von den Ego-VRU-Profilen, ihren Geschwindigkeiten und den Profilen der anderen Verkehrsteilnehmer und ihren Geschwindigkeiten ab. Der Maximalwert zwischen 2 m und dem Seitenabstand, um den sich der Ego-VRU in T_ErzVarnMax Sekunden bewegen könnte, wird als MSLaD gesetzt. A = Seitenabstand, um den sich der Ego-VRU in T_ErzVarnMax Sekunden bewegen könnte Max [2, A]
    minimalSicherLängsAbstand (MSLoD) Länge (in m) Minimaler sicherer Längsabstand zwischen dem Ego-VRU und einem anderen Verkehrsteilnehmer (ausgestattet oder nicht). Dieser hängt von den Ego-VRU-Profilen, ihren Geschwindigkeiten und den Profilen der anderen Verkehrsteilnehmer und ihren Geschwindigkeiten ab. B = Längsabstand, um den sich der Ego-VRU in T_ErzVarnMax Sekunden bewegen könnte. B
    minimalSicherVertikalAbstand (MSVD) Länge (in m) Minimaler sicherer Vertikalabstand zwischen dem Ego-VRU und einem anderen Verkehrsteilnehmer (ausgestattet oder nicht). Eine Überführung weist normalerweise einen Abstand von 5 m auf. 5
  • Einige neue DEs und DFs in vruHochFrequenzContainer beinhalten das DE VruUmgebung und das DE VruBewegungSteuerung, die durch Tabelle 1.5.4-40 und Tabelle 1.5.4-41 ausführlicher beschrieben werden. Tabelle 1.5.4-40: DE_VruUmgebung
    Beschreibender Name VruUmgebung
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0038
    Definition Codierter Wert der möglichen VRU-Umgebungsbedingungen. Die VRU-Umgebungsbedingungen werden wie folgt beschrieben:  Nicht verfügbar (0): falls Informationen über den Umgebungstyp nicht verfügbar sind,  Kreuzung (1),  ZebraStreifen (2),  Fußgängerweg (3),  FahrzeugStraße (4),  Wert 6-255: für künftige Verwendung reserviert. Wert 255 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen.
    Einheit N/A
    Kategorie VRU-Informationen
    Tabelle 1.5.4-41: DE_VruBewesunsSteuerung
    Beschreibender Name VruBewegungSteuerung
    Kennung DatenTyp XX
    ASN.1-Darstellung
    Figure DE112020006966T5_0039
    Definition Codierter Wert der möglichen VruBewegungSteuerung Die VruBewegungSteuerung wird wie folgt beschrieben:  nicht verfügbar (0): falls Informationen über die VruBewegungSteuerung nicht verfügbar sind,  Bremsen (1),  HartBremsen (2),  StoppPedalbetätigung (3),  BremsenUndStoppPedalbetätigung (4),  HartBremsenUndStoppPedalbetätigung (5),  keineReaktion (6),  Wert 5-255: für künftige Verwendung reserviert. Wert 255 wird auf „max“ gesetzt, um die Größe des codierten Feldes zu begrenzen.
    Einheit N/A
    Kategorie VRU-Informationen
  • 1.6. PARAMETRISIERUNG DER GITTERDARSTELLUNG
  • In einigen Ausführungsformen wird eine rechteckige Form für das DCROM-Gitter als Basis und feste Form für ein einzelnes Gitter angenommen. Darüber hinaus beinhalten Ausführungsformen die Parametrisierung des Gitters hinsichtlich der folgenden Konfigurationsparameter: Referenzpunkt: Spezifiziert durch den Standort der Ursprungs-ITS-S für den Gesamtbereich; Gittergröße: individuelle Gittergröße, spezifiziert durch Länge und Breite des Gitters unter Annahme eines rechteckigen Gitters (z.B. ist die Basis 30cm x 30cm); Gesamtanzahl an Stufen: Mindestens 1 Stufe bis maximal 2 Stufen. Die erste Stufe umfasst 8 Gitterplatten, die die Ego-ITS-S-Gitterplatte umgeben, die zweite Stufe umfasst 16 zusätzliche Gitterplatten, die 8 Stufe-1-Gitterplatten umgeben, was somit zu insgesamt 25 Gitterplatten einschließlich der Ego-ITS-S-Gitterplatte für die zweistufige Darstellung führt (vgl. z.B. 5d); Relativer Gitterstandort: Gemessen relativ zum Referenzpunkt, wie zuvor spezifiziert; und/oder Belegungsstatus: Belegt oder frei, wie zuvor spezifiziert.
  • 1.7. AUSFÜHRUNGSFORMEN FÜR UNTERSCHIEDLICHE TYPEN VON VAM-USPRUNGS-ITS-SS
  • Wie in der VRU-Clusterspezifikation in Klausel 5.4.1 von [TS103300-3] definiert, unterstützt der VRU-Basisdienst (VBS) VRU-Clusteroperationen, wobei eine Anzahl von VRU-ITS-S 117 unter der Verwaltung eines Clusterkopfes (CH) oder Clusterführers (CL) gruppiert werden kann, um eine Ressourcennutzung (z.B. Spektrumressourcen und Verarbeitungsressourcen) in der ITS-S zu optimieren.
  • Unter den möglichen Optionen für die VAM-Usprungs-ITS-S mit den OSI- und GLI-Feldern innerhalb der VAM kann in verschiedenen Ausführungsformen der Ego-VRU 116/117, der einer der LC-VRUs 116/117 oder der HC-VRUs 116/117 sein kann, in Abhängigkeit vom Typ der Ursprungs-ITS-S in den folgenden Optionen/Modi arbeiten:
  • Modus-1: Die ITS-S, von der die VAM mit GLI und OSI stammt, ist ein eigenständiger VRU 116/117, der nicht Teil eines Clusters ist (wie der Standardmodus, der bisher in allen vorherigen Abschnitten angenommen wurde).
  • Modus-2 : Die ITS-S, von der die VAM mit GLI und OSI stammt, ist eine nahe gelegene R-ITS-S 130 oder V-ITS-S 110.
  • Modus-3: Cluster-VRU 116/117 als Element(e) von Clustern, die durch einen CL verwaltet werden. Des Weiteren kann der CL einer der folgenden ITS-S-Typen sein:
  • Modus-2(a): Die Clusterführer-ITS-S, von der eine VAM mit GLI und OSI stammt, ist eine VRU-ITS-S 117 (entweder LC-VRU 116/117 oder HC-VRU 116/117), wie in 7a gezeigt.
  • Modus-2(b): Die Clusterführer-ITS-S 117, von der eine VAM mit GLI und OSI stammt, ist eine R-ITS-S 130, wie in 7b gezeigt.
  • Modus-2(c): Die Clusterfuhrer-ITS-S, von der eine VAM mit GLI und OSI stammt, ist eine V-ITS-S 110 (insbesondere geeignet, wenn der VRU dem Profil 3 (Hochgeschwindigkeits-Motorräder) entspricht, wie in 7c gezeigt.
  • Die 7a, 7b und 7c zeigen Beispiele für ein auf Clusterbetrieb basierendes Beispiel für unterschiedliche Typen von VAM-Ursprungs-ITS-Ss. 7a zeigt ein Beispiel 7a00, wobei eine VRU-ITS-S 117 die Clusterführer-Ursprungs-ITS-S für VAM mit GLI und OSI ist. In dem Beispiel von 7a ist der Clusterführer ein LC-VRU 116/117, dieses Beispiel gilt jedoch auch für einen HC-VRU 116/117, der als Clusterführer agiert. 7b zeigt ein Beispiel 7b00, wobei eine R-ITS-S 130 als die Clusterführer-Ursprungs-ITS-S für VAM mit GLI und OSI fungiert. 7c zeigt ein Beispiel 7c00, wobei die V-ITS-S 110 die Clusterführer-Ursprungs-ITS-S für VAM mit GLI und OSI ist.
  • Zusätzlich zum Vorstehenden können verschiedene Arten von Ursprungs-ITS-Ss zum Erstellen, Aktualisieren und Warten der DROM (z.B. der DCROM) von den ITS-S-Vorrichtungsfähigkeiten, Rechenkomplexität, verfügbaren Klassen von Sensoren und/oder anderen ähnlichen Parametern/Bedingungen abhängen.
  • Eine erste Ausführungsform beinhaltet einen eigenständigen VRU 116/117 als VAM-Ursprungs-ITS-S. VRU 116/117-Typen wie etwa des Profils 3 können in der Lage sein, DROM basierend auf GPU, Gyroskopen, Kameras und anderen Sensordaten, die Ihnen zur Verfügung stehen, zu erzeugen. Selbst in Abwesenheit hochentwickelter Sensoren kann eine VRU-ITS-S 117 jedoch immer noch Basisinformationen teilen, wie etwa den VAM-Basis-Container, einschließlich des Typs der Ursprungs-ITS-S und der neuesten geografischen Position der Ursprungs-ITS-S, wie sie durch den VBS bei der VAM-Erzeugung erhalten wird. Beim Empfangen solcher Informationen an einem anderen eigenständigen Ego-VRU 116/117 kann sie in der Lage sein, eine DROM mit geringer Komplexität periodisch zu erzeugen, beizubehalten und zu teilen (mit anderen ITS-Ss). Die anfängliche Qualität von DROM hängt von der Qualität und Verfügbarkeit der Sensoren und der Rechenfähigkeit am eigenständigen VRU 116/117 ab und kann im Laufe der Zeit über einen VAM-Austausch mit DROM-DF und zugehörigen DEs mit den benachbarten ITS-Ss verbessert werden. Eine beispielhafte Darstellung für diesen Fall ist in 8 gezeigt, die eine beispielhafte Gitterbelegungskarten-Ausführungsform für den Ego-VRU 116/117 als Ursprungs-ITS-S zeigt.
  • Eine zweite Ausführungsform beinhaltet einen Clusterführer-VRU 116/117 als VAM-Ursprungs-ITS-S: Dieser Fall tritt auf, wenn ein eigenständiger VRU 116/117 als Teil eines Clusters arbeiten kann, der durch einen Clusterführer verwaltet wird. In diesem Fall können die Clusterführer-VRUs 116/117 im Vergleich zu den eigenständigen VRUs 116/117 vollständigere Erste-Hand-Informationen und Wahrnehmung der Element-VRUs 116/117 innerhalb ihres lokalen Clusters besitzen und können somit in der Lage sein, DROM über ihre Ursprungs-VAM zu erzeugen und mit anderen Verkehrsteilnehmern zu teilen.
  • Eine dritte Ausführungsform beinhaltet einen RSE als VAM, der ITS-S erzeugt: Nicht-VRU-ITS-Ss, wie etwa die nahe gelegene R-ITS-S 130 mit hochentwickelten Sensoren oder Wahrnehmungsfähigkeiten, können zudem in der Lage sein, DROM zu erstellen, aufrechtzuerhalten und mit dem Ego-VRU 116/117 und den nahe gelegenen VRUs 116/117 zu teilen, wie in 9 gezeigt. 9 zeigt eine beispielhafte Gitterbelegungskarten-Ausführungsform für RSE als Ursprungs-ITS-S. Da die VRU-ITS-S 117 jedoch möglicherweise keine verallgemeinerte und rechenintensive DROM von der R-ITS-S 130 empfangen muss (aufgrund eines nicht zugehörigen Bereichs/einer nicht zugehörigen Umgebung, aufgrund von Vorrichtungsrechenressourcenbeschränkungen sowie Kommunikationsressourcenbeschränkungen), wird eine abgeschnittene oder partielle DROM (aus den größeren DROM-Daten, die an der R-ITS-S 130 verfügbar sein können) geteilt, die nur für die betrachtete spezifische eigenständige VRU-ITS-S 117 oder die Clusterführer-VRU-ITS-S 117 relevant ist.
  • Eine vierte Ausführungsform beinhaltet ein Fahrzeug als VAM-Ursprungs-ITS-S: Nicht-VRU-ITS-Ss, wie etwa die nahe gelegene V-ITS-S 110 mit hochentwickelten Sensoren oder Wahrnehmungsfähigkeiten, können zudem in der Lage sein, DROM zu erstellen, aufrechtzuerhalten und mit dem Ego-VRU 116/117 und den nahe gelegenen VRUs 116/117 zu teilen. Ähnlich dem Fall der R-ITS-S 130 als VAM-Ursprungs-ITS-S wird eine abgeschnittene oder partielle DROM (aus den größeren DROM-Daten, die an der V-ITS-S 110 verfügbar sein können) geteilt, die nur für die betrachtete spezifische eigenständige VRU-ITS-S 117 oder die Clusterführer-VRU-ITS-S 117 relevant ist.
  • 1.8. NICHT-VRU-ITS-S-VAM-VERTEILUNG
  • Die VAM stammt von einer VRU-ITS-S 117, die das Bewusstsein für nicht-ausgestattete VRUs 116 nicht wirksam adressiert. Hierbei sind nicht-ausgestattete VRUs 116 solche VRUs 116 ohne jegliche ITS-S für Tx, Rx oder Tx/Rx (z.B. VRUs 116, die keine VRU-Tx, VRU-Rx oder VRU-St sind; vgl. z.B. Tabelle 0-1). In vielen verkehrsreichen Situationen, wie etwa einer stark frequentierten Kreuzung, einem Zebrastreifen, einem Schul-Absetz- und -abholbereich, öffentlichen Bushaltestellen, Schulbushaltestellen, einer stark frequentierten Kreuzung in der Nähe eines Einkaufszentrums, einem Baustellenarbeitsbereich und anderen, sind sowohl ausgestattete als auch nicht-ausgestattete VRUs 116 vorhanden. Clusterbildung und -verwaltung durch eine einzelne VRU-ITS-S 117 (als Clusterführer oder Clusterkopf) ist durch die verfügbaren Ressourcen (z.B. Berechnung, Kommunikation, Erfassung) begrenzt. Ein durch einen einzelnen VRU 116/117 gebildeter VRU-Cluster kann keine nicht-ausgestatteten VRUs 116 im Cluster aufnehmen. In solchen Fällen sollten die VRUs 116/117 in der Lage sein, die Kollektivwahrnehmungsnachricht (CPM) zu decodieren und zu interpretieren, um das volle Umgebungsbewusstsein für die Sicherheit zu erhalten. Zu diesem Zweck kann die Infrastruktur (z.B. R-ITS-Ss 130) in solchen Szenarien eine Rolle beim Detektieren (z.B. über Sensoren) potentieller VRUs 116/117 und Gruppieren in Clustern spielen, einschließlich sowohl ausgestatteter VRUs 117 als auch nicht-ausgestatteter VRUs 116. Zum Beispiel kann eine statische R-ITS-S 130 an einer stark frequentierten Kreuzung, einem Zebrastreifen, einem Schul-Absetz- und -abholbereich, einer stark frequentierten Kreuzung in der Nähe eines Einkaufszentrums und dergleichen installiert sein, während eine mobile R-ITS-S 130 auf designierten Fahrzeugen (z.B. Schulbus, Stadtbus, Dienstfahrzeug, Drohnen/Roboter usw.) installiert sein kann, um zu diesem Zweck als Infrastruktur/R-ITS-S 130 an öffentlichen Bushaltestellen, Schulbushaltestellen, Baustellenarbeitsbereichen usw. zu dienen.
  • Bestehende VAMs ermöglichen ein Teilen von Informationen entweder eines Ego-VRU 116/117 oder eines VRU-Clusters. Im Falle einer Nicht-VRU-ITS-Ss- (z.B. R-ITS-Ss 130 oder designierten V-ITS-Ss 110) VAM kann die Nicht-VRU-ITS-S jedoch in der Lage sein, einen oder mehrere einzelne VRUs 116/117 und/oder einen oder mehrere VRU-Cluster im Sichtfeld (FOV) zu detektieren, die in der VAM gemeldet werden müssen.
  • In einigen Ausführungsformen kann das existierende VAM-Format modifiziert werden, um Nicht-VRU-ITS-S-VAMs zu ermöglichen. In einer Nicht-VRU-ITS-S-VAM werden die VRU-Bewusstseinsinhalte eines oder mehrerer VRUs 116/117 und/oder eines oder mehrerer VRU-Cluster übertragen. Zusätzlich werden ausführliche Mechanismen für Nicht-VRU-ITS-S-unterstützte VRU-Clusterbildung einschließlich sowohl ausgestatteter VRUs 116/117 als auch nicht-ausgestatteter VRUs 116 berücksichtigt, wobei eine Nicht-VRU-ITS-S (z.B. R-ITS-S 130) als Clusterführer fungiert und Nicht-VRU-ITS-S-VAMs überträgt.
  • Eine individuelle Meldung aller detektierten VRUs 116/117 und/oder VRU-Cluster einzeln durch Nicht-VRU-ITS-SS kann in bestimmten Szenarien ineffizient sein, wie etwa bei Vorhandensein einer großen Anzahl von VRUs 116/117 oder überlappender Ansicht von VRUs oder Verdeckung von VRUs 116/117 im FOV von Sensoren an der Ursprungs-Nicht-VRU-ITS-S. Ein solches Melden über existierende DFs/DEs in der VAM im Fall einer großen Anzahl von wahrgenommenen VRUs 116/117 und/oder VRU-Clustern kann einen großen Kommunikationsaufwand und eine erhöhte Verzögerung beim Melden aller VRUs 116/117 und/oder VRU-Cluster erfordern. Die Nicht-VRU-ITS-S muss möglicherweise eine Selbstzugangssteuerung, Redundanzabschwächung oder eigenständige Segmentierung verwenden, um die Überlastung in den Zugangsschichten zu verwalten. Die eigenständigen Segmente sind unabhängige VAM-Nachrichten und können in jedem folgenden VAM-Erzeugungsereignis übertragen werden.
  • Daher könnte eine belegungsgitterbasierte bandbreiteneffiziente Leicht-VRU-Bewusstmachungsnachricht unterstützt werden, um bei einer großen Anzahl detektierter VRUs 116/117 und/oder VRU-Cluster oder einer überlappenden Ansicht von VRUs 116/117 oder einer Verdeckung von VRUs 116/117 im FOV zu helfen. Der Wert jeder Zelle kann Informationen angeben, wie etwa Vorhandensein/Abwesenheit eines VRU, Vorhandensein/Abwesenheit eines VRU-Clusters und sogar Vorhandensein/Abwesenheit von Nicht-VRUs oder anderen Objekten in der Umgebung. Darüber hinaus besitzen nicht-VRU-ITS-Ss wie RSE eine bessere Wahrnehmung der Umgebung (über hochentwickelte Sensoren) durch einen Kollektivwahrnehmungsdienst (CPS) durch Austausch von Kollektivwahrnehmungsnachrichten (CPMs) (vgl. z.B. [EN302890-2]). Da erwartet wird, dass VRUs nicht in der Lage sind, CPMs abzuhören und die Umgebung wahrzunehmen, kann eine Nicht-VRU-ITS-S vom CPS erhaltene leichtgewichtige Umgebungsinformationen mit VRUs 116/117 über VAMs anstatt durch Hinzufügen entsprechender DFs und DEs teilen.
  • Nicht-VRU-ITS-Ss, wie etwa die nahe gelegene R-ITS-S 130 mit hochentwickelten Sensoren oder Wahrnehmungsfähigkeiten, können zudem in der Lage sein, eine dynamische Straßenbelegungskarte zu erstellen, aufrechtzuerhalten und mit dem Ego-VRU und den nahegelegenen VRUs 116/117 zu teilen, wie in den 8 und/oder 9 gezeigt wird. Die dynamische Straßenbelegungskarte ist ein vordefinierter Gitterbereich eines Straßensegments, der durch boolesche Werte für die Belegung dargestellt wird, begleitet von entsprechenden Konfidenzwerten. Da Nicht-VRUs, wie etwa eine nahe gelegene R-ITS-S 130, eine bessere globale Ansicht des Straßensegments aufweisen können, kann sie für die Verwaltung von VRU-Clusterbildung und die Verteilung von Multi-VRU-VAMs und Multi-VRU-Cluster-VAMs verwendet werden. Des Weiteren könnten die genaue Umgebungswahrnehmung, Leistungsverfügbarkeit und Rechenfähigkeit der Nicht-VRU-ITS-S für präzises Umgebungsbewusstsein und Positionsbestimmung der VRUs und Fahrzeuge genutzt werden.
  • 8 und 9 ITS-S zeigen Gitter 800 bzw. 900 mit jeweils einer rechteckigen Form, die als Grundlinie mit einer festen Form für ein einzelnes Gitter 800, 900 angenommen wird. In einigen Ausführungsformen kann eine Parametrisierung des Gitters hinsichtlich der folgenden Konfigurationsparameter verwendet werden
  • Referenzpunkt der Gitterkarte: Der Referenzpunkt der Gitterkarte wird durch den Standort der Ursprungs-ITS-S für den Gesamtbereich spezifiziert. Zum Beispiel beinhaltet die zentrale Zelle in 8 den VRU 116/117 als Ursprungs-ITS-S und beinhaltet die zentrale Zelle in 9 die R-ITS-S 130 als Ursprungs-ITS-S.
  • Gitterplatten-/-zellengröße: Die Gitterplatten-/-zellengröße ist die Größe (Abmessungen) und/oder Form der einzelnen Zellen der Gitterkarte. Bei der Gitterplatten-/-zellengröße kann es sich um vordefinierte globale Gitterplatten-/-zellengrößen handeln, die durch die Länge und Breite des Gitters unter Annahme eines rechteckigen Gitters spezifiziert sind und die Granularität der Zellen widerspiegeln. In einigen Implementierungen können die Zellen basierend auf Gesamtabmessungen der Gitterkarte gleichmäßig aufgeteilt sein oder können einzelne Zellenabmessungen angegeben/konfiguriert sein.
  • Startposition der Zelle: Die Startposition der Zelle ist eine Startzelle des Belegungsgitters als Referenzgitter (z.B. P11 , wie in 5e gezeigt). Die anderen Gitterplatten-/-zellenpositionen können basierend auf Versatz gegenüber der Referenzgitterplatte/-zelle gekennzeichnet werden.
  • Bitmap der Belegungswerte: 5e zeigt eine beispielhafte Bitmap 500e, wobei die Belegungswerte boolesche Werte sein können, die die Belegung jeder Zelle im Gitter darstellen. Andere Werte, Zeichen, Ketten usw. können verwendet werden, um unterschiedliche Belegungs- oder Wahrscheinlichkeitsniveaus einzelner Zellen darzustellen.
  • Konfidenzwerte: Die Konfidenzwerte sind Konfidenzwerte, die jeder Zelle im Gitter entsprechen (der Bitmap zugeordnet). Zusätzlich zu den zuvor genannten Parametern ist das Abbildungsmuster des Belegungsgitters in eine Bitmap in 5e gezeigt.
  • In einigen Fällen muss die nicht-VRU-ITS-S (z.B. statische R-ITS-S 130 oder mobile R-ITS-S 130 an designierten Fahrzeugen wie Schulbus, Baustellenfahrzeug, Polizeiautos) möglicherweise eine VAM (z.B. Infrastruktur-VAM) speziell übertragen, wenn nicht-ausgestattete VRUs 116 detektiert werden. Eine solche Infrastruktur-VAM kann zum Melden entweder einzelner detektierter VRUs oder Cluster von VRUs übertragen werden. Eine Nicht-VRU-ITS-S kann auswählen, eine Infrastruktur-VAM, die einzelne detektierte VRUs 116/117 und Cluster von VRUs 116/117 in derselben Infrastruktur-VAM meldet, zu übertragen, indem null oder mehr einzelne detektierte VRUs 116/117 und null oder mehr Cluster von VRUs 116/117 in derselben Infrastruktur-VAM aufgenommen werden.
  • Für eine VAM-Übertragungsverwaltung durch VBS an einer Nicht-VRU-ITS-S sollte, falls eine Nicht-VRU-ITS-S nicht bereits aufeinanderfolgende (wie etwa periodische) Infrastruktur-VAMs überträgt und die Infrastruktur-VAM-Übertragung keinen Redundanzabschwächungstechniken unterliegt, beim ersten Mal die Infrastruktur-VAM unmittelbar oder zum frühesten Zeitpunkt für die Übertragung erzeugt werden, wenn eine der folgenden Bedingungen erfüllt ist:
    • (1) Mindestens ein VRU 116/117 wird von der Ursprungs-Nicht-VRU-ITS-S detektiert, wobei der detektierte VRU keine VAM für mindestens die T_ErzVamMax -Dauer übertragen hat; der wahrgenommene Standort des detektierten VRU fällt nicht in einen Begrenzungsrahmen des Clusters, der in einer beliebigen VRU-Cluster-VAMs spezifiziert ist, die von der Ursprungs-Nicht-VRU-ITS-S während der letzten T _ErzVamMax -Dauer empfangen wird; und die erkannte VRU ist nicht in Infrastruktur-VAMs enthalten, die von der Ursprungs-VRU-ITS-S während der letzten T_ErzVamMax-Dauer empfangen wird.
    • (2) Mindestens ein VRU-Cluster wird von der Ursprungs-Nicht-VRU-ITS-S detektiert, wobei der Clusterkopf des detektierten VRU-Clusters keine VRU-Cluster-VAM für mindestens die T_ ErzVamMax-Dauer übertragen hat; der wahrgenommene Begrenzungsrahmen des detektierten VRU-Clusters überlappt sich um nicht mehr als eine vordefinierte SchwellenwertmaxInterVRUClusterÜberlappungInfrastrukturVAM mit dem Begrenzungsrahmen von VRU-Clustern, die in VRU-Cluster-VAMs oder Infrastruktur-VAMs spezifiziert sind, die durch die Ursprungs-Nicht-VRU-ITS-S während der letzten T ErzVamMax-Dauer empfangen werden.
  • Aufeinanderfolgende Infrastruktur-VAM-Übertragung ist abhängig von Bedingungen wie vorliegend beschrieben. Aufeinanderfolgende Infrastruktur-VAM-Erzeugungsereignisse sollten in einem Intervall gleich oder größer als T_ErzVam erfolgen. Eine Infrastruktur-VAM sollte zur Übertragung als Teil eines Generierungsereignisses erzeugt werden, falls die Ursprungs-Nicht-VRU-ITS-S mindestens einen ausgewählten wahrgenommenen VRU oder VRU-Cluster aufweist, der in der aktuellen Infrastruktur-VAM enthalten sein soll.
  • Zur Verwaltung der Einbeziehung wahrgenommener VRUs in einer aktuellen Nicht-VRU-ITS-S-VAM sollten die wahrgenommenen VRUs 116/117, die für die Aufnahme in der aktuellen Infrastruktur-VAM berücksichtigt werden, alle diese Bedingungen erfüllen: (1) Die Ursprungs-Nicht-VRU-ITS-S hat keine VAM von der detektierten VRU für mindestens die T_ErzVamMax-Dauer empfangen; (2) der wahrgenommene Standort des detektierten VRU fällt nicht in einen Begrenzungsrahmen von VRU-Clustern, die in VRU-Cluster-VAMs spezifiziert sind, die durch die Ursprungs-VRU-ITS-S während der letzten T_ErzVamMax-Dauer empfangen wird; (3) der detektierte VRU ist nicht in Infrastruktur-VAMs enthalten, die durch die Ursprungs-Nicht-VRU-ITS-S während der letzten T_ErzVamMax-Dauer empfangen wird; und (4) die detektierte VRU fällt nicht in den Begrenzungsrahmen von VRU-Clustern, die von der Ursprungs-Nicht-VRU-ITS-S in die aktuelle Infrastruktur-VAM aufgenommen werden sollen.
  • Ein VRU, der mit einem ausreichenden Konfidenzniveau wahrgenommen wird, das obige Bedingungen erfüllt und nicht Redundanzabschwächungstechniken unterliegt, sollte zur Aufnahme in das aktuelle VAM-Erzeugungsereignis ausgewählt werden, falls der wahrgenommene VRU zusätzlich eine der folgenden Bedingungen erfüllt:
    • (1) der VRU wurde erstmals durch die Ursprungs-VRU-ITS-S nach dem letzten Infrastruktur-VAM-Erzeugungsereignis detektiert.
    • (2) die Zeit, die seit dem letzten Mal verstrichen ist, als der wahrgenommene VRU in einer Infrastruktur-VAM enthalten war, überschreitet T_ErzVamMax.
    • (3) der euklidische absolute Abstand zwischen der aktuellen geschätzten Position des Referenzpunkts für den wahrgenommenen VRU und der geschätzten Position des Referenzpunkts für den wahrgenommenen VRU, der zuletzt in der Infrastruktur-VAM enthalten ist, überschreitetminReferenzPunktPositionÄnderungSchwelle.
    • (4) die Differenz zwischen der aktuellen geschätzten Bodengeschwindigkeit des Referenzpunkts für den wahrgenommenen VRU und der geschätzten absoluten Geschwindigkeit des Referenzpunkts für den wahrgenommenen VRU, der zuletzt in der Infrastruktur-VAM enthalten ist, überschreitet minBodenGeschwindigkeitÄnderungSchwelle.
    • (5) die Differenz zwischen der Orientierung des Vektors des aktuellen geschätzten Bodengeschwindigkeitsvektors des Referenzpunkts für den wahrgenommenen VRU und der geschätzten Orientierung des Vektors des Bodengeschwindigkeitsvektors des Referenzpunkts für den wahrgenommenen VRU, der zuletzt in der Infrastruktur-VAM enthalten ist, überschreitet minBodenGeschwindigkeitsvektorOrientierungÄnderungSchwelle.
    • (6) Die Infrastruktur oder die Fahrzeuge haben bestimmt, dass es eine Differenz zwischen der aktuellen geschätzten Trajektorieabfangangabe mit dem/den Fahrzeug(en) oder anderen VRU(s) und der Trajektorieabfangangabe mit dem/den Fahrzeug(en) oder anderen VRU(s) gibt, die zuletzt in einer Infrastruktur-VAM gemeldet werden.
    • (7) Ein oder mehrere neue Fahrzeuge oder andere VRUs 116/117 (z.B. VRU-Profil 3 - Motorradfahrer) haben nach der zuletzt übertragenen VAM gleichzeitig die folgenden Bedingungen erfüllt. Die Bedingungen sind: seitliche Annäherung näher als minimaler sicherer Seitenabstand (MSLaD), Längsannäherung näher als minimaler sicherer Längsabstand (MSLoD) und Vertikalannäherung näher als minimaler sicherer Vertikalabstand (MSVD) an den VRU nach der zuletzt übertragenen Infrastruktur-VAM
  • Zur Verwaltung der Einbindung wahrgenommener VRU-Cluster in einer aktuellen Nicht-VRU-ITS-S-VAM sollten die wahrgenommenen VRU-Cluster, die für die Aufnahme in die aktuelle Infrastruktur-VAM berücksichtigt werden, alle der folgenden Bedingungen erfüllen: Der wahrgenommene Begrenzungsrahmen des detektierten VRU-Clusters überlappt sich um nicht mehr als maxInterVRUClusterÜberlappunglnfrastrukturVAM mit dem Begrenzungsrahmen des VRU-Clusters, der in einer der VRU-Cluster-VAMs oder der Infrastruktur-VAMs spezifiziert ist, die durch die Ursprungs-Nicht-VRU-ITS-S während der letzten T ErzVamMax-Dauer empfangen werden.
  • Ein VRU-Cluster, der mit einem ausreichenden Konfidenzniveau wahrgenommen wird, das obige Bedingungen erfüllt und nicht Redundanzabschwächungstechniken unterliegt, sollte zur Aufnahme in die aktuelle VAM-Erzeugung ausgewählt werden, falls der wahrgenommene VRU-Cluster zusätzlich eine der folgenden Bedingungen erfüllt:
    • (1) der VRU-Cluster wurde erstmals durch die Ursprungs-VRU-ITS-S nach dem letzten Infrastruktur-VAM-Erzeugungsereignis detektiert.
    • (2) die Zeit, die seit dem letzten Mal verstrichen ist, als der wahrgenommene VRU-Cluster in einer Infrastruktur-VAM enthalten war, überschreitet T_ErzVamMax.
    • (3) der euklidische absolute Abstand zwischen der aktuellen geschätzten Position des Referenzpunkts des wahrgenommenen VRU-Clusters und der geschätzten Position des Referenzpunkts des wahrgenommenen VRU-Clusters, der zuletzt in einer Infrastruktur-VAM enthalten ist, überschreitetminReferenzPunktPositionÄnderungSchwelle.
    • (4) die Differenz zwischen der aktuellen geschätzten Breite des wahrgenommenen VRU-Clusters und der geschätzten Breite des wahrgenommenen VRU-Clusters, die in der zuletzt übertragenen VAM enthalten ist, überschreitet minClusterBreiteÄnderungSchwelle.
    • (5) die Differenz zwischen der aktuellen geschätzten Länge des wahrgenommenen VRU-Clusters und der geschätzten Länge des wahrgenommenen VRU-Clusters, die in der zuletzt übertragenen VAM enthalten ist, überschreitet minClusterLängeÄnderungSchwelle.
    • (6) die Differenz zwischen der aktuellen geschätzten Bodengeschwindigkeit des Referenzpunkts des wahrgenommenen VRU-Clusters und der geschätzten absoluten Geschwindigkeit des Referenzpunkts, die in der zuletzt übertragenen VAM enthalten ist, überschreitet minBodenGeschwindigkeitÄnderungSchwelle.
    • (7) die Differenz zwischen der Orientierung des Vektors des aktuellen geschätzten Bodengeschwindigkeitsvektors des Referenzpunkts des wahrgenommenen VRU-Clusters und der geschätzten Orientierung des Vektors des Bodengeschwindigkeitsvektors des Referenzpunkts, die in der zuletzt übertragenen Infrastruktur-VAM enthalten ist, überschreitet minBodenGeschwindigkeitsvektorOrientierungÄnderungSchwelle.
    • (8) Die Infrastruktur oder die Fahrzeuge haben bestimmt, dass es eine Differenz zwischen der aktuellen geschätzten Trajektorieabfangangabe mit dem/den Fahrzeug(en) oder anderen VRU(s) und der Trajektorieabfangangabe mit dem/den Fahrzeug(en) oder anderen VRU(s) gibt, die zuletzt in einer Infrastruktur-VAM gemeldet werden.
    • (9) die Ursprungs-Nicht-VRU-ITS-S hat bestimmt, den wahrgenommenen Cluster nach einem vorherigen Infrastruktur-VAM-Erzeugungsereignis mit einem oder mehreren anderen Clustern zusammenzuführen.
    • (10) die Ursprungs-Nicht-VRU-ITS-S hat bestimmt, den aktuellen Cluster nach vorherigem Infrastruktur-VAM-Erzeugungsereignis aufzuteilen.
    • (11) die Ursprungs-Nicht-VRU-ITS-S hat eine Änderung des Typs des wahrgenommenen VRU-Clusters (z.B. von homogenem zu heterogenem Cluster oder umgekehrt) nach einem vorherigen Infrastruktur-VAM-Erzeugungsereignis bestimmt.
    • (12) die Ursprungs-Nicht-VRU-ITS-S hat bestimmt, dass ein oder mehrere neue Fahrzeuge oder Nicht-Element-VRUs 116/117 (z.B. VRU-Profil 3 - Motorradfahrer) nach der zuletzt übertragenen VAM gleichzeitig die folgenden Bedingungen erfüllt hat. Die Bedingungen sind: seitliche Annäherung näher als minimaler sicherer Seitenabstand (MSLaD), Längsannäherung näher als minimaler sicherer Längsabstand (MSLoD) und Vertikalannäherung näher als minimaler sicherer Vertikalabstand (MSVD) an den Cluster-Begrenzungsrahmen nach der zuletzt übertragenen Infrastruktur-VAM
  • 1.9. BEISPIELHAFTE VAMS-DCROP-DATENFELDER
  • Tabelle 1.9-1 und Tabelle 1.9-2 zeigen eine DCROM-bezogene Erweiterung von VAM-Datenfeldern (DFs) gemäß verschiedenen Ausführungsformen. In Tabelle 1.9-1 sind die OSI- und GLI-DFs zum Ermöglichen einer DCROM über die empfangene VAM am Ego-VRU 116/117 von einer rechenfähigen ITS-S (z.B. R-ITS-Ss 130, V-ITS-Ss 110 und/oder HC-VRUs 116/117) definiert. Zusätzlich könnten alle relevanten ITS-Ss VAM in der Nähe des Ego-VRU 116/117 rundsenden, um eine kollaborative DCROM unter der Ego-VRU-ITS-S, anderen VRU-ITS-Ss und Nicht-VRU-ITS-Ss wie etwa V-ITS-Ss 110 und R-ITS-Ss 130 für eine gemeinsame kollaborative Wahrnehmung der VRU-Umgebungsbelegungskarte zu erzeugen. Eine weitere Beispiel-VAM ist durch Tabelle 1.9-2 für den Nachrichtenaustausch zwischen Ego-VRU und anderen ITS-Ss gezeigt, wobei DCROM-bezogene Informationen hinsichtlich der neuen DEs/DFs ausgedrückt werden, indem den Nachrichtenformaten gefolgt wird, die in Anhang A von [TS103300-2] angegeben sind.
  • Tabelle 1.9-3 zeigt eine beispielhafte VAM mit einem oder mehreren VRU-Erweiterungs-Containern des Typs VamErweiterung, der einen VRU-Niederfrequenz-, einen VRU-Hochfrequenz-, einen Clusterinformations-Container, einen Clusterbetrieb-Container und einen Bewegungsvorhersage-Container für jeden des VRU 116/117 und der VRU-Cluster trägt, die in einer von einer Nicht-VRU-ITS-S stammenden VAM gemeldet werden. Der VRU-Erweiterungs-Container trägt zusätzlich GesamtanzahllndividuellVruGemeldet-, GesamtanzalVruClusterGemeldet- und VruStraßenNetzBelegung-Container für eine von einer Nicht-VRU-ITS-S stammende VAM Das Straßengitterbelegungs-DF ist vom Typ VruStraßenNetzBelegung und sollte eine Angabe darüber bereitstellen, ob die Zellen belegt sind (durch eine andere VRU-ITS-Station oder ein anderes Objekt) oder frei. Die Angabe sollte durch das DE VruGitterBelegungStatusAnzeige dargestellt werden und der entsprechende Konfidenzwert sollte durch das DE KonfidenzNiveauProZelle angegeben werden. Zusätzliche DFs/DEs sind enthalten, um die Gitter- und Zellengrößen, die Straßensegmentreferenz-ID und den Referenzpunkt des Gitters zu tragen.
  • Die beispielhaften VAMs von Tabelle 1.9-1, Tabelle 1.9-2 und Tabelle 1.9-3 sind in den Nachrichtenformaten gemäß SAE International, „Dedicated Short Range Communications (DSRC) Message Set Dictionary“, J2735_201603 (30.03.2016) (im Folgenden „[SAEJ2735]“) strukturiert.
  • Figure DE112020006966T5_0040
    Figure DE112020006966T5_0041
    Figure DE112020006966T5_0042
    Figure DE112020006966T5_0043
    Figure DE112020006966T5_0044
    Figure DE112020006966T5_0045
    Figure DE112020006966T5_0046
  • In diesen Ausführungsformen können die neue V2X-Nachricht oder bestehende V2X/ITS-Nachrichten durch einen geeigneten Dienst oder eine geeignete Facility in der Facilities-Schicht erzeugt werden (vgl. z.B. 10 unten). In einigen Ausführungsformen, bei denen das ‚Potentielle-Gefährliche-Situation-VRU-Wahrnehmungs-Info‘ ein DE sein kann, das in einer kooperativen Bewusstmachungsnachricht (CAM) ((erzeugt durch eine Kooperativ-Bewusstmachungsdienst- (CAS-) Einrichtung), einer Kollektivwahrnehmungsnachricht (CPM) (erzeugt durch eine Kollektivwahrnehmungsdienst- (CPS-) Einrichtung), einer Manöverkoordinationsnachricht (MCM) (erzeugt durch eine Manöverkoordinationsdienst- (MCS-) Einrichtung), einer VRU-Bewusstmachungsnachricht (VAM) (erzeugt durch einen VRU-Basisdienst (vgl. z.B. 11), einer dezentralen Umgebungsbenachrichtigungsnachricht (DENM) (erzeugt durch eine DENM-Einrichtung) und/oder eine andere ähnliche Facilities-Schicht-Nachricht enthalten ist, wie etwa die vorliegend erörterten.
  • 2. KONFIGURATIONEN UND ANORDNUNGEN VON ITS-STATIONEN
  • 10 stellt eine beispielhafte ITS-S-Referenzarchitektur 1000 gemäß verschiedenen Ausführungsformen dar. Bei ITS-basierten Implementierungen können manche oder alle der in 10 dargestellten Komponenten das ITSC-Protokoll befolgen, das auf den Prinzipien des OSI-Modells für geschichtete Kommunikationsprotokolle basiert, die für ITS-Anwendungen erweitert sind. Die ITSC beinhaltet unter anderem eine Zugangsschicht, die den OSI-Schichten 1 und 2 entspricht, eine Vernetzungs- & Transport (N&T)-Schicht, die den OSI-Schichten 3 und 4 entspricht, die Facilities-Schicht, die den OSI-Schichten 5, 6 und zumindest mancher Funktionalität der OSI-Schicht 7 entspricht, und eine Anwendungsschicht, die einem Teil oder der Gesamtheit der OSI-Schicht 7 entspricht. Jede dieser Schichten ist über jeweilige Schnittstellen, SAPs, APIs und/oder andere ähnliche Verbinder oder Schnittstellen miteinander verbunden.
  • Die Anwendungsschicht 1001 stellt ITS-Dienste bereit, und ITS-Anwendungen sind innerhalb der Anwendungsschicht 1001 definiert. Eine ITS-Anwendung ist eine Anwendungsschichtentität, die Logik zum Erfüllen eines oder mehrerer ITS-Anwendungsfälle implementiert. Eine ITS-Anwendung nutzt die zugrundeliegenden Facilities und Kommunikationskapazitäten, die durch die ITS-S zur Verfügung gestellt werden. Jede Anwendung kann einer der drei identifizierten Anwendungsklassen zugeordnet werden: Verkehrssicherheit, Verkehrseffizienz und andere Anwendungen (siehe z.B. [EN302663]), ETSI TR 102 638 V1.1.1 (2009-06) (nachfolgend „[TR102638]“). Zu Beispielen für ITS-Anwendungen können Fahrassistenzanwendungen (z. B. für Cooperative Awareness und Verkehrswarnhinweise) einschließlich AEB-, EMA- und FCW-Anwendungen, Geschwindigkeitsmanagementanwendungen, Kartierungs- und/oder Navigationsanwendungen (z. B. Turn-by-Turn-Navigation und kooperative Navigation), Anwendungen, die standortbasierte Dienste bereitstellen, und Anwendungen, die Vernetzungsdienste bereitstellen (z. B. globale Internetdienste und ITS-S-Lebenszyklusmanagementdienste) zählen. Eine V-ITS-S 110 stellt Fahrzeugführern und/oder Passagieren ITS-Anwendungen bereit und kann eine Schnittstelle zum Zugreifen auf fahrzeuginterne Daten aus dem fahrzeuginternen Netzwerk oder fahrzeuginternen System erfordern. Für Einsatz- und Leistungsanforderungen können spezifische Instanzen einer V-ITS-S 110 Gruppierungen von Anwendungen und/oder Facilities enthalten.
  • Die Facilities-Schicht 1002 umfasst Middleware, Softwareverbinder, Software-Glue oder dergleichen, die mehrere Facility-Schichtfunktionen (oder einfach eine „Facility“) umfassen. Insbesondere enthält die Facilities-Schicht Funktionalität von der OSI-Anwendungsschicht, der OSI-Darstellungsschicht (z.B. ASN.1-Codierung und -Decodierung und Verschlüsselung) und der OSI-Sitzungsschicht (z.B. Inter-Host-Kommunikation). Eine Facility ist eine Komponente, die den Anwendungen in der Anwendungsschicht Funktionen, Informationen und/oder Dienste bereitstellt und mit anderen ITS-Ss Daten mit niedrigeren Schichten zum Kommunizieren dieser Daten austauscht. Zu beispielhaften Facilities zählen Cooperative Awareness Services, Collective Perception Services, Device Data Provider (DDP), Positions- und Zeitmanagement (POTI, Position and Time Management), Local Dynamic Map (LDM), Collaborative Awareness-Basisdienst (CA-BS) und/oder Cooperative Awareness-Basisdienst (CA-BS), Signal Phase and Timing-Dienst (SPATS), Basisdienst ungeschützte Verkehrsteilnehmer (VBS), Decentralized Environmental Notification (DEN)-Basisdienst, Manöverkoordinationsdienste (MCS) und/oder dergleichen. Für eine Fahrzeug-ITS-S ist der DDP mit dem fahrzeuginternen Netzwerk verbunden und stellt die Fahrzeugzustandsinformationen bereit. Die POTI-Entität stellt die Position der ITS-S und Zeitinformationen bereit. Eine Liste der gängigen Facilities gibt ETSI TS 102 894-1 V1.1.1 (2013-08) (im Folgenden „[TS102894-1]“).
  • Jede der oben erwähnten Schnittstellen/Dienstzugangspunkte (SAPs) kann den Vollduplexaustausch von Daten mit der Facilities-Schicht bereitstellen und kann geeignete APIs implementieren, um Kommunikation zwischen den verschiedenen Entitäten/Elementen zu ermöglichen.
  • Für eine Fahrzeug-ITS-S ist die Facilities-Schicht 1002 über ein fahrzeuginternes Daten-Gateway mit einem fahrzeuginternen Netzwerk verbunden, wie in [TS102894-1] gezeigt und beschrieben. Die Facilities und Anwendungen einer Fahrzeug-ITS-S empfangen benötigte fahrzeuginterne Daten von dem Daten-Gateway, um Nachrichten (z. B. CSMs, VAMs, CAMs, DENMs, MCMs und/oder CPMs) und zur Anwendungsnutzung aufzubauen. Zum Senden und Empfangen von CAMs beinhaltet der CA-BS die folgenden Entitäten: eine CAM-Codierentität, eine CAM-Decodierentität, eine CAM-Übertragungsverwaltungsentität und eine CAM-Empfangsverwaltungsentität. Zum Senden und Empfangen von DENMs beinhaltet der DEN-BS die folgenden Entitäten: eine DENM-Codierentität, eine DENM-Decodierentität, eine DENM-Übertragungsmanagemententität, eine DENM-Empfangsmanagemententität und eine DENM-Keep-Alive-Weiterleitungs (KAF, Keep-Alive Forwarding)-Entität. Die CAM/DENM-Übertragungsmanagemententität implementiert die Protokolloperation der Ursprungs-ITS-S einschließlich Aktivierung und Beendigung der CAM/DENM-Übertragungsoperation, Bestimmen der CAM/DENM-Generierungsfrequenz und Triggern der Generierung von CAMs/DENMs. Die CAM/DENM-Empfangsmanagemententität implementiert die Protokolloperation der empfangenden ITS-S einschließlich des Triggerns der Decodier-CAM/DENM-Entität beim Empfang von CAMs/DENMs, Bereitstellen empfangener CAM/DENM-Daten an das LDM, Facilities oder Anwendungen der empfangenden ITS-S, Verwerfen ungültiger CAMs/DENMs und Prüfen der Informationen empfangener CAMs/DENMs. Die DENM-KAF-Entität KAF speichert eine empfangene DENM während ihrer Gültigkeitsdauer und leitet die DENM gegebenenfalls weiter; die Nutzungsbedingungen der DENM-KAF können entweder durch ITS-Anwendungsanforderungen oder durch eine schichtübergreifende Funktionalität einer ITSC-Managemententität definiert sein. Die CAM/DENM-Codierentität konstruiert (codiert) CAMs/DENMs, damit sie verschiedene beinhaltet, wobei die Objektliste eine Liste von DEs und/oder DFs beinhalten kann, die in einem ITS-Datenlexikon enthalten sind.
  • Die ITS-Stationstyp-/-Fähigkeiten-Facility stellt Informationen bereit, um ein Profil einer ITS-S zu beschreiben, die in der Anwendungs- und der Facilities-Schicht verwendet werden soll. Dieses Profil gibt den ITS-S-Typ (z. B. Fahrzeug-ITS-S, Roadside-ITS-S, persönliche ITS-S oder zentrale ITS-S), eine Rolle der ITS-S und Detektionsfähigkeiten und -status (z. B. Positionsbestimmungsfähigkeiten der ITS-S, Abtastfähigkeiten usw.) an. Die Stationstyp-/Fähigkeiten-Facility kann Sensorfähigkeiten verschiedener verbundener/gekoppelter Sensoren und Sensordaten, die von solchen Sensoren erhalten werden, speichern. 10 zeigt die VRU-spezifische Funktionalität, einschließlich Schnittstellen, die der ITS-S-Architektur zugeordnet sind. Die VRU-spezifische Funktionalität ist um den VRU-Basisdienst (VBS) 1021 herum zentriert , der sich in der Facilities-Schicht befindet, die Daten von anderen Facility-Schicht-Diensten beansprucht, wie etwa der Positions- und Zeitverwaltung (PoTi) 1022, der lokalen dynamischen Karte (LDM) 1023, der HMI-Unterstützung 1024, DCC-FAC 1025, dem CA-Basisdienst (CBS) 1026 usw. Die PoTi-Entität 1022 stellt die Position der ITS-S und Zeitinformationen bereit. Die LDM 1023 ist eine Datenbank in der ITS-S, die zusätzlich zu Bordsensordaten mit empfangenen CAM- und CPM-Daten aktualisiert werden kann (siehe z.B. ETSI TR 102 863 v1.1.1 (2011-06)). Nachrichtenverteilungsspezifische Informationen bezüglich der aktuellen Kanalnutzung werden durch Verbinden mit der DCC-FAC-Entität 1025 empfangen. DCC-FAC 1025 stellt dem VBS 1021 Zugangsnetzüberlastungsinformationen bereit.
  • Die Positions- und Zeitverwaltungsentität (PoTi) verwaltet die Positions- und Zeitinformationen zur Verwendung durch die ITS-Anwendungs-, Facility-, Netzwerk-, Verwaltungs- und Sicherheitsschicht. Zu diesem Zweck erhält die PoTi Informationen von Subsystementitäten, wie etwa GNSS, Sensoren und einem anderen Subsystem der ITS-S. Die POTI stellt ITS-Zeitsynchronität zwischen ITS-Ss in einer ITS-Konstellation sicher, hält die Datenqualität aufrecht (z.B. durch Überwachen der Zeitabweichung) und verwaltet Aktualisierungen der Position (z.B. kinematischer und Lagezustand) und der Zeit. Eine ITS-Konstellation ist eine Gruppe von ITS-S, die IHRE Daten untereinander austauschen. Die PoTi-Entität 1022 kann Erweiterungsdienste beinhalten, um die Positions- und Zeitgenauigkeit, Integrität und Zuverlässigkeit zu verbessern. Unter diesen Verfahren können Kommunikationstechnologien verwendet werden, um Positionsbestimmungsunterstützung von mobilen zu mobilen ITS-Ss und Infrastruktur zu mobilen ITS-Ss bereitzustellen. Angesichts der ITS-Anwendungsanforderungen hinsichtlich der Positions- und Zeitgenauigkeit kann die POTI 1022 Erweiterungsdienste verwenden, um die Positions- und Zeitgenauigkeit zu verbessern. Verschiedene Erweiterungsverfahren können angewendet werden. Die PoTi 1022 kann diese Erweiterungsdienste unterstützen, indem Nachrichtendienste bereitgestellt werden, die Erweiterungsdaten rundsenden. Beispielsweise kann eine Straßenrand-ITS-S Korrekturinformationen für GNSS an eine entgegenkommende Fahrzeug-ITS-S rundsenden; ITS-Ss können GPS-Rohdaten austauschen oder können terrestrische Funkpositions- und zeitrelevante Informationen austauschen. Die PoTi 1022 hält und stellt die Positions- und Zeitreferenzinformationen gemäß den Dienstanforderungen der Anwendungs- und Facility- und anderen Schicht in der ITS-S bereit. Im Kontext von ITS beinhaltet die „Position“ Lageparameter und Bewegungsparameter, einschließlich Geschwindigkeitsvektor, Kurs, Horizontalgeschwindigkeit und optional anderer. Der kinematische und Lagezustand eines starren Körpers, der in der ITS-S enthalten ist, beinhaltet Position, Geschwindigkeit, Beschleunigung, Ausrichtung, Winkelgeschwindigkeit und mögliche andere bewegungsbezogene Informationen. Die Positionsinformationen zu einem spezifischen Zeitpunkt werden als der kinematische und Lagezustand des starren Körpers einschließlich der Zeit bezeichnet. Neben dem kinematischen und Lagezustand sollte die PoTi 1022 auch Informationen über die Konfidenz der kinematischen und Lagezustandsvariablen erhalten.
  • Der VBS 1021 ist auch mit anderen Entitäten verknüpft, wie etwa Anwendungsunterstützungseinrichtungen, einschließlich zum Beispiel des Basisdienstes für kollaboratives/kooperatives Bewusstsein (CAPS), Signalphase- und Timing-Dienstes (SPATS), dezentralisierten Umgebungsbenachrichtigungsdienstes (DEN-Dienst), Kollektivwahrnehmungsdienstes (CPS), Manöverkoordinationsdienstes (MCS), Infrastrukturdienstes 1012 usw. Der VBS 1021 ist für das Übertragen der VAMs, das Identifizieren, ob der VRU Teil eines Clusters ist, und das Ermöglichen der Beurteilung eines potentiellen Kollisionsrisikos zuständig. Der VBS 1021 kann auch mit einer VRU-Profilverwaltungsentität in der Verwaltungsschicht zu VRU-bezogenen Zwecken interagieren.
  • Der VBS 1021 verbindet sich durch den Netzwerk-Transport/Facilities- (NF-) Dienstzugangspunkt (SAP) mit dem N&T zum Austauschen von CPMs mit anderen ITS-Ss. Die VBS 1021 verbindet sich durch den Sicherheits-Facilities- (SF-) SAP mit der Sicherheitsentität, um auf Sicherheitsdienste für VAM-Übertragung und VAM-Empfang 1103 zuzugreifen. Der VBS 1021 verbindet sich durch den Verwaltungs-Facilities- (MF-) SAP mit der Verwaltungsentität und durch den Facilities-Anwendungs- (FA-) SAP mit der Anwendungsschicht, falls empfangene VAM-Daten direkt an die Anwendungen geliefert werden. Jede der oben erwähnten Schnittstellen/SAPs kann den Vollduplexaustausch von Daten mit der Facilities-Schicht bereitstellen und kann geeignete APIs implementieren, um Kommunikation zwischen den verschiedenen Entitäten/Elementen zu ermöglichen.
  • In einigen Ausführungsformen können die hier besprochenen Ausführungsformen in oder durch den VBS 1021 implementiert werden. Insbesondere kann sich das VBS-Modul/die VBS-Entität 1021 in der Facilities-Schicht befinden oder in dieser arbeiten, erzeugt VAMs, prüft zugehörige Dienste/Nachrichten, um die Übertragung von VAMs in Verbindung mit anderen ITS-Dienstnachrichten zu koordinieren, die durch andere Facilities und/oder andere Entitäten innerhalb der ITS-S erzeugt werden, die dann zu den N&T- und den Zugangsschichten zur Übertragung zu anderen nahe gelegenen ITS-Ss weitergeleitet werden. In einigen Ausführungsformen sind die VAMs in ITS-Paketen enthalten, die Facilities-Schicht-PDUs sind, die über die N&T-Schicht zu der Zugangsschicht weitergeleitet oder zum Verbrauch durch eine oder mehrere ITS-Anwendungen zur Anwendungsschicht weitergeleitet werden können. Auf diese Weise ist das VAM-Format agnostisch gegenüber der zugrundeliegenden Zugangsschicht und ist dazu ausgelegt, zu ermöglichen, dass VAMs unabhängig von der zugrundeliegenden Zugangstechnologie/RAT gemeinsam genutzt werden.
  • Die Anwendungsschicht empfiehlt eine mögliche Verteilung funktionaler Entitäten, die am Schutz der VRUs 116 beteiligt wären, basierend auf der Analyse von VRU-Anwendungsfällen. Die Anwendungsschicht beinhaltet zudem eine Vorrichtungsrolleneinstellfunktion/-anwendung (App) 1011, eine Infrastrukturdienstfunktion/App 1012, eine Manöverkoordinationsfunktion/App 1013, eine kooperative Wahrnehmungsfunktion/App 1014, eine Fernsensordatenfusionsfunktion/App 1015, eine Kollisionsrisikoanalyse- (CRA-) Funktion/App 1016, eine Kollisionsrisikovermeidungsfunktion/App 1017 und eine Ereignisdetektionsfunktion/App 1018.
  • Das Vorrichtungsrolleneinstellmodul 1011 nimmt die Konfigurationsparametereinstellungen und Benutzerpräferenzeinstellungen und aktiviert/deaktiviert unterschiedliche VRU-Profile in Abhängigkeit von den Parametereinstellungen, Benutzerpräferenzeinstellungen und/oder anderen Daten (z.B. Sensordaten und dergleichen). Ein VRU kann mit einer tragbaren Vorrichtung ausgestattet sein, die anfänglich konfiguriert werden muss und sich während seines Betriebs im Anschluss an Kontextänderungen, die spezifiziert werden müssen, entwickeln kann. Dies gilt insbesondere für das Einrichten des VRU-Profils und -Typs, die automatisch beim Einschalten oder über ein HMI erreicht werden können. Die Änderung des Straßenbenutzer-Vulnerabilitätszustands muss zudem bereitgestellt werden, um den VBS 1021 zu aktivieren, wenn der Straßenbenutzer vulnerabel/ungeschützt wird, oder ihn zu deaktivieren, wenn er in einen geschützten Bereich eintritt. Die Anfangskonfiguration kann automatisch eingerichtet werden, wenn die Vorrichtung eingeschaltet wird. Dies kann für folgenden VRU-Gerätetyp der Fall sein: VRU-Tx (ein VRU nur mit der Kommunikationsfähigkeit zum Senden von Nachrichten, die die Kanalüberlastungssteuerregeln erfüllen); VRU-Rx (ein VRU nur mit Kommunikationsfähigkeit zum Empfangen von Nachrichten); und VRU-St (ein VRU mit Vollduplex- (Tx- und Rx-) Kommunikationsfähigkeiten). Während des Betriebs kann sich das VRU-Profil zudem aufgrund von Clusterung oder Deassemblierung ändern. Folglich wird die VRU-Vorrichtungsrolle in der Lage sein, sich gemäß den Änderungen des VRU-Profils zu entwickeln.
  • Das Infrastrukturdienstmodul 1012 ist dafür zuständig, neue VRU-Instanziierungen zu starten, Nutzungsdaten zu sammeln und/oder Dienste von Infrastrukturstationen zu beanspruchen. Bestehende Infrastrukturdienste 1012, wie etwa die nachstehend beschriebenen, können im Kontext des VBS 1021 verwendet werden:
  • Der Broadcast des SPAT (Signalphase und Timing) & KARTE (nach SPAT-Relevanz begrenzte Fläche) ist bereits standardisiert und wird von Fahrzeugen auf Kreuzungsebene verwendet. Im Prinzip schützen sie einander kreuzende VRUs 116. Es können jedoch Signalverstoßwarnungen existieren und können unter Verwendung von DENM detektiert und signalisiert werden. Diese Signalverstoßanzeige unter Verwendung von DENMs ist für VRU-Vorrichtungen sehr relevant, da sie eine Zunahme des Kollisionsrisikos mit dem Fahrzeug anzeigt, das das Signal verletzt. Wenn sie lokale Fänger verwendet oder VAMs detektiert und analysiert, kann die Ampelsteuerung die Rotphasenänderung auf Grün verzögern und dem VRU ermöglichen, seine Straßenüberquerung sicher zu beenden.
  • Die kontextbezogene Geschwindigkeitsbegrenzung unter Verwendung von IVI (In Vehicle Information, fahrzeuginterne Informationen) kann angepasst werden, wenn ein großer Cluster von VRUs 116 detektiert wird (z.B. Begrenzen der Fahrzeuggeschwindigkeit auf 30 km/Stunde). Bei einer derartigen reduzierten Geschwindigkeit kann ein Fahrzeug effizient agieren, wenn es die VRUs 116 mittels seines eigenen lokalen Wahrnehmungssystems wahrnimmt.
  • Fernsensordatenfusions- und Aktuatoranwendungen/-funktionen 1015 (einschließlich ML/AI) sind ebenfalls in einigen Implementierungen enthalten. Die lokalen Wahrnehmungsdaten, die durch die Berechnung von Daten erhalten werden, die durch lokale Sensoren gesammelt werden, können durch entfernte Daten erweitert werden, die durch Elemente des VRU-Systems (z.B. V-ITS-Ss 110, R-ITS-Ss 130) über die ITS-S gesammelt werden. Diese Ferndaten werden unter Verwendung von Standarddiensten, wie etwa des CPS und/oder dergleichen, übertragen. In einem solchen Fall kann es notwendig sein, diese Daten zu fusionieren. In einigen Implementierungen kann die Datenfusion mindestens drei mögliche Ergebnisse liefern: (i) nach einer Datenkonsistenzprüfung sind die empfangenen Ferndaten nicht kohärent mit den lokalen Daten, wobei das Systemelement entscheiden muss, welcher Quelle der Daten vertraut werden kann und welche zu ignorieren ist; (ii) nur eine Eingabe ist verfügbar (z.B. die Ferndaten), was bedeutet, dass die andere Quelle nicht die Möglichkeit hat, Informationen bereitzustellen, wobei das Systemelement der einzigen verfügbaren Quelle vertrauen kann; und (iii) nach einer Datenkonsistenzprüfung stellen die beiden Quellen kohärente Daten bereit, die die einzelnen bereitgestellten Eingaben erweitern. Die Verwendung von ML/AI kann notwendig sein, um die detektierten Objekte (z.B. VRU, Motorrad, Fahrzeugtyp usw.), aber auch ihre assoziierte Dynamik zu erkennen und zu klassifizieren. Die AI kann sich in einem beliebigen Element des VRU-Systems befinden. Derselbe Ansatz ist auf Aktuatoren anwendbar, wobei die Aktuatoren in diesem Fall jedoch das Ziel der Datenfusion sind.
  • Die kollektive Wahrnehmung (CP) beinhaltet, dass ITS-Ss Informationen über ihre aktuellen Umgebungen miteinander teilen. Eine ITS-S, die an der CP teilnimmt, sendet Informationen über ihre aktuelle (zum Beispiel Fahr-) Umgebung anstatt über sich selbst. Zu diesem Zweck involviert die CP verschiedene ITS-Ss, die lokal wahrgenommene Objekte (z.B. andere Verkehrsteilnehmer und VRUs 116, Hindernisse und dergleichen), die durch lokale Wahrnehmungssensoren mittels einer oder mehrerer V2X-RATs detektiert werden, aktiv austauschen. In einigen Implementierungen beinhaltet CP eine Wahrnehmungskette, die die Fusion von Ergebnissen mehrerer Wahrnehmungsfunktionen zu vordefinierten Zeiten sein kann. Diese Wahrnehmungsfunktionen können lokale Wahrnehmungs- und Fernwahrnehmungsfunktionen beinhalten.
  • Die lokale Wahrnehmung wird durch die Sammlung von Informationen aus der Umgebung des betrachteten ITS-Elements (z.B. VRU-Vorrichtung, Fahrzeug, Infrastruktur usw.) bereitgestellt. Diese Informationssammlung wird unter Verwendung relevanter Sensoren (optische Kamera, thermische Kamera, Radar, LIDAR usw.) erreicht. Die Fernwahrnehmung wird durch die Bereitstellung von Wahrnehmungsdaten über C-ITS (hauptsächlich V2X-Kommunikation) bereitgestellt. Existierende Basisdienste, wie etwa für kooperatives Bewusstsein (CA) oder neuere Dienste, wie etwa der Kollektivwahrnehmungsdienst (CPS), können verwendet werden, um eine Fernwahrnehmung zu übertragen.
  • Mehrere Wahrnehmungsquellen können dann verwendet werden, um die kooperative Wahrnehmungsfunktion 1014 zu erreichen. Die Konsistenz dieser Quellen kann in vordefinierten Momenten verifiziert werden, und, wenn nicht konsistent, kann die CP-Funktion die beste gemäß dem Konfidenzniveau auswählen, das mit jeder Wahrnehmungsvariablen assoziiert ist. Das Ergebnis der CP sollte dem erforderlichen Genauigkeitsniveau entsprechen, wie durch die PoTi spezifiziert. Das assoziierte Konfidenzniveau kann notwendig sein, um die CP, die aus der Fusion resultiert, im Fall von Differenzen zwischen der lokalen Wahrnehmung und der Fernwahrnehmung aufzubauen. Es kann auch für die Nutzung durch andere Funktionen (z.B. Risikoanalyse) des CP-Ergebnisses notwendig sein.
  • Die Wahrnehmungsfunktionen von der Verarbeitung durch die lokalen Vorrichtungssensoren bis zum Endergebnis auf der Ebene der kooperativen Wahrnehmung 1014 können eine signifikante Latenzzeit von mehreren hundert Millisekunden darstellen. Für die Charakterisierung einer VRU-Trajektorie und ihre Geschwindigkeitsvektorentwicklung besteht ein Bedarf an einer gewissen Anzahl der Fahrzeugpositionsmessungen und Geschwindigkeitsvektormessungen, wodurch die Gesamtlatenzzeit der Wahrnehmung erhöht wird. Folglich ist es notwendig, die Gesamtlatenzzeit dieser Funktion zu schätzen, um sie beim Auswählen einer Kollisionsvermeidungsstrategie zu berücksichtigen.
  • Die CRA-Funktion 1016 analysiert die bewegungsdynamische Vorhersage der betrachteten sich bewegenden Objekte, die mit ihren jeweiligen Konfidenzniveaus (Zuverlässigkeit) assoziiert sind. Eine Zielsetzung besteht darin, die Wahrscheinlichkeit einer Kollision zu schätzen und dann die Zeit bis zur Kollision (TTC) so präzise wie möglich zu identifizieren, falls die resultierende Wahrscheinlichkeit hoch ist. Andere Variablen können zum Berechnen dieser Schätzung verwendet werden.
  • In einigen Ausführungsformen sind die VRU-CRA-Funktion 1016 und die dynamische Zustandsprognose in der Lage, die relevanten Verkehrsteilnehmermanöver mit einem akzeptablen Konfidenzniveau zum Zweck des Auslösens der geeigneten Kollisionsvermeidungsaktion zuverlässig vorherzusagen, unter der Annahme, dass die Eingabedaten von ausreichender Qualität sind. Die CRA-Funktion 1016 analysiert das Kollisionsrisiko basierend auf einer zuverlässigen Vorhersage der jeweiligen dynamischen Zustandsentwicklung. Folglich kann der Zuverlässigkeitsniveauaspekt hinsichtlich eines Konfidenzniveaus für die ausgewählten Kollisionsrisikometriken charakterisiert werden, wie in den Klauseln 6.5.10.5 und 6.5.10.9 von [TS103300-2] besprochen ist. Die Konfidenz einer dynamischen VRU-Zustandsprognose wird zum Zweck der Risikoanalyse berechnet. Die Vorhersage des dynamischen Zustands des VRU ist besonders für manche spezifischen VRU-Profile (z.B. Tier, Kind, behinderte Person usw.) kompliziert. Daher kann mit dieser Vorhersage ein Konfidenzniveau assoziiert werden, wie in den Klauseln 6.5.10.5, 6.5.10.6 und 6.5.10.9 von [TS103300-2] erläutert. Die zuverlässige VRU-Bewegungsvorhersage wird verwendet, um das Rundsenden relevanter VAMs auszulösen, wenn ein Kollisionsrisiko, das einen VRU involviert, mit ausreichender Konfidenz detektiert wird, um falsch positive Warnungen zu vermeiden (siehe z.B. Klauseln 6.5.10., 6.5.10.6 und 6.5.10.9 von [TS 103300-2]).
  • Zur Berechnung der TTC werden folgende zwei Bedingungen verwendet. Erstens folgen zwei oder mehr in Betracht gezogene sich bewegende Objekte Trajektorien, die sich irgendwo an einer Position schneiden, die als „potentieller Konfliktpunkt“ bezeichnet werden kann. Zweitens ist es, falls die sich bewegenden Objekte ihre Bewegungsdynamiken beibehalten (z.B. Annäherungen, Trajektorien, Geschwindigkeiten usw.), möglich, vorherzusagen, dass sie zu einer gegebenen Zeit kollidieren werden, die durch die Berechnung der Zeit geschätzt werden kann (als Zeit bis zur Kollision (TTC) bezeichnet), die notwendig ist, damit sie gleichzeitig auf der Ebene des identifizierten potenziellen Konfliktpunkts ankommen. Die TTC ist ein berechnetes Datenelement, das die Auswahl der Art und Dringlichkeit einer durchzuführenden Kollisionsvermeidungsaktion ermöglicht.
  • Eine TTC-Vorhersage kann nur zuverlässig bestimmt werden, wenn der VRU 116 in einen Kollisionsrisikoraum eintritt. Dies beruht auf der Ungewissheit der VRU-Fußgängerbewegungsdynamik (hauptsächlich seiner Trajektorie), bevor er entscheidet, die Straße zu überqueren.
  • Auf Ebene des potentiellen Konfliktpunkts kann eine andere Messung, die ‚Zeitdifferenz für einen Fußgänger und ein Fahrzeug, die zu dem potentiellen Konfliktpunkt‘ (TDTC) fahren, verwendet werden, um das Kollisionsrisikoniveau zu schätzen. Falls sie beispielsweise nicht auf die Bewegungsdynamik des Fußgängers oder/und auf die Bewegungsdynamik des Fahrzeugs einwirken, ist TDTC gleich 0 und die Kollision ist gewiss. Durch Erhöhen der TDTC wird das Kollisionsrisiko zwischen dem VRU und dem Fahrzeug verringert. Der potentielle Konfliktpunkt befindet sich in der Mitte des Kollisionsrisikobereichs, der gemäß der Fahrspurbreite (z.B. 3,5 m) und der Fahrzeugbreite (maximal 2 m für Personenkraftwagen) definiert werden kann.
  • Die TTC ist eine der Variablen, die verwendet werden können, um eine Kollisionsvermeidungsstrategie und die durchzuführenden operativen Kollisionsvermeidungsaktionen zu definieren. Andere Variablen können berücksichtigt werden, wie etwa der Straßenzustand, die Wetterbedingungen, das Dreifache von {Längsabstand (LOD), Seitenabstand (Lad), Vertikalabstand (VD)} zusammen mit dem entsprechenden Schwellenwert-Dreifachen von {MSLaD, MSLoD, MSVD}, Trajektorieabfangindikator (TII) und die Fähigkeiten der mobilen Objekte, auf ein Kollisionsrisiko zu reagieren und eine Kollision zu vermeiden (siehe z.B. Klausel 6.5.10.9 in [TS103300-2]). Die TII ist ein Indikator für die Wahrscheinlichkeit, dass der VRU 116 und ein oder mehrere andere VRUs 116, Nicht-VRUs oder auch Objekte auf der Straße kollidieren werden.
  • Die CRA-Funktion 1016 vergleicht Lad, LOD und VD mit ihren jeweiligen vordefinierten Schwellen, MSLaD, MSLoD bzw. MSVD, und falls alle drei Metriken gleichzeitig kleiner als ihre jeweiligen Schwellen sind, das heißt Lad < MSLaD, LOD < MSLoD, VD < MSVD, werden die Kollisionsvermeidungsaktionen initiiert. Diese Schwellen könnten in Abhängigkeit von der Geschwindigkeit, Beschleunigung, dem Typ und der Beladung der Fahrzeuge und VRUs 116 und den Umgebungs- und Wetterbedingungen periodisch oder dynamisch eingestellt und aktualisiert werden. Andererseits spiegelt die TII wider, wie wahrscheinlich die Ego-VRU-ITS-S-Trajektorie 117 durch die benachbarten ITSs (andere VRUs 116 und/oder Nicht-VRU-ITSs, wie etwa die Fahrzeuge 110) abgefangen werden wird.
  • Die Wahrscheinlichkeit einer Kollision, die mit der TTC assoziiert ist, kann auch als eine Auslösebedingung für das Rundsenden von Nachrichten verwendet werden (z.B. kann ein Infrastrukturelement, das eine vollständige Wahrnehmung der Situation erhält, DENM, IVI (kontextbezogene Geschwindigkeitsbegrenzung), CPM oder MCM rundsenden).
  • Die Kollisionsrisikovermeidungsfunktion/-anwendung 1017 beinhaltet die Kollisionsvermeidungsstrategie, die gemäß dem TTC-Wert ausgewählt werden soll. Im Fall von autonomen Fahrzeugen 110 kann die Kollisionsrisikovermeidungsfunktion 1017 die Identifikation der Manöveranoordination 1013/der Fahrzeugbewegungssteuerung 1308 beinhalten, um die Kollisionsvermeidung gemäß der Wahrscheinlichkeit einer VRU-Trajektorieabfangung mit anderen Verkehrsteilnehmern zu erreichen, die durch TII and Manöverkennung (MI) erfasst werden, wie im Folgenden erörtert wird.
  • Die Kollisionsvermeidungsstrategie kann mehrere Umgebungsbedingungen berücksichtigen, wie etwa Sichtbedingungen in Bezug auf das lokale Wetter, Fahrzeugstabilitätsbedingungen in Bezug auf den Straßenzustand (z.B. rutschig) und Fahrzeugbremsfähigkeiten. Die Fahrzeugkollisionsvermeidungsstrategie muss dann die Aktionsfähigkeiten des VRU gemäß ihrem Profil, der verbleibenden TTC, den Straßen- und Wetterbedingungen sowie den autonomen Aktionsfähigkeiten des Fahrzeugs berücksichtigen. Die Kollisionsvermeidungsaktionen können unter Verwendung einer Manöverkoordination 1013 (und eines zugehörigen Manöverkoordinationsnachrichten- (MCM-) Austauschs) implementiert werden, wie sie bei dem französischen Projekt PAC-V2X oder anderen ähnlichen Systemen durchgeführt werden.
  • Bei einem Beispiel ist es unter guten Bedingungen möglich, eine Kollisionsvermeidungsaktion auszulösen, wenn die TTC größer als zwei Sekunden ist (eine Sekunde für die Fahrerreaktionszeit und eine Sekunde, um die Kollisionsvermeidungsaktion zu erreichen). Unterhalb von zwei Sekunden kann das Fahrzeug als in einer „vor-Crash“-Situation befindlich betrachtet werden, und somit muss es eine Abschwächungsaktion auslösen, um die Schwere des Kollisionsaufpralls für den VRU 116/117 zu reduzieren. Die möglichen Kollisionsvermeidungshandlungen und Aufprallabschwächungsaktionen wurden in Anforderung FSYS08 in Klausel 5 von [TS103300-2] aufgelistet.
  • Straßeninfrastrukturelemente (z.B. R-ITS-Ss 130) können zudem eine CRA-Funktion 1016 sowie eine Kollisionsrisikovermeidungsfunktion 1017 beinhalten. Bei diesen Ausführungsformen können diese Funktionen den benachbarten VRUs 116/117 und Fahrzeugen 110 Kollisionsvermeidungsaktionen angeben.
  • Die Kollisionsvermeidungsaktionen (z.B. unter Verwendung von MCM, wie es im französischen PAC-V2X-Projekt durchgeführt wird) für VRUs, V-ITS-Ss und/oder R-ITS-Ss können von dem Fahrzeugautomatisierungsniveau abhängen. Die Kollisionsvermeidungsaktion oder Aufprallabschwächungsaktion wird als eine Warnung/Alarm für den Fahrer oder als eine direkte Aktion am Fahrzeug 110 selbst ausgelöst. Beispiele für Kollisionsvermeidung beinhalten eine beliebige Kombination von: Erweitern oder Ändern der Phase einer Ampel; Einwirken auf die Trajektorie und/oder den Geschwindigkeitsvektor der Fahrzeuge 110 (z.B. Verlangsamen, Spurwechsel usw.), wenn das Fahrzeug 110 ein ausreichendes Automatisierungsniveau aufweist; Alarmieren des ITS-Vorrichtungsbenutzers durch die HMI; Verteilen einer C-ITS-Nachricht an andere Verkehrsteilnehmer, einschließlich des VRU 116/117, falls relevant. Beispiele für Abschwächungsmaßnahmen können eine beliebige Kombination von Auslösen eines Schutzmittels auf Fahrzeugebene (z.B. erweiterter externer Airbag); Auslösen eines tragbaren VRU-Schutzairbags beinhalten.
  • Die Straßeninfrastruktur kann Dienste zur Unterstützung der Straßenüberquerung durch VRU, wie etwa Ampeln, anbieten. Wenn ein VRU beginnt, eine Straße auf Ampelebene zu überqueren, die ihn autorisiert, sollte die Ampel nicht die Phase wechseln, solange der VRU seine Überquerung nicht abgeschlossen hat. Dementsprechend sollte die VAM Datenelemente enthalten, die es der Ampel ermöglichen, das Ende der Straßenkreuzung durch den VRU 116/117 zu bestimmen.
  • Die Manöverkoordinationsfunktion 1013 führt die Kollisionsvermeidungsaktionen aus, die mit der Kollisionsvermeidungsstrategie assoziiert sind, die entschieden (und ausgewählt) wurde. Die Kollisionsvermeidungsaktionen werden auf der Ebene des VRU 116/117, des Fahrzeugs 110 oder beider in Abhängigkeit von den VRU-Fähigkeiten zum Handeln (z.B. VRU-Profil und -Typ), dem Fahrzeugtyp und den Fähigkeiten und dem tatsächlichen Kollisionsrisiko ausgelöst. VRUs 116/117 besitzen nicht immer die Fähigkeit, zu handeln, um eine Kollision zu vermeiden (z.B. Tier, Kinder, ältere Person, Behinderte usw.), insbesondere wenn die TTC kurz ist (einige wenige Sekunden) (siehe z.B. Klauseln 6.5.10.5 und 6.5.10.6 von [TS103300-2]. Diese Funktion sollte auf Fahrzeugebene 110 vorhanden sein, auch abhängig vom Automatisierungsniveau des Fahrzeugs 110 (z.B. nicht in nichtautomatisierten Fahrzeugen vorhanden), und kann gemäß dem VRU-Profil auf Ebene der VRU-Vorrichtung 117 vorhanden sein. Auf Ebene des Fahrzeugs 110 ist diese Funktion der Fahrzeugelektronik zugeordnet, die den dynamischen Fahrzeugzustand in Bezug auf Kurs und Geschwindigkeitsvektor steuert. Auf der Ebene der VRU-Vorrichtung 117 kann diese Funktion die HMI-Unterstützungsfunktion gemäß dem VRU-Profil verknüpfen, um in der Lage zu sein, eine Warnung oder einen Alarm an den VRU 116/117 gemäß der TTC auszugeben.
  • Eine Manöverkoordination 1013 kann Fahrzeugen von einem Infrastrukturelement vorgeschlagen werden, das in der Lage sein kann, eine bessere Wahrnehmung der Bewegungsdynamiken der beteiligten sich bewegenden Objekte mittels seiner eigenen Sensoren oder durch die Fusion ihrer Daten mit der Fernwahrnehmung, die aus Standardnachrichten wie etwa CAMs erhalten wird, zu erhalten.
  • Die Manöverkoordination 1013 am VRU 116 kann durch Teilen unter der Ego-VRU und den benachbarten ITSs erstens des TII, der widerspiegelt, wie wahrscheinlich die Ego-VRU-ITS-SS-Trajektorie 117 durch die benachbarten ITSs (andere VRU- oder Nicht-VRU-ITSs, wie etwa Fahrzeuge) abgefangen werden wird, und zweitens einer Manöverkennung (MI) ermöglicht werden, um den Typ des benötigten VRU-Manövers anzugeben. Ein MI ist eine Kennung eines Manövers, das in einem Manöverkoordinationsdienst (MCS) 1013 verwendet wird (werden soll). Die Wahl des Manövers kann lokal basierend auf den verfügbaren Sensordaten an der VRU-ITS-S 117 erzeugt werden und kann mit benachbarten ITS-S (z.B. anderen VRUs 116 und/oder Nicht-VRUs) in der Nähe der Ego-VRU-ITS-S 117 geteilt werden, um eine gemeinsame Manöverkoordination zwischen den VRUs 116 zu initiieren (vgl. z.B. Klausel 6.5.10.9 von [TS 103300-3]).
  • In Abhängigkeit von der Analyse der Szene hinsichtlich der sensorischen sowie geteilten Eingaben können einfache TII-Bereiche definiert werden, um die Wahrscheinlichkeit anzugeben, dass der Weg des Ego-VRU 116 von einer anderen Entität abgefangen wird. Eine solche Anzeige hilft dabei, ein rechtzeitiges Manövrieren auszulösen. Beispielsweise könnte TII hinsichtlich des TII-Index definiert werden, der einfach die Chance einer potentiellen Trajektorienabfangung (niedrig, mittel, hoch oder sehr hoch) für die CRA 1016 angeben kann. Falls es mehrere andere Entitäten gibt, kann die TII für die spezifische Entität angegeben werden, die über eine einfache ID unterscheidbar ist, die von der gleichzeitigen Anzahl von Entitäten in der Nähe zu dieser Zeit abhängt. Die Nähe könnte sogar nur ein Cluster sein, in dem sich der aktuelle VRU befindet. Zum Beispiel beträgt die Mindestanzahl von Entitäten oder Benutzern in einem Cluster 50 pro Cluster (schlimmstenfalls). Der Satz von Benutzern, die möglicherweise das Potential haben, mit dem VRU zu kollidieren, könnte jedoch viel kleiner als 50 sein, was somit über wenige Bits in beispielsweise einer VAM angegeben werden kann.
  • Andererseits kann der MI-Parameter bei der Kollisionsrisikovermeidung 1017 hilfreich sein, indem die Art der an den VRUs 116/117 benötigten Manöveraktion ausgelöst/vorgeschlagen wird. Die Anzahl solcher möglicher Manöveraktionen kann nur wenige betragen. Aus Gründen der Einfachheit könnte es auch als die möglichen Handlungen definieren, aus denen gewählt wird {Längstrajektorieänderungsmanöver, seitliches Trajektorieänderungsmanöver, Kursänderungsmanöver oder Notbremsung/Verlangsamung}, um eine durch die TII angezeigte potentielle Kollision zu vermeiden. In verschiedenen Ausführungsformen können die TII- und MI-Parameter auch über die Aufnahme in einen Teil einer VAM-DF-Struktur ausgetauscht werden.
  • Die Ereignisdetektionsfunktion 1018 unterstützt den VBS 1021 während seines Betriebs, wenn er von einem Zustand in einen anderen übergeht. Beispiele für die zu betrachteten Ereignisse umfassen: Änderung einer VRU-Rolle, wenn ein Verkehrsteilnehmer zu einem ungeschützten Verkehrsteilnehmer wird (Aktivierung) oder wenn ein Verkehrsteilnehmer nicht mehr ungeschützt ist (Deaktivierung); Ändern eines VRU-Profils, wenn ein VRU in einen Cluster mit anderen VRU(s) oder mit einem neuen mechanischen Element (z. B. Fahrrad, Roller, Motorrad usw.) eintritt oder wenn ein VRU-Cluster sich auflöst; Kollisionsrisiko zwischen einem oder mehreren VRU(s) und mindestens einem anderen VRU (unter Verwendung eines VRU-Fahrzeugs) oder einem Fahrzeug (ein derartiges Ereignis wird über die Wahrnehmungsfähigkeiten des VRU-Systems detektiert); Änderung der VRU-Bewegungsdynamik (Trajektorie oder Geschwindigkeitsvektor), die sich auf die TTC und die Zuverlässigkeit der vorherigen Vorhersage auswirken wird; und Änderung des Status eines Straßeninfrastrukturteils (z.B. einer Ampelphase), die sich auf die VRU-Bewegungen auswirkt.
  • Zusätzlich oder alternativ können existierende Infrastrukturdienste 1012, wie etwa die hier beschriebenen, im Kontext des VBS 1021 verwendet werden. Zum Beispiel ist der Broadcast der Signalphase und -Timing (SPAT) und des nach SPAT-Relevanz begrenzten Bereichs (KARTE) bereits standardisiert und wird von Fahrzeugen auf Kreuzungsebene verwendet. Im Prinzip schützen sie einander kreuzende VRUs 116/117. Es können jedoch Signalverstoßwarnungen existieren und können unter Verwendung von DENM detektiert und signalisiert werden. Diese Signalverstoßanzeige unter Verwendung von DENMs ist für VRU-Vorrichtungen 117 sehr relevant, da sie eine Zunahme des Kollisionsrisikos mit dem Fahrzeug anzeigt, das das Signal verletzt. Wenn sie lokale Fänger verwendet oder VAMs detektiert und analysiert, kann die Ampelsteuerung die Rotphasenänderung auf Grün verzögern und dem VRU 116/117 ermöglichen, seine Straßenüberquerung sicher zu beenden. Die kontextbezogene Geschwindigkeitsbegrenzung unter Verwendung von fahrzeuginternen Informationen (IVI) kann angepasst werden, wenn ein großer Cluster von VRUs 116/117 detektiert wird (z.B. Begrenzung der Fahrzeuggeschwindigkeit auf 30 km/Stunde). Bei einer derartigen reduzierten Geschwindigkeit kann ein Fahrzeug 110 effizient agieren, wenn es die VRUs mittels seines eigenen lokalen Wahrnehmungssystems wahrnimmt.
  • Die ITS-Verwaltungs- (vrwltngs-) Schicht beinhaltet eine VRU-Profil-vrwltngs-Entität. Die VRU-Profilverwaltungsfunktion ist ein wichtiges Unterstützungselement für den VBS 1021 als Verwaltung des VRU-Profils während einer aktiven VRU-Sitzung. Die Profilverwaltung ist Teil der ITS-S-Konfigurationsverwaltung und wird dann mit erforderlichen typischen Parameterwerten initialisiert, um seinen Betrieb erfüllen zu können. Die ITS-S-Konfigurationsverwaltung ist auch für Aktualisierungen (zum Beispiel: Neue Standardversionen) zuständig, die während des gesamten Lebenszyklus des Systems notwendig sind.
  • Wenn der VBS 1021 aktiviert ist (Ungeschütztheit konfiguriert), muss die VRU-Profilverwaltung ein personalisiertes VRU-Profil basierend auf ihrer Erfahrung und auf einer bereitgestellten anfänglichen Konfiguration (generischer VRU-Typ) charakterisieren. Die VRU-Profilverwaltung kann dann fortfahren, die VRU-Gewohnheiten und Verhaltensweisen mit dem Ziel zu lernen, das Konfidenzniveau (Zuverlässigkeit) zu erhöhen, das mit ihrer Bewegungsdynamik (Trajektorien und Geschwindigkeitsvektoren) und ihren Bewertungsvorhersagen assoziiert ist.
  • Die VRU-Profilverwaltung 1061 ist in der Lage, das VRU-Profil gemäß detektierten Ereignissen anzupassen, die durch die VBS-Verwaltung und die VRU-Clusterverwaltung 1102 (Clusteraufbau/-bildung oder Clusterzersetzung/-auflösung) signalisiert werden können.
  • Gemäß seinem Profil kann ein VRU durch ein Verkehrsinfrastrukturereignis (z.B. Entwicklung einer Ampelphase) beeinflusst werden oder nicht, sodass ermöglicht wird, dass seinen Bewegungen eine bessere Schätzung des Konfidenzniveaus zugeordnet wird. Beispielsweise wartet ein erwachsener Fußgänger wahrscheinlich an einer grünen Ampel, und überquert dann die Straße, wenn die Ampel auf Rot umschaltet. Ein Tier wird sich nicht um die Ampelfarbe kümmern und ein Kind kann gemäß seinem Alter und seinem Bildungsstand warten oder auch nicht.
  • 11 zeigt ein beispielhaftes VBS-Funktionsmodell 1100 gemäß verschiedenen Ausführungsformen. Der VBS 1021 ist eine Entität der Facilities-Schicht, die das VAM-Protokoll betreibt. Er stellt drei Hauptdienste bereit: Handhabung der VRU-Rolle, Senden und Empfangen von VAMs. Der VBS verwendet die Dienste, die von den Protokollentitäten der ITS-Netzwerk- & Transportschicht bereitgestellt werden, um die VAM zu verbreiten.
  • Handhabung der VRU-Rolle: Der VBS 1021 empfängt unaufgefordert Angaben von der VRU-Profilverwaltungsentität (vgl. z.B. Klausel 6.4 in [TS103300-2]) darüber, ob sich der Vorrichtungsbenutzer in einem Kontext befindet, in dem er als VRU (z.B. ein Fußgänger, der eine Straße überquert) betrachtet wird oder nicht (z.B. Fahrgast in einem Bus). Der VBS 1021 bleibt in beiden Zuständen betriebsbereit, wie durch Tabelle 4-1 definiert. Tabelle 4-1: Mögliche Rollen des VRU-Basisdiensthetriehs
    VRU-Rolle Spezifikation Gültige VRU-Profile Gültige VRU-Typen Zusätzliche Erläuterung
    VRU_ROLLE_EI N Der Vorrichtungsbenutzer wird als VRU betrachtet. Basierend auf Informationen, die von der VRU- Profilverwaltungsentität empfangen werden, soll der VBS den Typ von VRU und das Profil des VRU prüfen. Er soll zudem den VBS-Clusterbildungszustand handhaben und anderen Entitäten Dienste bereitstellen, wie in Klausel 5 definiert. ALLE ALLE Der VBS-Zustand sollte gemäß dem Zustand eines VRU- Vorrichtungsbenutzers wie durch die VRU-Profilverwaltungsentität benachrichtigt geändert werden. Die VRU-Vorrichtung kann VAMs senden, VAMs empfangen oder beides, während die Position des VRU-Vorrichtungsbenutzers durch die PoTi-Entität geprüft wird. Mit Ausnahme von VRUs des Profils 3 kann er die VRU- Clusterbildungsfunktionen ausführen (siehe Klausel 5).
    VRU_ROLLE_AU S Der Vorrichtungsbenutzer wird nicht als VRU betrachtet. Die VRU-Vorrichtung soll VAMs weder senden noch empfangen ALLE ALLE Der VRU befindet sich in einem „risikofreien“ geografischen Bereich, zum Beispiel in einem Bus, in einem Personenkraftwagen usw. Der VBS bleibt in diesem Zustand betriebsbereit, um jegliche Benachrichtigung zu überwachen, dass sich die Rolle auf VRU_ROLLE_EIN geändert hat.
  • Es kann Fälle geben, in denen die VRU-Profilverwaltungsentität ungültige Informationen bereitstellt, z.B. wird der VRU-Vorrichtungsbenutzer als VRU betrachtet, während seine Rolle VRU_ROLLE_AUS sein sollte. Dies ist implementierungsabhängig, da die empfangende ITS-S eine sehr starke Pausibilitätsprüfung aufweisen und den VRU-Kontext während ihrer Risikoanalyse berücksichtigen sollte. Die Genauigkeit des Positionsbestimmungssystems (sowohl auf der Übertragungsseite als auch auf der Empfangsseite) hätte ebenfalls einen starken Einfluss auf die Detektion solcher Fälle.
  • Das Senden von VAMs beinhaltet zwei Aktivitäten: Erzeugung von VAMs und Übertragung von VAMs. Bei der VAM-Erzeugung setzt die Ursprungs-ITS-S 117 die VAM zusammen, die dann an die ITS-Netzwerk- und Transportschicht zur Verteilung geliefert wird. Bei der VAM-Übertragung wird die VAM über ein oder mehrere Kommunikationsmedien unter Verwendung eines oder mehrerer Transport- und Vernetzungsprotokolle übertragen. Ein natürliches Modell ist, dass VAMs von der Ursprungs-ITS-S an alle ITS-Ss innerhalb des direkten Kommunikationsbereichs gesendet werden. VAMs werden mit einer Frequenz erzeugt, die durch den steuernden VBS 1021 in der Ursprungs-ITS-S bestimmt wird. Falls sich eine VRU-ITS-S nicht in einem Cluster befindet, oder falls sie ein Clusterführer ist, überträgt sie die VAM periodisch. Die VRU-ITS-S 117, die sich in einem Cluster befinden, aber kein Clusterführer sind, übertragen die VAM nicht. Die Erzeugungsfrequenz wird basierend auf der Änderung des kinematischen Zustands, dem Standort der VRU-ITS-S 117 und einer Überlastung im Funkkanal bestimmt. Sicherheitsmaßnahmen wie etwa Authentifizierung werden während des Übertragungsprozesses in Koordination mit der Sicherheitsentität auf die VAM angewendet.
  • Beim Empfangen einer VAM stellt der VBS 1021 den Inhalt der VAM den ITS-Anwendungen und/oder anderen Anlagen innerhalb der empfangenden ITS-S 117/130/110, wie etwa einer lokalen dynamischen Karte (LDM), zur Verfügung. Er wendet alle notwendigen Sicherheitsmaßnahmen, wie etwa Relevanz- oder Nachrichtenintegritätsprüfung, in Koordination mit der Sicherheitsentität an.
  • Der VBS 1021 beinhaltet eine VBS-Verwaltungsfunktion 1101, eine VRU-Cluster-Verwaltungsfunktion 1102, eine VAM-Empfangsverwaltungsfunktion 1103, eine VAM-Übertragungsverwaltungsfunktion 1104, eine VAM-Codierungsfunktion 1105 und eine VAM-Decodierungsfunktion 1106. Das Vorhandensein einiger oder aller dieser Funktionen hängt vom VRU-Gerätetyp (z.B. VRU-Tx, VRU-Rx oder VRU-St) ab und kann von Ausführungsform zu Ausführungsform variieren.
  • Die VBS-Verwaltungsfunktion 1101 führt die folgenden Operationen aus: Speichern der zugewiesenen ITS-AID und des zugewiesenen Netzwerk-Ports zur Verwendung für den VBS 1021; Speichern der VRU-Konfiguration, die zur Initialisierungszeit empfangen wird oder später für die Codierung von VAM-Datenelementen aktualisiert wird; Empfangen von Informationen von der HMI und Übertragen von Informationen an die HMI; Aktivieren/Deaktivieren des VAM-Übertragungsdienstes 1104 gemäß dem Vorrichtungsrollenparameter (zum Beispiel wird der Dienst deaktiviert, wenn ein Fußgänger in einen Bus einsteigt); und Verwalten der Auslösebedingungen der VAM-Übertragung 1104 in Bezug auf die Netzwerküberlastungssteuerung. Nach der Aktivierung eines neuen Clusters kann zum Beispiel entschieden werden, die Übertragung von Element(en) des Clusters zu stoppen.
  • Die VRU-Cluster-Verwaltungsfunktion 1102 führt die folgenden Operationen durch: Detektieren, ob der zugehörige VRU der führende eines Clusters sein kann; Berechnen und Speichern der Clusterparameter zur Aktivierungszeit für die Codierung von für das Cluster spezifischen VAM-Datenelementen; Verwalten der mit dem VRU assoziierten Zustandsmaschine gemäß detektierten Clusterereignissen (siehe z.B. Zustandsmaschinenbeispiele, die in Abschnitt 6.2.4 von [TS103300-2] bereitgestellt sind); und Aktivieren oder Deaktivieren des Rundsendens der VAMs oder anderer Standardnachrichten (z.B. DENMs) gemäß dem Zustand und den Typen des zugehörigen VRU.
  • Die Clusterbildungsoperation als Teil des VBS 1021 soll die Ressourcennutzung im ITS-System optimieren. Diese Ressourcen sind hauptsächlich Spektrumressourcen und Verarbeitungsressourcen.
  • Eine große Anzahl von VRUs in einem bestimmten Bereich (Fußgängerüberweg in städtischer Umgebung, große Plätze in städtischer Umgebung, Sonderereignisse wie große Fußgängeransammlungen) würde zu einer signifikanten Anzahl einzelner Nachrichten führen, die von der VRU-ITS-S ausgesendet werden, und somit zu einem erheblichen Bedarf an Spektrumressourcen. Zusätzlich müssten alle diese Nachrichten durch die empfangende ITS-S verarbeitet werden, einschließlich potentiellem Aufwand für Sicherheitsoperationen.
  • Um diese Ressourcennutzung zu reduzieren, spezifiziert das vorliegende Dokument Clusterbildungsfunktionalität. Ein VRU-Cluster ist eine Gruppe von VRUs mit einem homogenen Verhalten (siehe ETSI TS 103 300-2 [1]), wobei VAMs in Bezug auf den VRU-Cluster Informationen über den gesamten Cluster bereitstellen. Innerhalb eines VRU-Clusters übernehmen VRU-Vorrichtungen die Rolle entweder eines führenden VRU (einer pro Cluster) oder eines Elements. Eine Führungsvorrichtung sendet VAMs, die Clusterinformationen und/oder Clusteroperationen enthalten. Element-Vorrichtungen senden VAMs, die einen Clusterbetrieb-Container enthalten, um dem VRU-Cluster beizutreten/diesen zu verlassen. Element-Vorrichtungen senden zu einem beliebigen Zeitpunkt keine VAMs, die Clusterinformations-Container enthalten.
  • Ein Cluster kann VRU-Vorrichtungen mehrerer Profile enthalten. Ein Cluster wird als „homogen“ bezeichnet, wenn er Vorrichtungen mit nur einem Profil enthält, und „heterogen“, wenn er VRU-Vorrichtungen mit mehr als einem Profil enthält (z.B. eine gemischte Gruppe von Fußgängern und Fahrradfahrern). Der VAM-Clusterinformations-Container enthält ein Feld, das dem Cluster-Container ermöglicht, anzugeben, welche VRU-Profile im Cluster vorhanden sind. Das Angeben heterogener Cluster ist wichtig, da dies nützliche Informationen über Trajektorie- und Verhaltensvorhersage bereitstellt, wenn der Cluster aufgebrochen wird.
  • Die Unterstützung der Clusterbildungsfunktion ist im VBS 1021 für alle VRU-Profile optional. Die Entscheidung, die Clusterbildung zu unterstützen oder nicht, ist für alle VRU-Profile implementierungsabhängig. Wenn die Bedingungen erfüllt sind (siehe Klausel 5.4.2.4 von [TS103300-3]), wird die Unterstützung von Clusterbildung für das VRU-Profil 1 empfohlen. Eine Implementierung, die Clusterbildung unterstützt, kann dem Vorrichtungseigentümer auch ermöglichen, sie durch Konfiguration zu aktivieren oder nicht. Diese Konfiguration ist ebenfalls implementierungsabhängig. Falls die Clusterbildungsfunktion in der VRU-Vorrichtung unterstützt und aktiviert wird, und nur dann, soll die VRU-ITS-S die in Klausel 5.4.2 und Klausel 7 von [TS103300-3] spezifizierten Anforderungen erfüllen und die in Klausel 5.4.3 von [TS103300-3] spezifizierten Parameter definieren. Infolgedessen werden Clusterparameter im vorliegenden Dokument in zwei spezifische und bedingt obligatorische Container gruppiert.
  • Die als Teil der VRU-Clusterverwaltung 1102 im VBS 1021 durchzuführenden Basisoperationen sind: Clusteridentifikation: Clusterinterne Identifikation durch Cluster-Teilnehmer im Ad-Hoc-Modus; Clustererzeugung: Erzeugung eines Clusters aus VRUs einschließlich VRU-Vorrichtungen, die sich in der Nähe befinden und ähnliche beabsichtigte Richtungen und Geschwindigkeiten aufweisen. Die Einzelheiten der Clustererstellungsoperation sind in Klausel 5.4.2.2 von [TS103300-3] angegeben; Clusteraufbrechen: Auflösen des Clusters, wenn er nicht mehr an dem sicherheitsrelevanten Verkehr teilnimmt oder die Kardinalität unter eine gegebene Schwelle fällt; Clusterbeitritt und -austritt: clusterinterne Operation, Hinzufügen oder Löschen eines einzelnen Elements zu/aus einem bestehenden Cluster; Clustererweiterung oder -verkleinerung: Operation zum Erhöhen oder Verringern der Größe (Fläche oder Kardinalität).
  • Eine beliebige VRU-Vorrichtung soll höchstens einen Cluster führen. Dementsprechend soll ein Clusterführer seinen Cluster aufbrechen, bevor er beginnt, einem anderen Cluster beizutreten. Diese Anforderung gilt auch für kombinierte VRUs wie in [TS103300-2] definiert, die einem anderen Cluster beitreten (z.B. während sie einen Fußgängerüberweg passieren). Der kombinierte VRU kann dann nach Verlassen des heterogenen Clusters nach Bedarf erneut erstellt werden. Falls zum Beispiel ein Fahrradfahrer mit einer VRU-Vorrichtung, der sich gegenwärtig in einem kombinierten Cluster mit seinem Fahrrad befindet, das ebenfalls eine VRU-Vorrichtung aufweist, detektiert, dass er einem größeren Cluster beitreten könnte, bricht der Führer des kombinierten VRU den Cluster auf und beide Vorrichtungen treten jeweils separat dem größeren Cluster bei. Die Möglichkeit, VRU-Cluster oder kombinierte VRUs innerhalb eines VRU-Clusters einzubinden oder zusammenzuführen, bleibt weitergehend zu analysieren. In einigen Implementierungen kann eine einfache bandinterne VAM-Signalisierung für den Betrieb von VRU-Clusterbildung verwendet werden. Weitere Verfahren können definiert werden, um die Assoziierung zwischen Vorrichtungen (z.B. Bluetooth®, UWB usw.) herzustellen, aufrechtzuerhalten und aufzureißen.
  • VRU-Clusterbetrieb. Je nach Kontext befindet sich der VBS 1021 in einem der in Tabelle 4-5 spezifizierten Clusterzustände. Tabelle 4-5: Mögliche Zustände des VRU-Basisdienstes in Bezug auf Clusterbetrieb
    VBS-Zustand Spezifikation Gültige VRU-Profile Gültige VRU-Typen Zusätzliche Erläuterung
    VRU-RUHE Der Vorrichtungsbenutzer wird nicht als VRU betrachtet ALLE ALLE Die VRU-Rolle wie definiert in Klausel 4.2 VON [TS103300-3] ist VRU_ROLLE_AUS.
    VRU-AKTIV-EIGENSTÄNDIG VAMs oder CAMs (im Fall des VRU-Profils 2) werden mit Informationen übertragen, die nur mit diesem VRU zusammenhängen. ALLE VRU-St, VRU-Tx In diesem Zustand kann eine VRU-ITS-S eine Absicht angeben, einem Cluster beizutreten, oder angeben, dass sie gerade einen Cluster verlassen hat.
    VRU-AKTIV-CLUSTER-FÜHRER VAMs werden übertragen und beinhalten einen Container mit spezifischen Datenelementen bezüglich des Clusters VRU-Profil 1, VRU-Profil 2 VRU-St
    VRU-PASSIV Die VRU-Vorrichtung überträgt keine VAMs ALLE außer VRU-Profil 3 VRU-St, VRU-Tx Der VRU ist Element eines Clusters oder befindet sich in einem geographischen Gebiet mit geringem Risiko, das in Klausel 3.1 von [TS103300-3] definiert ist (siehe z.B. FCOM03 in [TS103300-2]). Falls die Bereichsregeln den Verkehr von Kraftfahrzeugen autorisieren, kann der VBS auch im VRU-AKTIVEIGENSTÄNDIG-VBS-Zustand bleiben und die Periodizität der VAMs erhöhen.
  • Zusätzlich zu den in Klausel 6 von [TS103300-3] definierten normalen VAM-Auslösebedingungen lösen die folgenden Ereignisse einen VBS-Zustandsübergang in Bezug auf Clusterbetrieb aus. Parameter, die diese Ereignisse steuern, sind in Klausel 8 von [TS103300-3], Tabelle 1.5.4-23 und Tabelle 1.5.4-24 zusammengefasst.
  • Eintreten in die VRU-Rolle: VRU-RUHE. Wenn der VBS 1021 in VRU-RUHE bestimmt, dass der VRU-Vorrichtungsbenutzer seine Rolle auf VRU_ROLLE_EIN geändert hat (z.B. durch Verlassen eines Busses), soll er die Übertragung von VAMs starten, wie in Klausel 4.2 definiert. Ein VBS 1021, der diesen Übergang ausführt, darf zu keinem Cluster gehören. Nächster Zustand: VRU-AKTIV-EIGENSTÄNDIG
  • VRU-Rolle verlassen: VRU-AKTIV-EIGENSTÄNDIG. Wenn der VBS 1021 in VRU-AKTIV-EIGENSTÄNDIG bestimmt, dass der VRU-Vorrichtungsbenutzer seine Rolle auf VRU_ROLLE_AUS geändert hat (z.B. durch Einsteigen in einen Bus oder einen Personenkraftwagen), soll er die Übertragung von VAMs stoppen, wie in Klausel 4.2 von [TS103300-3] definiert. Ein VBS 1021, der diesen Übergang ausführt, darf zu keinem Cluster gehören. Nächster Zustand: VRU-RUHE.
  • Erzeugen eines VRU-Cluster-Anfangszustands: VRU-AKTIV EIGENSTÄNDIG. Wenn der VBS 1021 in VRU-AKTIV-EIGENSTÄNDIG basierend auf den empfangenen VAMs von anderen VRUs bestimmt, dass er einen Cluster bilden kann (siehe Bedingungen in Klausel 5.4.2.4 von [TS103300-3]), ergreift er die folgenden Maßnahmen: 1) Erzeugen einer zufälligen Clusterkennung. Die Kennung soll lokal eindeutig sein, d.h. sie soll sich von einer beliebigen Clusterkennung in einer VAM unterscheiden, die durch den VBS 1021 in der letzten ZeitClusterEindeutigkeitSchwelle-Zeit empfangen wird, und sie soll ungleich null sein. Die Kennung muss nicht global eindeutig sein, da ein Cluster eine lokale Entität ist und erwartet werden kann, dass er für einen kurzen Zeitrahmen besteht. 2) Bestimmen einer anfänglichen Clusterabmessung, um den Clusterbegrenzungsrahmen zu begrenzen. Um falsch-Positive zu vermeiden, soll der anfängliche Begrenzungsrahmen so eingestellt werden, dass er nur den Clusterführer-VRU beinhaltet. 3) Einstellen der Größe des Clusters auf minClusterGröße und des VRU-Clusterprofilfeldes auf sein eigenes VRU-Profil. 4) Übergang in den nächsten Zustand, d.h. Starten des Übertragens von Cluster-VAMs. Die zufällige Auswahl der Cluster-ID schützt vor dem Fall, in dem zwei Clusterführer, die gleichzeitig eine ID auswählen, dieselbe Kennung auswählen. Die Clustererstellung unterscheidet sich von der Clustererstellung wie in Klausel 5.4.2.4 von [TS103300-3] definiert, darin, dass eine VRU-Vorrichtung, die einem Cluster beitritt, vorab inen Hinweis angibt, dass sie dem Cluster beitreten wird, während eine VRU-Vorrichtung, die einen Cluster erzeugt, einfach vom Senden einzelner VAMs zum Senden von Cluster-VAMs umschaltet. Nächster Zustand: VRU-AKTIV-CLUSTER-FÜHRER
  • Aufbrechen eines VRU-Clusters: Anfangszustand: VRU-AKTIV-CLUSTER-FÜHRER Wenn der VBS 1021 im Zustand VRU-AKTIV-CLUSTER-FÜHRER bestimmt, dass er den Cluster aufbrechen sollte, soll er in den Cluster-VAMs ein VRU-Clusterbetrieb-Feld beinhalten, das angibt, dass er den Cluster mit der Kennung des VRU-Clusters auflössen wird, sowie einen Grund für das Aufbrechen des VRU-Clusters (Siehe Klausel 7.3.5 für die Liste möglicher Gründe). Er soll dann kurz das Senden von Cluster-VAMs stoppen. Diese Angabe wird für ZeitClusterAufbruchWarnung in aufeinanderfolgenden VAMs übertragen. Alle VRU-Vorrichtungen im Cluster sollen das Senden individueller VAMs wieder aufnehmen (z.B. gehen sie in den Zustand VRU-AKTIV-EIGENSTÄNDIG über). Andere VRUs können dann versuchen, neue Cluster mit sich selbst als Führer zu bilden, wie vorstehend spezifiziert. Nächster Zustand: VRU-AKTIV-EIGENSTÄNDIG.
  • Beitreten zu einem VRU-Cluster: Anfangszustand: VRU-AKTIV-EIGENSTÄNDIG. Wenn eine VRU-Vorrichtung Cluster-VAMs von einem Clusterführer empfängt, soll der VBS 1021 in VRU-AKTIV-EIGENSTÄNDIG die empfangenen Cluster-VAMs analysieren und entscheiden, ob er dem Cluster beitreten sollte oder nicht (siehe Bedingungen in Klausel 5.4.2.4 von [TS103300-3]). Das Beitreten zu einem Cluster ist eine optionale Operation. Vor dem Beitreten zu dem Cluster soll der VRU in seinen individuellen VAMs eine Angabe beinhalten, dass er dem identifizierten Cluster beitritt, zusammen mit einer Angabe der Zeit, zu der er beabsichtigt, das Senden einzelner VAMs zu stoppen. Er soll diese Angaben für eine Zeit ZeitClusterBeitrittBenachrichtigung senden. Sobald der VRU die geeignete Anzahl von Benachrichtigungen gesendet hat, tritt er in den Cluster ein, d.h. er stoppt die Übertragung und startet das Überwachen der Cluster-VAMs vom Clusterführer.
  • Handhabung stornierter Beitritte: Falls der VBS 1021 bestimmt, dass er nicht dem Cluster beitreten wird, nachdem er die Zusammenstellungsoperation gestartet hat (zum Beispiel weil er eine VAM mit überschrittener maximaler Clustergröße (Kardinalität) maxClusterGröße empfängt), stoppt er das Aufnehmen der Cluster-Beitrittsbenachrichtigung in seinen individuellen VAMs und bindet die Cluster-Austrittsbenachrichtigung für eine Zeit ZeitClusterAustrittBenachrichtigung ein. Dies ermöglicht es dem Clusterführer, die Größe seines Clusters zu verfolgen.
  • Handhabung fehlgeschlagener Beitritte: Falls nach dem Beenden des Sendens individueller VAMs der VBS 1021 bestimmt, dass der Clusterführer den Clusterzustand nicht so aktualisiert hat, dass er dieses neue Element enthält (z.B. befindet sich die Vorrichtung nicht innerhalb der Begrenzungsrahmen-Informationen, die in der empfangenen Cluster-VAM vom Clusterführer bereitgestellt werden, oder die Größe ist nicht mit beobachteten Clusterbeitritts- und -austritts-Benachrichtigungen konsistent), oder der Cluster, dem er beitreten wollte, nicht mehr existiert, verlässt der VBS 1021 den Cluster (z.B. startet er wieder das Übertragen individueller VAMs und verbleibt im VRU-AKTIV-EIGENSTANDIG-Zustand). Der VBS 1021 nimmt diese Aktion vor, wenn die erste Cluster-VAM, die nach ZeitClusterBeitrittErfolg empfangen wird, den Ego-VBS 1021 nicht berücksichtigt. Wenn der Ego-VBS 1021 einzelne VAMs nach einem stornierten Beitritt oder einem fehlgeschlagenen Beitritt überträgt, a) verwendet er dieselbe Station-ID, die er vor dem stornierten Beitritt oder dem fehlgeschlagenen Beitritt verwendete; und b) bindet er die Cluster-Austrittsbenachrichtigung für eine Zeit ZeitClusterAustrittBenachrichtigung ein. Eine VRU-ITS-S, die einen „fehlgeschlagenen Beitritt“ dieses Typs erfährt, kann weitere Versuche machen, dem Cluster beizutreten. Jeder Versuch soll dem in diesem Übergangsfall definierten Prozess folgen. Eine VRU-Vorrichtung kann bestimmen, dass sie sich innerhalb eines Clusterbegrenzungsrahmens befindet, der durch eine andere Nachricht als eine VAM (zum Beispiel eine CPM) angegeben wird. In diesem Fall soll sie dem vorliegend beschriebenen Cluster-Beitrittsprozess folgen, soll aber den speziellen Wert „0“ als Kennung des Clusters bereitstellen, dem sie beitritt. Nächster Zustand: VRU-PASSIV.
  • Verlassen eines VRU-Clusters: Anfangszustand: VRU-PASSIV. Wenn ein VRU in einem Cluster VAMs von dem VRU-Clusterführer empfängt, analysiert der VBS 1021 die empfangenen VAMs und entscheidet, ob er den Cluster verlassen sollte oder nicht (siehe Klausel 5.4.2.4 von [TS103300-3]). Das Verlassen des Clusters besteht im Wiederaufnehmen des Sendens individueller VAMs. Wenn die VRU-ITS-S den Cluster verlässt, sollen die VAMs, die sie sendet, nachdem der Zustand VRU-PASSIV endet, angeben, dass sie den identifizierten Cluster verlässt, zusammen mit einem Grund, warum sie den identifizierten Cluster verlässt (siehe Klausel 7.3.5 von [TS103300-3] aus der Liste der Gründe). Sie soll diese Angabe für die Zeit ZeitClusterAustrittBenachrichtigung beinhalten. Es ist einem VRU stets erlaubt, einen Cluster aus beliebigem Grund zu verlassen, einschließlich seiner eigenen Entscheidung oder einem identifizierten Sicherheitsrisiko. Nachdem ein VRU einen Cluster verlässt und mit dem Senden individueller VAMs beginnt, sollte er andere Kennungen (einschließlich Station-ID in der VAM und dem Pseudonymzertifikat) als diejenigen verwenden, die er in individuellen VAMs verwendet hat, die gesendet wurden, bevor er dem Cluster beigetreten ist. Ausnahme: Wenn der VRU einen stornierten Beitritt oder einen fehlgeschlagenen Beitritt erfährt, wie vorstehend spezifiziert (im „Beitreten zu einem VRU-Cluster“-Übergang), sollte er die Station-ID und andere Kennungen verwenden, die er vor dem fehlgeschlagenen Beitrittverwendet hat, um eine bessere Verfolgung durch den Clusterführer des Zustands des Clusters für eine Anzahl AnzClusterVAMWiederholung von VAMs zu ermöglichen, und danach die Pseudonymisierung seiner Station-ID wieder aufnehmen. Eine VRU-Vorrichtung, die sich im VRU-PASSIV-Zustand und innerhalb eines Clusters befindet, der durch eine andere Nachricht als eine VAM (z.B. eine CPM) angegeben wird, kann entscheiden, das Senden der VAM wieder aufzunehmen, da sie bestimmt hat, dass sie sich innerhalb des Clusters befand, der durch die andere Nachricht angegeben wird, nun aber diesen Clusterbegrenzungsrahmen verlassen wird oder verlassen hat. In diesem Fall soll sie dem hier beschriebenen Clusteraustrittsprozess folgen und den speziellen Clusteridentifikatorwert „0“ angeben. Nächster Zustand: VRU-AKTIV-EIGENSTÄNDIG
  • Bestimmen eines verlorenen VRU-Clusterführers: In einigen Fällen kann der VRU-Clusterführer die Kommunikationsverbindung verlieren oder als Knoten ausfallen. In diesem Fall kann der VBS 1021 des Clusterführers VAMs im Auftrag des Clusters nicht mehr senden. Wenn ein VBS 1021 aufgrund von Clusterbildung im VRU-PASSIV-Zustand bestimmt, dass er VAMs vom VRU-Clusterführer für eine Zeit ZeitClusterKontinuität nicht empfangen hat, soll er annehmen, dass der VRU-Clusterführer verloren gegangen ist, und soll den Cluster verlassen, wie zuvor spezifiziert. Nächster Zustand: VRU-AKTIV-EIGENSTÄNDIG
  • Die folgenden Aktionen lösen keinen Zustandsübergang aus, sondern sollen eine Aktualisierung von Informationen bewirken.
  • Erweitern oder Verkleinern eines VRU-Clusters: Zustand: VRU-AKTIV-CLUSTER-FÜHRER Eine VAM, die angibt, dass ein VRU dem Cluster beitritt, ermöglicht es dem VRU-Clusterführer, zu bestimmen, ob der Cluster homogen oder heterogen ist, sein Profil, Begrenzungsrahmen, Geschwindigkeitsvektor und Referenzposition usw. Die Cluster-Datenelemente in der Cluster-VAM sollen durch den VRU-Clusterführer aktualisiert werden, um den neuen VRU aufzunehmen. Das gleiche gilt, wenn ein VRU den Cluster verlässt.
  • Ändern einer VRU-Cluster-ID: Zustand: VRU-AKTIV-CLUSTER-FÜHRER, VRU-PASSIV. Ein Clusterführer kann die Cluster-ID zu einem beliebigen Zeitpunkt und aus beliebigem Grund ändern. Der Clusterführer soll in seinen VAMs eine Angabe, dass sich die Cluster-ID ändern wird, für die Zeit ZeitClusterldAnderungBenachrichtigung einbinden, bevor die Änderung implementiert wird. Die Benachrichtigung gibt den Zeitpunkt an, zu dem die Änderung stattfinden wird. Der Clusterführer soll eine Cluster-VAM mit der neuen Cluster-ID so bald wie möglich nach der ID-Änderung übertragen. VRU-Vorrichtungen im Cluster sollen zu dieser Zeit beobachten, ob es einen Cluster mit einer neuen ID gibt, der ähnliche Begrenzungsrahmen und dynamische Eigenschaften wie der vorherige Cluster aufweist. Wenn es einen solchen Cluster gibt, sollen die VRU-Vorrichtungen ihre interne Aufzeichnung der Cluster-ID auf die neu beobachtete Cluster-ID aktualisieren. Wenn es keinen solchen Cluster gibt, sollen die VRU-Vorrichtungen den Austrittsprozess in Bezug auf das alte Cluster ausführen. VRU-Vorrichtungen, die einen Cluster verlassen, der kürzlich die ID geändert hat, können entweder die alte oder die neue Cluster-ID in ihrer Austrittsanzeige für die Zeit ZeitClusterldFortdauer verwenden. Nach dieser Zeit sollen sie nur die neue Cluster-ID verwenden. Falls der VBS 1021 eines Clusterführers eine VAM von einem anderen VRU mit der gleichen Kennung wie seine eigene empfängt, soll er unter Einhaltung des im vorstehenden Absatz beschriebenen Prozesses unmittelbar eine Änderung der Cluster-ID auslösen.
  • Die Übertragung der Absicht, die Cluster-ID zu ändern, hat keine wesentlichen Auswirkungen hinsichtlich Datenschutz. Dies liegt daran, dass ein Mithörer, der versucht, einen Cluster zu verfolgen, und die Cluster-VAMs zum Zeitpunkt einer ID-Änderung abhört, in der Lage ist, Kontinuität des Clusters dennoch zu bestimmen, und zwar durch „Zusammenfügen der Punkte“ seiner Trajektorie durch die ID-Änderung unter Verwendung der dynamischen Informationen. Eine ID-Änderung soll hauptsächlich vor einem Mithörer schützen, der nicht kontinuierlich lauscht, sondern stattdessen die Fähigkeit aufweist, nur an diskreten, isolierten Orten mitzuhören. Für dieses Mithörermodell erhöht ein Einbinden einer „Änderung vorbereiten“-Benachrichtigung für kurze Zeit nicht wesentlich die Wahrscheinlichkeit, dass der Mithörer in der Lage sein wird, den Cluster durch die ID-Änderung zu verfolgen. Die neue Cluster-ID wird in der Benachrichtigung nicht bereitgestellt, sondern nur die Zeit, zu der sich die ID ändern soll.
  • Bedingungen zum Bestimmen, ob ein Cluster erzeugt werden soll: Eine VRU-Vorrichtung mit einem VBS 1021 in VRU-AKTIV-EIGENSTÄNDIG kann einen Cluster erzeugen, falls alle diese Bedingungen erfüllt sind: Sie weist eine ausreichende Verarbeitungsleistung auf (angegeben in der von der VRU-Profilverwaltungsfunktion empfangenen VRU-Konfiguration). Sie wurde mit einem VRU-Gerätetyp VRU-St konfiguriert (wie in Klausel 4.4 von [TR103300-1] definiert). Sie empfängt VAMs von AnzErstelleCluster verschiedenen VRUs nicht weiter entfernt als maxClusterAbstand. Sie konnte keinen Cluster identifizieren, dem sie beitreten könnte. Eine andere mögliche Bedingung ist, dass die VRU-ITS-S eine Angabe von einer benachbarten V-ITS-S oder R-ITS-S empfangen hat, dass ein Cluster erzeugt werden sollte.
  • Bedingungen zum Bestimmen unter normalen Bedingungen, ob einem Cluster beigetreten oder dieser verlassen werden soll: eine VRU-Vorrichtung, deren VBS 1021 sich im VRU-AKTIV-EIGENSTÄNDIG-Zustand befindet, soll bestimmen, ob sie einem Cluster beitreten kann oder diesen verlassen sollte, indem sie seine gemessene Position und seinen kinematischen Zustand mit der Position und dem kinematischen Zustand vergleicht, die in der VAM des VRU-Clusterführers angegeben sind. Das Beitreten zu einem Cluster ist eine optionale Operation.
  • Falls die verglichenen Informationen bestimmte Bedingungen erfüllen, d.h. der Cluster hat seine maximale Größe (Kardinalität) maxClusterGröße nicht erreicht, der VRU befindet sich innerhalb des VRU-Clusterbegrenzungsrahmens oder in einem bestimmten Abstand maxClusterAbstand von dem VRU-Clusterführer entfernt und eine Geschwindigkeitsvektordifferenz ist kleiner als maxClusterGeschwindigkeitsvektorDifferenz des eigenen Geschwindigkeitsvektors, kann die VRU-Vorrichtung dem Cluster beitreten.
  • Nach dem Beitreten zum Cluster soll die VRU-Vorrichtung, wenn die verglichenen Informationen die vorherigen Bedingungen nicht mehr erfüllen, den Cluster verlassen. Wenn ihre Rolle zu Nicht-VRU geändert wird (z.B. durch Einsteigen in einen Bus oder ein Personenkraftfahrzeug), soll die VRU-Vorrichtung zudem dem in Klausel 5.4.2.2 von [TS103300-3] beschriebenen Austrittsprozess folgen. Falls die VRU-Vorrichtung VAMs von zwei verschiedenen Clustern empfängt, die dieselbe Cluster-ID aufweisen (z.B. aufgrund eines verborgenen Knotens), soll sie keinem der beiden Cluster beitreten. Falls der VBS 1021 nach dem Verlassen eines VRU-Clusters bestimmt, dass er in einen geographischen Bereich mit geringem Risiko eingetreten ist, wie in Klausel 3.1 von [TS103300-3] definiert (z.B. durch den Empfang einer MAPEM), soll sie gemäß Anforderung FCOM03 in [TS103300-2] in den VRU-PASSIV-Zustand übergehen (vgl. Klausel 6 von [TS103300-3]). Der VBS 1021 gibt in der VAM den Grund an, warum er einen Cluster verlässt, wie in Klausel 7.3.5 von [TS103300-3] definiert.
  • In einigen Fällen kann das Zusammenführen von VRU-Clustern eine VRU-Nachrichtenübermittlung im Netzwerk weiter reduzieren. Beispielsweise können sich bewegende VRU-Cluster auf einem Fußgängerweg mit ähnlichen kohärenten Clustergeschwindigkeitsvektorprofilen vollständig oder teilweise überlappende Begrenzungsrahmen aufweisen (siehe Klausel 5.4.3 von [TS103300-3]) und können sich somit vereinen, um einen größeren Cluster zu bilden. Dies soll wie in Klausel 5.4.1 von [TS103300-3] spezifiziert erfolgen, d.h. der zweite Clusterführer soll seinen Cluster aufbrechen, in einen VRU-AKTIV-EIGENSTÄNDIG-Zustand eintreten und als individueller VRU dem neuen Cluster beitreten. Alle Vorrichtungen, die Teil des Clusters waren, der durch den zweiten Clusterführer geführt wurde, werden zu individuellen VRUs (d.h. treten in einen VRU-AKTIV-EIGENSTÄNDIG-Zustand ein) und können einzeln auswählen, dem Cluster beizutreten, der durch den ersten Clusterführer geführt wird.
  • Die VAM-Empfangsverwaltungsfunktion 1103 führt die folgenden Operationen nach dem Decodieren von VAM-Nachrichten durch: Prüfen der Relevanz der empfangenen Nachricht gemäß ihren aktuellen Mobilitätseigenschaften und ihrem aktuellen Zustand; Prüfen der Konsistenz, Plausibilität und Integrität (vgl. die Verbindung mit Sicherheitsprotokollen) der empfangenen semantischen Nachricht; und Vernichten oder Speichern der empfangenen Nachrichtendatenelemente in der LDM gemäß vorherigen Operationsergebnissen.
  • Die VAM-Übertragungsverwaltungsfunktion 1104 ist nur auf VRU-Vorrichtungsebene verfügbar, nicht auf der Ebene anderer ITS-Elemente, wie etwa V-ITS-Ss 110 oder R-ITS-Ss 130. Selbst auf VRU-Vorrichtungsebene ist diese Funktion in Abhängigkeit von ihrer anfänglichen Konfiguration möglicherweise nicht vorhanden (siehe Vorrichtungsrollen-Einstellfunktion 1011). Die VAM-Übertragungsverwaltungsfunktion 1104 führt auf Anfrage der VBS-Verwaltungsfunktion 1101 die folgenden Operationen durch: Zusammenstellen der Nachrichtendatenelemente in Übereinstimmung mit der Nachrichtenstandardspezifikation; und Senden der erstellten VAM an die VAM-Codierungsfunktion 1105. Die VAM-Codierungsfunktion 1105 codiert die Datenelemente, die von der VAM-Übertragungsverwaltungsfunktion 1104 bereitgestellt werden, in Übereinstimmung mit der VAM-Spezifikation. Die VAM-Codierungsfunktion 1105 steht nur zur Verfugung, falls die VAM-Übertragungsverwaltungsfunktion 1104 verfügbar ist.
  • Die VAM-Decodierungsfunktion 1106 extrahiert die relevanten Datenelemente, die in der empfangenen Nachricht enthalten sind. Diese Datenelemente werden dann der VAM-Empfangsverwaltungsfunktion 1103 kommuniziert. Die VAM-Decodierungsfunktion 1106 steht nur zur Verfügung, falls die VAM-Empfangsverwaltungsfunktion 1103 verfügbar ist.
  • Ein VRU kann mit einem VRU-Profil konfiguriert sein. VRU-Profile sind die Grundlage für die weitere Definition der VRU-Funktionsarchitektur. Die Profile werden aus den verschiedenen vorliegend besprochenen Anwendungsfällen abgeleitet. VRUs 116 beziehen sich üblicherweise auf Lebewesen. Ein Lebewesen wird nur dann als VRU betrachtet, wenn es sich im Kontext einer sicherheitsrelevanten Verkehrsumgebung befindet. Zum Beispiel ist ein in einem Haus befindliches Lebewesen kein VRU, bis es sich in der Nähe einer Straße (z.B. 2m oder 3m) befindet, wobei es zu diesem Zeitpunkt Teil des sicherheitsbezogenen Kontexts ist. Dies ermöglicht, dass die Kommunikationsmenge begrenzt wird, zum Beispiel muss eine C-ITS-Kommunikationsvorrichtung nur beginnen, als eine VRU-ITS-S zu fungieren, wenn das mit ihm assoziierte Lebewesen beginnt, in der Rolle eines VRU zu agieren.
  • Ein VRU kann mit einer tragbaren Vorrichtung ausgestattet sein. Der Begriff „VRU“ kann verwendet werden, um sowohl auf einen VRU als auch seine VRU-Vorrichtung zu verweisen, es sei denn, der Kontext gibt etwas anderes vor. Die VRU-Vorrichtung kann anfänglich konfiguriert sein und kann sich während ihres Betriebs im Anschluss an Kontextänderungen, die spezifiziert werden müssen, entwickeln. Dies gilt insbesondere für das Einrichten des VRU-Profils und des VRU-Typs, die automatisch beim Einschalten oder über ein HMI erreicht werden können. Die Änderung des Straßenbenutzer-Vulnerabilitätszustands muss zudem bereitgestellt werden, um den VBS zu aktivieren, wenn der Straßenbenutzer vulnerabel/ungeschützt wird, oder ihn zu deaktivieren, wenn er in einen geschützten Bereich eintritt. Die Anfangskonfiguration kann automatisch eingerichtet werden, wenn die Vorrichtung eingeschaltet wird. Dies kann für folgenden VRU-Gerätetyp der Fall sein: VRU-Tx mit der einzigen Kommunikationsfähigkeit zum Senden von Nachrichten und Erfüllen der Kanalüberlastungssteuerregeln; VRU-Rx mit der einzigen Kommunikationsfähigkeit zum Empfangen von Nachrichten; und/oder VRU-St mit Vollduplex-Kommunikationsfähigkeiten. Während des Betriebs kann sich das VRU-Profil zudem aufgrund von Clusterung oder Deassemblierung ändern. Folglich wird die VRU-Vorrichtungsrolle in der Lage sein, sich gemäß den Änderungen des VRU-Profils zu entwickeln.
  • Die folgenden Profilklassifizierungsparameter können verwendet werden, um unterschiedliche VRUs 116 zu klassifizieren:
    • • Maximale und mittlere (z.B. typische) Geschwindigkeitswerte (können z.B. mit ihrer Standardabweichung vorliegen).
    • • Minimaler und mittlerer (z.B. typische) Kommunikationsbereich. Der Kommunikationsbereich kann basierend auf der Annahme berechnet werden, dass eine Bewusstmachungszeit von 5 Sekunden benötigt wird, um die Verkehrsteilnehmer zu informieren/auf diese einzuwirken.
    • • Umgebung oder Art des Bereichs (z.B. Stadt, Vorort, Land, Autobahn usw.).
    • • Durchschnittliche Gewichtung und Standardabweichung.
    • • Direktivität/Trajektoriemehrdeutigkeit (geben das Konfidenzniveau der Vorhersagbarkeit des Verhaltens des VRU in seinen Bewegungen an).
    • • Clustergröße: Anzahl der VRUs 116 im Cluster. Ein VRU kann einen Cluster führen und dann seine Größe angeben. In einem solchen Fall kann eine Position des führenden VRU als Referenzposition des Clusters bestimmt werden.
  • Diese Profilparameter sind keine dynamischen Parameter, die in internen Tabellen beibehalten werden, sondern Angaben typischer Werte, die verwendet werden sollen, um die VRUs 116 zu klassifizieren und das Verhalten eines VRU 116, der zu einem spezifischen Profil gehört, zu evaluieren. Beispielhafte VRU-Profile können wie folgt sein:
    • • VRU-Profil 1 - Fußgänger. VRUs 116 in diesem Profil können beliebige Verkehrsteilnehmer aufweisen, die keine mechanische Vorrichtung verwenden, und beinhalten zum Beispiel Fußgänger auf einem Fußgängerweg, Kinder, Kinderwägen, Personen mit Behinderung, blinde Personen, die durch einen Hund geführt werden, ältere Personen, Radfahrer, die nicht auf ihren Fahrrädern sitzen, und dergleichen.
    • • VRU-Profil 2 - Fahrradfahrer. Die VRUs 116 in diesem Profil können Fahrradfahrer und ähnliche Leichtfahrzeugführer, möglicherweise mit einem Elektromotor, beinhalten. Dieses VRU-Profil beinhaltet Fahrradfahrer und auch Einräder, Rollstuhlfahrer, Pferde mit Reiter, Skater, E-Roller, Segways usw. Es sollte beachtet werden, dass das Leichtfahrzeug selbst keinen VRU darstellt, sondern nur in Kombination mit einer Person den VRU bildet.
    • • VRU-Profil 3 - Motorradfahrer. VRUs 116 in diesem Profil können Motorradfahrer beinhalten, die mit Maschinen ausgestattet sind, die es ihnen ermöglichen, sich auf der Straße zu bewegen. Dieses Profil beinhaltet Benutzer (z.B. Fahrer und Mitfahrer, z.B. Kinder und Tiere) von mit angetriebenen Zweirädern (PTW, Powered Two Wheelers), wie etwa Mopeds (motorisierte Roller), Motorräder oder Beiwägen, und kann auch vierfahrende Geländefahrzeuge (ATVs, All-Terrain Vehicles), Schneemobile (oder Schnemaschinen), Jet-Skis für Wasserumgebungen und/oder andere ähnliche angetriebene Fahrzeuge beinhalten.
    • • VRU-Profil 4 - Tiere, die für andere Verkehrsteilnehmer ein Sicherheitsrisiko darstellen. Die VRUs 116 in diesem Profil können Hunde, wilde Tiere, Pferde, Kühe, Schafe usw. beinhalten. Einige dieser VRUs 116 könnten ihre eigene ITS-S (z.B. Hund in einer Stadt oder ein Pferd) oder andere Art von Vorrichtung (z.B. GPS-Modul in Hundehalsband, implantierte RFID-Tags usw.) aufweisen, die meisten der VRUs 116 in diesem Profil werden jedoch nur indirekt detektiert (z.B. wilde Tiere in ländlichen Gebieten und Autobahnszenarien). Cluster von Tier-VRUs 116 könnten Herden von Tieren sein, wie eine Herde von Schafen, Kühen oder Wildschweinen. Dieses Profil hat eine niedrigere Priorität, wenn Entscheidungen getroffen werden müssen, um einen VRU zu schützen.
  • Punkt-zu-Mehrfachpunkt-Kommunikation, wie in ETSIEN 302 636-4-1 v 1.3.1 (2017-08) (im Folgenden „[EN302634-4-1]“), ETSI EN 302 636-3 v1.1.2 (2014-03) (im Folgenden „[EN302636-3]“) erörtert, kann zum Übertragen von VAMs verwendet werden, wie in ETSI TS 103 300-3 V0.1.11 (2020-05) (im Folgenden „[TS103300-3]“) spezifiziert.
  • Frequenz-/Periodizitätsbereich von VAMs. Ein VAM-Erzeugungsereignis führt zur Erzeugung einer VAM. Die minimale Zeit, die zwischen dem Start aufeinanderfolgender VAM-Erzeugungsereignisse verstrichen ist, ist gleich oder größer als T_ErzVam. T_ErzVam ist auf T_ErzVamMin ≤ T_ErzVam ≤T_ErzVamMax beschränkt, wobei T_ErzVamMin und T ErzVamMax in Tabelle 11 spezifiziert sind (Abschnitt 8). Wenn eine Cluster-VAM übertragen wird, könnte die T_ErzVam kleiner sein als die einer individuellen VAM
  • Im Fall von ITS-G5 wird T_ErzVam gemäß den Kanalnutzungsanforderungen der Dezentralen Überlastungssteuerung (DCC, Decentralized Congestion Control) verwaltet, wie in ETSI TS 103 175 spezifiziert. Der Parameter T_ErzVam wird von der VBS-Verwaltungsentität in der Einheit Millisekunden bereitgestellt. Stellt die Verwaltungsentität diesen Parameter mit einem Wert über T_ErzVamMax bereit, so wird T_ErzVam auf T_ErzVamMax gesetzt, und falls der Wert unter T_ErzVamMin liegt oder falls dieser Parameter nicht bereitgestellt wird, wird T_ErzVam wird auf T_ErzVamMin gesetzt. Der Parameter T _ErzVam stellt die aktuell gültige Untergrenze für die Zeit dar, die zwischen aufeinanderfolgenden VAM-Erzeugungsereignissen verstrichen ist.
  • Im Fall von C-V2X PC5 wird T_ErzVam gemäß dem durch die Zugangsschicht in ETSI TS 103 574 definierten Überlaststeuermechanismus verwaltet.
  • Auslösebedingungen. Verwaltung der Übertragung individueller VAMs durch VBS an der VRU-ITS-S. Das erste Mal, wenn eine individuelle VAM unmittelbar oder zum frühesten Zeitpunkt zur Übertragung erzeugt wird, falls eine der folgenden Bedingungen erfüllt ist und die individuelle VAM-Übertragung keinen Redundanzabschwächungstechniken unterliegt:
    1. 1. Ein VRU 116 befindet sich im VRU-RUHE-VBS-Zustand und ist in VRU-AKTIV-EIGENSTÄNDIG eingetreten
    2. 2. Ein VRU 116/117 befindet sich im VRU-PASSIV-VBS-Zustand; hat entschieden, den Cluster zu verlassen und in den VRU-AKTIV-EIGENSTÄNDIG-VBS-Zustand einzutreten.
    3. 3. Ein VRU 116/117 befindet sich im VRU-PASSIV-VBS-Zustand; VRU hat bestimmt, dass ein oder mehrere neue Fahrzeuge oder andere VRUs 116/117 (z.B. VRU-Profil 3 - Motorradfahrer) seitlich näher als ein minimaler sicherer Seitenabstand (MSLaD), in Längsrichtung näher als ein minimaler sicherer Längsabstand (MSLoD) und vertikal näher als ein minimaler sicherer Vertikalabstand (MSVD) gekommen ist; und hat bestimmt, den Cluster zu verlassen und in den VRU-AKTIV-EIGENSTÄNDIG-VBS-Zustand einzutreten, um eine sofortige VAM zu übertragen.
    4. 4. Ein VRU 116/117 befindet sich im VRU-PASSIV-VBS-Zustand; hat bestimmt, dass der VRU-Clusterführer verloren gegangen ist, und hat entschieden, in den VRU-AKTIV-EIGENST ÄNDIG- VBS-Zustand einzutreten.
    5. 5. Ein VRU 116/117 befindet sich im VRU-AKTIV-CLUSTERFÜHRER-VBS-Zustand; hat bestimmt, den Cluster aufzubrechen, und hat eine VRU-Cluster-VAM mit einer Auflösungsanzeige übertragen; und hat entschieden, in einen VRU-AKTIV-EIGENSTANDIG-VBS-Zustand einzutreten.
  • Aufeinanderfolgende VAM-Übertragung ist von Bedingungen wie vorliegend beschrieben abhängig. Aufeinanderfolgende individuelle VAM-Erzeugungsereignisse treten in einem Intervall gleich oder größer als T_ErzVam auf. Eine individuelle VAM wird zur Übertragung als Teil eines Erzeugungsereignisses erzeugt, falls sich die Ursprungs-VRU-ITS-S 117 immer noch im VBS-VRU-AKTIV-EIGENSTÄNDIG-VBS-Zustand befindet, eine beliebige der folgenden Bedingungen erfüllt ist und eine individuelle VAM-Übertragung keinen Redundanzabschwächungstechniken unterliegt:
    1. 1. Die verstrichene Zeit seit dem letzten Mal, als die individuelle VAM übertragen wurde, überschreitet T_ErzVamMax.
    2. 2. Der euklidische absolute Abstand zwischen der aktuellen geschätzten Position des Referenzpunkts des VRU und der geschätzten Position des Referenzpunkts, die zuletzt in einer individuellen VAM enthalten ist, überschreitet eine vordefinierte Schwelle minReferenzPunktPositionÄnderungSchwelle.
    3. 3. Die Differenz zwischen der aktuellen geschätzten Bodengeschwindigkeit des Referenzpunkts des VRU 116 und der geschätzten absoluten Geschwindigkeit des Referenzpunkts des VRU, die zuletzt in einer individuellen VAM enthalten ist, überschreitet eine vordefinierte Schwelle minBodenGeschwindigkeitÄnderungSchwelle.
    4. 4. Die Differenz zwischen der Orientierung des Vektors des aktuellen geschätzten Bodengeschwindigkeitsvektors des Referenzpunkts des VRU 116 und der geschätzten Orientierung des Vektors des Bodengeschwindigkeitsvektors des Referenzpunkts des VRU 116, die zuletzt in einer individuellen VAM enthalten ist, überschreitet eine vordefinierte Schwelle minBodenGeschwindigkeitsvektorOrientierungÄnderungSchwelle
    5. 5. Die Differenz zwischen der aktuellen geschätzten Kollisionswahrscheinlichkeit mit Fahrzeug(en) oder anderen VRU(s) 116 (z.B. wie durch die Trajektorieabfangwahrscheinlichkeit gemessen) und der geschätzten Kollisionswahrscheinlichkeit mit Fahrzeug(en) oder anderen VRU(s) 116, die zuletzt in einer individuellen VAM gemeldet werden, überschreitet eine vordefinierte Schwelle minKollision WahrscheinlichtkeitÄnderungSchwelle.
    6. 6. Die Ursprungs-ITS-S ist ein VRU im VRU-AKTIV-EIGENSTÄNDIG-VBS-Zustand und hat nach seiner vorherigen individuellen VAM-Übertragung entschieden, einem Cluster beizutreten.
    7. 7. Ein VRU 116/117 hat bestimmt, dass ein oder mehrere neue Fahrzeuge oder andere VRUs 116/117 nach der zuletzt übertragenen VAM gleichzeitig die folgenden Bedingungen erfüllt haben. Die Bedingungen sind: seitliche Annäherung näher als minimaler sicherer Seitenabstand (MSLaD), Längsannäherung näher als minimaler sicherer Längsabstand (MSLoD) und Vertikalannäherung näher als minimaler sicherer Vertikalabstand (MSVD).
  • VRU-Cluster-VAM-Übertragungsverwaltung durch VBS an der VRU-ITS-S. Das erste Mal, wenn eine VRU-Cluster-VAM unmittelbar oder zum frühesten Zeitpunkt zur Übertragung erzeugt wird, wenn eine der folgenden Bedingungen erfüllt ist und die VRU-Cluster-VAM-Übertragung keinen Redundanzabschwächungstechniken unterliegt: Ein VRU 116 im VRU-AKTIV-EIGENSTÄNDIG-VBS-Zustand bestimmt, einen VRU-Cluster zu bilden.
  • Aufeinanderfolgende VRU-Cluster-VAM-Übertragung ist abhängig von Bedingungen wie vorliegend beschrieben. Aufeinanderfolgende VRU-Cluster-VAM-Erzeugungsereignisse treten am Clusterführer in einem Intervall gleich oder größer als T_ErzVam auf. Eine VRU-Cluster-VAM wird zur Übertragung durch den Clusterführer als Teil eines Erzeugungsereignisses erzeugt, falls eine der folgenden Bedingungen erfüllt ist und die VRU-Cluster-VAM-Übertragung keinen Redundanzabschwächungstechniken unterliegt:
    1. 1. Die Zeit, die seit dem letzten Mal verstrichen ist, als die VRU-Cluster-VAM übertragen wurde, überschreitet T_ErzVamMax.
    2. 2. Der euklidische absolute Abstand zwischen der aktuellen geschätzten Position des Referenzpunkts des VRU-Clusters und der geschätzten Position des Referenzpunkts, die zuletzt in einer VRU-Cluster-VAM enthalten ist, überschreitet eine vordefinierte Schwelle minReferenzPunktPositionÄnderungSchwelle.
    3. 3. Die Differenz zwischen der aktuellen geschätzten Breite des Clusters und der geschätzten Breite, die in der zuletzt übertragenen VAM enthalten ist, überschreitet eine vordefinierte Schwelle minClusterBreiteÄnderungSchwelle.
    4. 4. Die Differenz zwischen der aktuellen geschätzten Länge des Clusters und der geschätzten Länge, die in der zuletzt übertragenen VAM enthalten ist, überschreitet eine vordefinierte Schwelle minClusterLängeÄnderungSchwelle.
    5. 5. Die Differenz zwischen der aktuellen geschätzten Bodengeschwindigkeit des Referenzpunkts des VRU-Clusters und der geschätzten absoluten Geschwindigkeit des Referenzpunkts, die zuletzt in einer VRU-Cluster-VAM enthalten ist, überschreitet eine vordefinierte Schwelle minBodenGeschwindigkeitSchwelle.
    6. 6. Die Differenz zwischen der Orientierung des Vektors des aktuellen geschätzten Bodengeschwindigkeitsvektors des Referenzpunkts des VRU-Clusters und der geschätzten Orientierung des Vektors des Bodengeschwindigkeitsvektors des Referenzpunkts, die zuletzt in einer VRU-Cluster-VAM enthalten ist, überschreitet eine vordefinierte Schwelle minBodenGeschwindigkeitsvektorOrientierungÄnderungSchwelle.
    7. 7. Die Differenz zwischen der aktuellen geschätzten Kollisionswahrscheinlichkeit des VRU-Clusters mit Fahrzeug(en) oder anderen VRU(s) (z.B. wie durch die Trajektorieabfangwahrscheinlichkeit anderer Fahrzeuge/VRUs 116/117 mit Clusterbegrenzungsfläche gemessen) und der geschätzten Kollisionswahrscheinlichkeit mit Fahrzeug(en) oder anderen VRU(s), die zuletzt in einer VAM gemeldet wird, überschreitet minKollisionWahrscheinlichkeitÄnderungSchwelle .
    8. 8. Der VRU-Clustertyp wurde nach vorherigem VAM-Erzeugungsereignis (z.B. von einem homogenen zu einem heterogenen Cluster oder umgekehrt) geändert.
    9. 9. Der Clusterführer hat nach der Übertragung einer vorherigen VRU-Cluster-VAM bestimmt, den Cluster aufzubrechen.
    10. 10. Mehr als eine vordefinierte Anzahl neuer VRUs 116/117 sind nach Übertragung einer vorherigen VRU-Cluster-VAM dem VRU-Cluster beigetreten.
    11. 11. Mehr als eine vordefinierte Anzahl von Mitgliedern hat nach Übertragung einer vorherigen VRU-Cluster-VAM den VRU-Cluster verlassen.
    12. 12. Der VRU im VRU-AKTIV-CLUSTERFÜHRER-VBS-Zustand hat bestimmt, dass ein oder mehrere neue Fahrzeuge oder Nicht-Element-VRUs 116/117 (z.B. VRU-Profil 3 - Motorradfahrer) nach der zuletzt übertragenen VAM die folgenden Bedingungen gleichzeitig erfüllt haben. Die Bedingungen sind: seitliche Annäherung näher als minimaler sicherer Seitenabstand (MSLaD), Längsannäherung näher als minimaler sicherer Längsabstand (MSLoD) und Vertikalannäherung näher als minimaler sicherer Vertikalabstand (MSVD) an den Clusterbegrenzungsrahmen.
  • VAM-Redundanzabschwächung. Ein Gleichgewicht zwischen der Frequenz der VAM-Erzeugung in der Facilities-Schicht und dem Kommunikationsaufwand an der Zugangsschicht wird berücksichtigt, ohne die VRU-Sicherheit und das VRU-Bewusstsein in der Nähe zu beeinflussen. Die VAM-Übertragung an einem VAM-Erzeugungsereignis kann den folgenden Redundanzabschwächungstechniken unterliegen:
    • • Eine Ursprungs-VRU-ITS-S 117 überspringt die aktuelle individuelle VAM, falls alle folgenden Bedingungen gleichzeitig erfüllt sind. Die Zeit, die seit dem letzten Mal verstrichen ist, als eine VAM von der Ursprungs-VRU-ITS-S 117 übertragen wurde, überschreitet N (z.B. 4) Mal T_ErzVamMax, Der euklidische absolute Abstand zwischen der aktuellen geschätzten Position des Referenzpunkts und der geschätzten Position des Referenzpunkts in der empfangenen VAM ist kleiner als minReferenzPunktPositionÄnderungSchwelle; Die Differenz zwischen der aktuellen geschätzten Geschwindigkeit des Referenzpunkts und der geschätzten absoluten Geschwindigkeit des Referenzpunkts in der empfangenen VAM kleiner als minBodenGeschwindigkeitÄnderungSchwelle, Und die Differenz zwischen der Orientierung des Vektors des aktuellen geschätzten Bodengeschwindigkeitsvektors und der geschätzten Orientierung des Vektors des Bodengeschwindigkeitsvektors des Referenzpunktes in der empfangenen VAM ist geringer als minBodenGeschwindigkeitsvektorOrientierungAnderungSchwelle.
    • • Oder eine der folgenden Bedingungen erfüllt ist: Der VRU 116 konsultiert geeignete Karten, um zu verifizieren, ob sich der VRU 116 in geschützten oder nicht befahrbaren Bereichen wie Gebäuden usw. befindet; der VRU befindet sich in einem geografischen Bereich, der als Fußgängerzone ausgewiesen ist. Nur VRU-Profile 1 und 4 sind in dem Bereich erlaubt; der VRU 116 betrachtet sich selbst als Element eines VRU-Clusters und eine Cluster-Aufbruchnachricht wurde nicht vom Clusterführer empfangen; Die Informationen über den Ego-VRU 116 wurden von einer anderen ITS-S innerhalb von T_ErzVam gemeldet
  • VAM-Erzeugungszeit. Neben der VAM-Erzeugungsfrequenz sind die Zeit, die für die VAM-Erzeugung benötigt wird, und die Zeitigkeit der für die Nachrichtenkonstruktion aufgenommenen Daten entscheidend für die Anwendbarkeit von Daten in den empfangenden ITS-Ss. Um eine richtige Interpretation empfangener VAMs sicherzustellen, wird jede VAM zeitgestempelt. Eine akzeptable Zeitsynchronisation zwischen den unterschiedlichen ITS-Ss wird erwartet und sie liegt außerhalb des Umfangs dieser Spezifikation. Die für eine VAM-Erzeugung benötigte Zeit ist kleiner als T_ZusammenstellungVAM Die für eine VAM-Erzeugung erforderliche Zeit bezieht sich auf die Zeitdifferenz zwischen einer Zeit, zu der eine VAM-Erzeugung ausgelöst wird, und der Zeit, zu der die VAM an die N&T-Schicht geliefert wird.
  • VAM-Zeitstempel. Der Referenzzeitstempel, der in einer VAM bereitgestellt wird, die durch eine ITS-S verteilt wird, entspricht der Zeit, zu der die im Basis-Container-DF bereitgestellte Referenzposition durch die Ursprungs-ITS-S bestimmt wird. Das Format und der Bereich des Zeitstempels ist in Klausel B.3 von ETSI EN 302 637-2 V1.4.1 (2019-04) (im Folgenden „[EN302637-2]“) definiert. Die Differenz zwischen VAM-Erzeugungszeit und Referenzzeitstempel beträgt weniger als 32 767 ms, wie in [EN302637-2]. Dies kann dabei helfen, Zeitstempelumhüllungskomplikationen zu vermeiden.
  • Übertragen von VAMs. Die VRU-ITS-S 117 im VRU-AKTIV-EIGENSTÄNDIG-Zustand sendet „individuelle VAMs”, während die VRU-ITS-S im VRU-AKTIV-CLUSTERFÜHRER-VBS-Zustand „Cluster-VAMs” im Auftrag des VRU-Clusters überträgt. Die Cluster-Element-VRU-ITS-S 117 im VRU-PASSIV-VBS-Zustand sendet individuelle VAMs, die VruClusterBetriebContainer enthalten, während sie den VRU-Cluster verlässt. Die VRU-ITS-S 117 in VRU-AKTIV-EIGENSTÄNDIG sendet die VAM als „individuelle VAM”, dieVruClusterBetriebContainer enthält, während sie dem VRU-Cluster beitritt.
  • VRUs 116/117 stellen eine Vielfalt von Profilen dar, die zu zufälligen Verhaltensweisen führen, wenn sie sich in gemeinsam genutzten Bereichen bewegen. Darüber hinaus ist ihre Trägheit viel niedriger als bei Fahrzeugen (zum Beispiel kann ein Fußgänger eine Kehrtwende in weniger als einer Sekunde vornehmen), und somit ist seine Bewegungsdynamik schwieriger vorherzusagen.
  • Der VBS 1021 ermöglicht die Verteilung von VRU-Bewusstmachungsnachrichten (VAMs), deren Zweck es ist, ein Bewusstsein auf Ebene anderer VRUs 116/117 oder Fahrzeuge 110 zu erzeugen, mit dem Ziel, Konfliktsituationen zu lösen, die zu Kollisionen führen. Die mögliche Aktion des Fahrzeugs zum Lösen einer Konfliktsituation bezieht sich direkt auf die Zeit, die vor dem Konflikt bleibt, den Fahrzeuggeschwindigkeitsvektor, die Fahrzeugverlangsamungs- oder Spurwechselfähigkeit, das Wetter und den Fahrzeugzustand (zum Beispiel den Zustand der Straße und der Fahrzeugreifen). Im besten Fall benötigt ein Fahrzeug 1 bis 2 Sekunden, um eine Kollision zu vermeiden, aber im schlimmsten Fall kann es mehr als 4 bis 5 Sekunden benötigen, um eine Kollision zu vermeiden. Wenn sich ein Fahrzeug sehr nahe an einem VRU und mit konstantem Geschwindigkeitsvektor (zum Beispiel Zeit bis zur Kollision zwischen 1 bis 2 Sekunden) befindet, ist es nicht mehr möglich, über Bewusstsein zu sprechen, da daraus tatsächlich eine Warnung für sowohl den VRU als auch das Fahrzeug wird.
  • VRUs 116/117 und Fahrzeuge, die sich in einer Konfliktsituation befinden, müssen diese mindestens 5 bis 6 Sekunden detektieren, bevor der Konfliktpunkt erreicht wird, um sicherzustellen, dass sie rechtzeitig agieren können, um eine Kollision zu vermeiden. Allgemein werden Kollisionsrisikoindikatoren (zum Beispiel TTC, TDTC, PET usw., siehe z.B. [TS103300-2]) verwendet, um den Zeitpunkt des Konflikts vorherzusagen. Diese Indikatoren benötigen eine Vorhersage bezüglich: der Trajektorie (Weg), gefolgt von dem betreffenden VRU und dem betreffenden Fahrzeug; und/oder der Zeit, die der betreffende VRU und das betreffende Fahrzeug benötigen, um den Konfliktpunkt zusammen zu erreichen.
  • Diese Vorhersagen sollten aus Datenelementen abgeleitet werden, die zwischen dem betreffenden VRU und dem betreffenden Fahrzeug ausgetauscht werden. Für Fahrzeuge können die Trajektorie- und Zeitvorhersagen besser als für VRUs vorhergesagt werden, da Trajektorien der Fahrzeuge auf die Straßentopografie, den Verkehr, die Verkehrsregeln usw. beschränkt sind, während die VRUs 116/117 über viel mehr Bewegungsfreiheit verfügen. Bei Fahrzeugen ist ihre Dynamik zudem durch ihre Größe, ihre Masse und ihre Kursvariationsfähigkeiten eingeschränkt, was für die meisten der VRUs nicht der Fall ist.
  • Dementsprechend ist es in vielen Situationen nicht möglich, die genaue Trajektorie der VRUs 116/117 oder ihren Geschwindigkeitsvektor nur basierend auf ihrer jüngsten Weghistorie und auf ihrer aktuellen Position vorherzusagen. Falls dies durchgeführt wird, sind viele falsch positive und falsch negative Ergebnisse zu erwarten, was zu Entscheidungen für eine falsche Kollisionsvermeidungsaktion führt.
  • Ein möglicher Weg, falsch positive und falsch negative Ergebnisse zu vermeiden, besteht darin, die Fahrzeug- bzw. VRU-Wegvorhersagen auf deterministischen Informationen zu basieren, die durch das Fahrzeug und durch den VRU (Angaben bewegungsdynamischer Änderungen) bereitgestellt werden, und durch bessere Kenntnis des statistischen VRU-Verhaltens in sich wiederholenden Kontextsituationen. Eine Vorhersage kann immer a-posteriori verifiziert werden, wenn die Weghistorie erstellt wird. Erkannte Fehler können dann verwendet werden, um künftige Vorhersagen zu korrigieren.
  • VRU-Bewegungsdynamik-Änderungsanzeigen (MDCI, Motion Dynamic Change Indications) sind aus deterministischen Indikatoren aufgebaut, die direkt durch die VRU-Vorrichtung selbst bereitgestellt werden oder die aus einer Mobilitätsmodalitätszustandsänderung resultieren (z.B. Übergang von Fußgänger zu Fahrradfahrer, Übergehen von einem Fußgänger, der sein Fahrrad fährt, zu einem Fußgänger, der sein Fahrrad schiebt, Übergang von einem Motorradfahrer, der sein Motorrad fährt, zu einem Motorradfahrer, der von seinem Motorrad abgeworfen wird, Übergang von einem gefährlichen Bereich in einen geschützten Bereich, zum Beispiel Einsteigen in eine Straßenbahn, einen Zug usw.).
  • Im vorliegenden Dokument können die VRUs 116/117 in vier Profile klassifiziert werden, die in Klausel 4.1 von [TS 103300-3] definiert sind. Die SAE J3194 schlägt zudem eine Taxonomie und Klassifizierung von angetriebenen Mikromobilität-Fahrzeugen vor: angetriebenes Fahrrad (z.B. Elektrofahrrad); angetriebener Stehroller (z.B. Segway®); angetriebener Roller mit Sitz; angetriebenes selbstbalancierendes Board, manchmal als „selbstbalancierender Roller“ bezeichnet (z.B. selbstbalancierendes Hoverboard® und selbstbalancierendes elektrisches Einrad-Onewheel®); angetriebene Rollschuhe; und/oder dergleichen. Ihre Hauptcharakteristiken sind ihr Gewicht, Fahrzeugbreite, Höchstgeschwindigkeit, Leistungsquelle (elektrisch oder Verbrennung). Von Menschen angetriebene Mikromobilitätsfahrzeuge (Fahrrad, Stehroller) sollten ebenfalls berücksichtigt werden. Übergänge zwischen motorgetriebenen Fahrzeugen und durch Menschen angetriebenen Fahrzeugen können auftreten, wobei die Bewegungsdynamik des Fahrzeugs geändert wird. Es können auch menschengetrieben und motorgetrieben parallel auftreten, was sich ebenfalls auf die Bewegungsdynamik des Fahrzeugs auswirkt.
  • In [TS103300-2] und in Klausel 5.4.2.6 von [TS103300-3] ist ein kombinierter VRU 116/117 als die Zusammenstellung eines VRU-Profils 1 definiert, potentiell mit einem oder mehreren zusätzlichen VRU(s) 116/117, mit einem VRU-Fahrzeug oder Tier. Mehrere VRU-Fahrzeugtypen sind möglich. Selbst wenn die meisten von ihnen VRUs tragen können, kann ihr Antriebsmodus unterschiedlich sein, was zu spezifischen Bedrohungen und Anfälligkeiten führt: sie können von einem Menschen (ein Mensch, der auf dem Fahrzeug fährt oder auf einem Tier aufsitzt) angetrieben werden; sie können von einer Wärmekraftmaschine angetrieben werden. In diesem Fall wird die Wärmekraftmaschine nur aktiviert, wenn das Zündungssystem betriebsfähig ist; und/oder sie können durch einen Elektromotor angetrieben werden. In diesem Fall wird der Elektromotor unmittelbar aktiviert, wenn die Leistungsversorgung eingeschaltet ist (keine Zündung).
  • Ein kombinierter VRU 116/117 kann die Zusammenstellung eines Menschen und eines Tiers (z.B. eines Menschen mit einem Pferd oder eines Menschen mit einem Kamel) sein. Ein Mensch, der auf einem Pferd reitet, kann entscheiden, von dem Pferd abzusteigen und es dann zu führen. In diesem Fall führt der VRU 116/117 einen Übergang vom Profil 2 zum Profil 1 mit Auswirkung auf den Geschwindigkeitsvektor durch.
  • Diese Diversität der VRUs 116/117 und Cluster-Assoziation führt dazu, dass mehrere VBS-Zustandsmaschinen Standardnachrichtenverteilung und ihre jeweiligen Bewegungsdynamiken konditionieren. Diese Zustandsmaschinen und ihre Übergänge können zusammengefasst werden wie in 12.
  • 12 zeigt beispielhafte Zustandsmaschinen und Übergänge 1200 gemäß verschiedenen Ausführungsformen. In 12 ist es, wenn ein VRU als ein Profil 2 des VRU 1202 mit mehreren angeschlossenen Vorrichtungen gesetzt ist, notwendig, eine aktive auszuwählen. Dies kann für jede angeschlossene Vorrichtung zur Initialisierungszeit (Konfigurationsparameter) erreicht werden, wenn die Vorrichtung aktiviert wird. In 12 wurde die an dem Fahrrad angebrachte Vorrichtung so konfiguriert, dass sie während ihrer Kombination mit dem VRU aktiv ist. Wenn der VRU jedoch in einen Zustand 1201 des Profils 1 zurückkehrt, muss die an das VRU-Fahrzeug angeschlossene Vorrichtung deaktiviert werden, während der VBS 1021 in der an den VRU angeschlossenen Vorrichtung erneut VAMs überträgt, falls er sich nicht an einem geschützten Standort befindet.
  • In Zukunft können VRUs des Profils 2 1202, des Profils 1 1201 und des Profils 4 1204 Elemente eines Clusters werden, womit sie zu ihrem eigenen Zustand die mit der Clusterbildungsoperation verbundene Zustandsmaschine hinzufügen. Dies bedeutet, dass sie die Clusterverwaltungsanforderungen berücksichtigen müssen, während sie weiterhin ihre eigenen Zustände verwalten. Beim Übergang von einem Zustand in einen anderen kann der kombinierte VRU einen Cluster verlassen, falls er dessen Anforderungen nicht mehr entspricht.
  • Die in 12 identifizierten Übergänge der Maschinenzustände (z.B. T1 bis T4) beeinflussen die Bewegungsdynamik des VRU. Diese Übergänge werden deterministisch nach VRU-Entscheidungen oder mechanischen Ursachen (zum Beispiel VRU-Auswurf aus seinem VRU-Fahrzeug) detektiert. Die identifizierten Übergänge haben die folgenden Auswirkungen auf die VRU-Bewegungsdynamik.
  • T1 ist ein Übergang von einem VRU-Profil 1 1201 zum Profil 2 1202. Dieser Übergang wird manuell oder automatisch ausgelöst, wenn der VRU die Entscheidung trifft, aktiv ein VRU-Fahrzeug zu verwenden (zu fahren). Der bewegungsdynamische-Geschwindigkeitsvektor-Parameterwert des VRU ändert sich von einer niedrigen Geschwindigkeit (Schieben/Ziehen seines VRU-Fahrzeugs) zu einer höheren Geschwindigkeit, die mit der Klasse des ausgewählten VRU-Fahrzeugs zusammenhängt.
  • T2 ist ein Übergang von einem VRU-Profil 2 1202 zum Profil 1 1201. Dieser Übergang wird manuell oder automatisch ausgelöst, wenn der VRU von seinem VRU-Fahrzeug absteigt und es stehen lässt und zu einem Fußgänger wird. Der bewegungsdynamische Geschwindigkeitsvektor-Parameterwert des VRU ändert sich von einer gegebenen Geschwindigkeit zu einer niedrigeren Geschwindigkeit, die mit der Klasse des ausgewählten VRU-Fahrzeugs zusammenhängt.
  • T3 ist ein Übergang von einem VRU-Profil 2 1202 zum Profil 1 1201. Dieser Übergang wird manuell oder automatisch ausgelöst, wenn der VRU von seinem VRU-Fahrzeug absteigt und es zum Beispiel schiebt/zieht, um in eine geschützte Umgebung (zum Beispiel Straßenbahn, Bus, Zug) einzutreten. Der bewegungsdynamische Geschwindigkeitsvektor-Parameterwert des VRU ändert sich von einer gegebenen Geschwindigkeit zu einer niedrigeren Geschwindigkeit, die mit der Klasse des ausgewählten VRU-Fahrzeugs zusammenhängt.
  • T4 ist ein Übergang von einem VRU-Profil 2 1202 zum Profil 1 1201. Dieser Übergang wird automatisch ausgelöst, wenn detektiert wird, dass ein VRU von seinem VRU-Fahrzeug abgeworfen wird. Der bewegungsdynamische Geschwindigkeitsvektor-Parameterwert des VRU ändert sich von einer gegebenen Geschwindigkeit zu einer niedrigeren Geschwindigkeit in Bezug auf den VRU-Zustand, der aus seinem Abwurf resultiert. In diesem Fall wird das VRU-Fahrzeug als ein Hindernis auf der Straße angesehen und sollte dementsprechend DENMs verbreiten, bis es von der Straße entfernt wird (seine ITS-S ist deaktiviert).
  • Der Abwurffall kann durch Stabilitätsindikatoren einschließlich Trägheitssensoren und das aus seinem Verhalten abgeleitete Fahrkompetenzniveau detektiert werden. Die Stabilität kann dann in Form des Risikoniveaus eines vollständigen Stabilitätsverlustes ausgedrückt werden. Wenn das Risikoniveau 100 % beträgt, kann dies als faktischer Abwurf des VRU bestimmt werden.
  • Aus der Variation des bewegungsänderungsdynamischen Geschwindigkeitsparameterwerts kann eine neue Wegvorhersage aus registrierten „kontextbezogenen“ vergangenen Weghistorien (durchschnittlichen VRU-Spuren) bereitgestellt werden. Die Kontextaspekte berücksichtigen mehrere Parameter, die sich auf einen Kontext beziehen, der dem Kontext ähnlich ist, in dem sich der VRU entwickelt.
  • Zusätzlich zu den oben identifizierten Zustandsübergängen, die sich drastisch auf den VRU-Geschwindigkeitsvektor auswirken können, beeinflussen die folgenden VRU-Angaben ebenfalls den VRU-Geschwindigkeitsvektor und/oder die VRU-Trajektorie (zusätzlich zu den bereits in der VAM definierten Parametern).
  • Stoppindikator. Der VRU oder eine externe Quelle (eine Ampel, die für den VRU rot ist) kann angeben, dass der VRU für einen Moment anhält. Wenn dieser Indikator gesetzt ist, könnte es auch nützlich sein, die Dauer des VRU-Stopps zu kennen. Diese Dauer kann entweder geschätzt werden, wenn sie durch eine externe Quelle bereitgestellt wird (beispielsweise die von einer Ampel empfangenen SPATEM-Informationen), oder wenn sie durch eine Analyse des VRU-Verhaltens unter ähnlichen Umständen erlernt werden.
  • Sichtindikatoren. Wetterbedingungen können sich auf die VRU-Sicht auswirken und dementsprechend dessen Bewegungsdynamik ändern. Selbst wenn die lokalen Fahrzeuge diese Wetterbedingungen detektieren können, könnte in manchen Fällen die Auswirkung auf den VRU durch Fahrzeuge schwierig zu schätzen sein. Ein typisches Beispiel ist das folgende: Gemäß seiner Orientierung kann ein VRU durch eine stark blendende Sonne gestört werden (beispielsweise morgens, wenn die Sonne aufgeht, oder abends, wenn die Sonne untergeht), wodurch seine Geschwindigkeit beschränkt wird
  • Unter erneuter Bezugnahme auf 10 stellt die N&T-Schicht 1003 Funktionalität der OSI-Netzwerkschicht und der OSI-Transportschicht bereit und beinhaltet ein oder mehrere Vernetzungsprotokolle, ein oder mehrere Transportprotokolle und Netzwerk- und Transportschichtverwaltung. Zusätzlich können Aspekte von Sensorschnittstellen und Kommunikationsschnittstellen Teil der N&T-Schicht 1003 und der Zugangsschicht 1004 sein. Die Vernetzungsprotokolle können unter anderem IPv4-, IPv6-, IPv6-Vernetzung mit Mobilitätsunterstützung, IPv6 über GeoNetworking, das CALM FAST-Protokoll und/oder dergleichen beinhalten. Die Transportprotokolle können unter anderem BOSH-, BTP-, GRE-, GeoNetworking-Protokoll, MPTCP, MPUDP, QUIC, RSVP, SCTP, TCP, UDP, VPN, ein oder mehrere dedizierte ITSC-Transportprotokolle oder ein anderes geeignetes Transportprotokoll beinhalten. Jedes der Vernetzungsprotokolle kann mit einem entsprechenden Transportprotokoll verbunden sein.
  • Die Zugangsschicht beinhaltet eine physikalische Schicht (PHY) 1004, die physikalisch mit dem Kommunikationsmedium verbindet, eine Sicherungsschicht (DLL), die in eine Medienzugangssteuer (MAC)-Subschicht, die den Zugang zum Kommunikationsmedium verwaltet, und eine Logical Link Control (LLC)-Subschicht unterteilt sein kann, eine Verwaltungsanpassungsentität (MAE), um die PHY 1004 und die DLL direkt zu verwalten, und eine Sicherheitsanpassungsentität (SAE), um Sicherheitsdienste für die Zugangsschicht bereitzustellen. Die Zugangsschicht kann auch externe Kommunikationsschnittstellen (CIs) und interne CIs beinhalten. Die CIs sind Instanziierungen einer spezifischen Zugangsschichttechnologie oder RAT und eines Protokolls, wie etwa 3GPP LTE, 3GPP 5G/NR, C-V2X (z.B. basierend auf 3GPP LTE und/oder 5G/NR), WiFi, W-V2X (z.B. einschließlich ITS-G5 und/oder DSRC), DSL, Ethernet, Bluetooth und/oder beliebige andere RAT und/oder Kommunikationsprotokolle, die hier erörtert werden, oder Kombinationen davon. Die CIs stellen die Funktionalität eines oder mehrerer logischer Kanäle (LCHs) bereit, wobei die Abbildung von LCHs auf physikalische Kanäle durch den Standard der speziellen beteiligten Zugangstechnologie spezifiziert wird. Wie zuvor angemerkt, können die V2X-RATs ITS-G5/DSRC und 3GPP C-V2X beinhalten. Zusätzlich oder alternativ dazu können andere Zugangsschichttechnologien (V2X-RATs) bei verschiedenen anderen Ausführungsformen verwendet werden.
  • Die ITS-S-Referenzarchitektur 1000 kann auf die Elemente der 13 und 15 anwendbar sein. Das ITS-S-Gateway 1311, 1511 (siehe z.B. 13 und 15) verbindet auf der Facilities-Schicht einen OSI-Protokollstapel auf den OSI-Schichten 5 bis 7. Der OSI-Protokollstapel ist typischerweise mit dem System- (z.B. Fahrzeugsystem oder Straßenrandsystem) Netzwerk verbunden, und der ITSC-Protokollstapel ist mit dem stationsinternen ITS-Netzwerk verbunden. Das ITS-S-Gateway 1311, 1511 (siehe z.B. 13 und 15) ist in der Lage, Protokolle zu konvertieren. Dadurch kann eine ITS-S mit externen Elementen des Systems kommunizieren, in dem sie implementiert ist. Der ITS-S-Router 1311, 1511 stellt die Funktionalität der ITS-S-Referenzarchitektur 1000 unter Ausschluss der Anwendungen und Facilities-Schicht bereit. Der ITS-S-Router 1311, 1511 verbindet zwei unterschiedliche ITS-Protokollstapel auf Schicht 3. Der ITS-S-Router 1311, 1511 kann in der Lage sein, Protokolle zu konvertieren. Einer dieser Protokollstapel ist typischerweise mit dem stationsinternen ITS-Netzwerk verbunden. Der ITS-S-Border-Router 1514 (siehe z.B. 15) stellt die gleiche Funktionalität wie der ITS-S-Router 1311, 1511 bereit, beinhaltet aber einen Protokollstapel, der sich auf ein externes Netzwerk bezieht, das möglicherweise nicht die Management- und Sicherheitsprinzipien des ITS befolgt (z.B. die ITS-Vrwltngs- und ITS-Sicherheitsschichten in 10).
  • Zusätzlich beinhalten andere Entitäten, die auf derselben Ebene arbeiten, aber nicht in der ITS-S enthalten sind, die relevanten Benutzer auf dieser Ebene, die relevante HMI (z. B. AudioVorrichtungen, Anzeige-/Touchscreen-Vorrichtungen usw.); wenn die ITS-S ein Fahrzeug ist, Fahrzeugbewegungssteuerung für computergestützte und/oder automatisierte Fahrzeuge (sowohl HMI als auch Fahrzeugbewegungssteuerentitäten können durch die ITS-S-Anwendungen getriggert werden); ein Sensorsystem und eine IoT-Plattform der lokalen Vorrichtung, die IoT-Daten sammeln und gemeinsam nutzen; Sensorfusions- und Aktuatoranwendung(en) der lokalen Vorrichtung, die ML/KI enthalten können und den vom Sensorsystem ausgegebenen Datenfluss aggregieren können; lokale Perzeptions- und Trajektorienprädiktionsanwendungen, die die Ausgabe der Fusionsanwendung aufnehmen und die ITS-S-Anwendungen speisen; und die relevante ITS-S. Das Sensorsystem kann eine oder mehrere Kameras, Radare, LIDARs usw. in einer V-ITS-S 110 oder R-ITS-S 130 beinhalten. In der Zentrale beinhaltet das Sensorsystem Sensoren, die sich am Straßenrand befinden können, aber ihre Daten ohne Beteiligung einer V-ITS-S 110 oder R-ITS-S 130 direkt an die Basisstation melden. In einigen Fällen kann das Sensorsystem zusätzlich ein oder mehrere Gyroskope, einen oder mehrere Beschleunigungsmesser und dergleichen beinhalten (siehe z.B. die Sensorschaltungsanordnung 1772 von 17). Aspekte dieser Elemente werden im Folgenden mit Bezug auf die 13, 14 und 15 erörtert
  • 13 stellt ein beispielhaftes Fahrzeugrechensystem 1300 gemäß verschiedenen Ausführungsformen dar. In diesem Beispiel beinhaltet das Fahrzeugrechensystem 1300 eine V-ITS-S 1301 und elektronische Steuereinheiten (ECUs, Electronic Control Units) 1305. Die V-ITS-S 1301 beinhaltet ein V-ITS-S-Gateway 1311, einen ITS-S-Host 1312 und einen ITS-S-Router 1313. Das Fahrzeug-ITS-S-Gateway 1311 stellt Funktionalität bereit, um die Komponenten im fahrzeuginternen Netzwerk (z.B. ECUs 1305) mit dem ITS-stationsinternen Netzwerk zu verbinden. Die Schnittstelle zu den fahrzeuginternen Komponenten (z.B. ECUs 1305) kann die gleiche wie die hierin erörterten oder ähnlich sein (siehe z.B. IX 1756 von 17) und/oder kann eine proprietäre Schnittstelle/Verschaltung sein. Der Zugang zu Komponenten (z.B. ECUs 1305) kann implementierungsspezifisch sein. Die ECUs 1305 können die gleichen oder ähnlich den zuvor mit Bezug auf 1 erörterten Antriebssteuereinheiten (DCUs) 174 sein. Die ITS-Station ist über den ITS-S-Router 1313 mit ITS-Ad-hoc-Netzwerken verbunden.
  • 14 stellt ein beispielhaftes Personal-Computing-System 1400 gemäß verschiedenen Ausführungsformen dar. Das persönliche ITS-Subsystem 1400 stellt die Anwendungs- und Kommunikationsfunktionalität von ITSC in Mobilvorrichtungen, wie etwa Smartphones, Tablet-Computern, Wearable-Vorrichtungen, PDAs, tragbaren Medienspielern, Laptops und/oder anderen mobilen Vorrichtungen, bereit. Das persönliche ITS-Subsystem 1400 enthält eine persönliche ITS-Station (P-ITS-S) 1401 und verschiedene andere Entitäten, die nicht in der P-ITS-S 1401 enthalten sind und die im Folgenden ausführlicher erörtert werden. Die Vorrichtung, die als eine persönliche ITS-Station verwendet wird, kann auch eine HMI-Funktionalität als Teil eines anderen ITS-Subsystems durchführen, das über das ITS-Stations-interne Netzwerk (nicht gezeigt) mit dem anderen ITS-Subsystem verbunden ist. Zum Zwecke der vorliegenden Offenbarung kann das persönliche ITS-Subsystem 1400 als eine VRU-ITS-S 117 verwendet werden.
  • 15 stellt ein beispielhaftes Roadside-Infrastruktursystem 1500 gemäß verschiedenen Ausführungsformen dar. In diesem Beispiel beinhaltet das Roadside-Infrastruktursystem 1500 eine R-ITS-S 1501, eine oder mehrere Ausgabevorrichtungen 1505, einen oder mehrere Sensoren 1508 und eine oder mehrere Funkeinheiten (RUs) 1510. Die R-ITS-S 1501 beinhaltet ein R-ITS-S-Gateway 1511, einen ITS-S-Host 1512, einen ITS-S-Router 1513 und einen ITS-S-Border-Router 1514. Die ITS-Station ist über den ITS-S-Router 1513 mit ITS-Ad-hoc-Netzwerken und/oder ITS-Zugangsnetzwerken verbunden. Das R-ITS-S-Gateway 1311 stellt Funktionalität bereit, um die Komponenten des Straßenrandsystems (z.B. Ausgabevorrichtungen 1505 und Sensoren 1508) an dem Straßenrandnetzwerk mit dem ITS-stationsinternen Netzwerk zu verbinden. Die Schnittstelle zu den fahrzeuginternen Komponenten (z.B. ECUs 1305) kann die gleiche wie die hierin erörterten oder ähnlich sein (siehe z.B. IX 1606 von 16 und IX 1756 von 17) und/oder eine proprietäre Schnittstelle/Verschaltung sein. Der Zugang zu Komponenten (z.B. ECUs 1305) kann implementierungsspezifisch sein. Der/die Sensor(en) 1508 kann/können induktive Schleifen und/oder Sensoren, die gleich oder ähnlich den Sensoren 172 sind, die nachstehend mit Bezug auf 1 erörtert werden, und/oder der Sensorschaltungsanordnung 1772, die im Folgenden mit Bezug auf 17 erörtert wird, sein.
  • Bei den Aktuatoren 1513 handelt es sich um Vorrichtungen, die für die Bewegung und Steuerung eines Mechanismus oder Systems verantwortlich sind. Bei verschiedenen Ausführungsformen werden die Aktuatoren 1513 verwendet, um den Betriebszustand (z.B. ein/aus, Zoom oder Fokus usw.), die Stellung und/oder Ausrichtung der Sensoren 1508 zu ändern. In einigen Ausführungsformen werden die Aktuatoren 1513 verwendet, um den Betriebszustand einiger anderer Straßenrandgeräte, wie etwa Schranken, Ampeln, digitaler Beschilderung oder variabler Nachrichtenschilder (VMS) usw., zu ändern. Die Aktuatoren 1513 sind dazu ausgelegt, Steuersignale von der R-ITS-S 1501 über das Straßenrandnetzwerk zu empfangen und die Signalenergie (oder irgendeine andere Energie) in eine elektrische und/oder mechanische Bewegung zu konvertieren. Die Steuersignale können eine elektrische Spannung oder Strom mit relativ niedriger Energie sein. In einigen Ausführungsformen umfassen die Aktuatoren 1513 elektromechanische Relais und/oder Halbleiterrelais, die dazu ausgelegt sind, elektronische Vorrichtungen ein-/auszuschalten und/oder Motoren zu steuern, und/oder die dieselben oder ähnliche Aktuatoren 1774 sein können, die nachstehend mit Bezug auf 17 erörtert sind.
  • Jede der 13, 14 und 15 zeigt zudem Entitäten, die auf der gleichen Ebene arbeiten, aber nicht in der ITS-S einschließlich der relevanten HMI 1306, 1406 und 1506 enthalten sind; Fahrzeugbewegungssteuerung 1308 (nur auf der Fahrzeugebene); lokales Vorrichtungssensorsystem und IoT-Plattform 1305, 1405 und 1505; lokale Vorrichtungssensorfusions- und Aktuatoranwendung 1304, 1404 und 1504; lokale Wahrnehmungs- und Trajektorievorhersageanwendungen 1302, 1402 und 1502; Bewegungsvorhersage 1303 und 1403 oder Mobilobjekttrajektorievorhersage 1503 (auf der RSU-Ebene); und das verbundene System 1307, 1407 und 1507.
  • Das lokale Vorrichtungssensorsystem und die IoT-Plattform 1305, 1405 und 1505 sammeln und teilen IoT-Daten. Das VRU-Sensorsystem und die IoT-Plattform 1405 bestehen zumindest aus der in jeder ITS-S des Systems vorhandenen PoTi-Verwaltungsfunktion (siehe z.B. [EN302890-2]). Die PoTi-Entität stellt die globale Zeit, die allen Systemelementen gemeinsam ist, und die Echtzeitposition der Mobilelemente bereit. Lokale Sensoren können auch in anderen mobilen Elementen sowie in der Straßeninfrastruktur (z.B. Kamera in einer intelligenten Ampel, elektronische Beschilderung usw.) eingebettet sein. Eine IoT-Plattform, die über die Systemelemente verteilt werden kann, kann dazu beitragen, zusätzliche Informationen bezüglich der Umgebung im VRU-System 1400 bereitzustellen. Das Sensorsystem kann eine oder mehrere Kameras, Radars, LiDARs und/oder andere Sensoren (siehe z.B. 1722 von 17), in einer V-ITS-S 110 oder einer R-ITS-S 130 beinhalten. In der VRU-Vorrichtung 117/1400 kann das Sensorsystem Gyroskop(e), Beschleunigungsmesser und dergleichen beinhalten (siehe z.B. 1722 von 17). In einer (nicht gezeigten) Basisstation beinhaltet das Sensorsystem Sensoren, die sich am Straßenrand befinden können, aber ihre Daten direkt an die Basisstation melden, ohne Beteiligung einer V-ITS-S 110 oder einer R-ITS-S 130.
  • Die (lokalen) Sensordatenfusionsfunktions- und/oder Aktuatoranwendungen 1304, 1404 und 1504 stellen die Fusion von lokalen Wahrnehmungsdaten bereit, die von dem VRU-Sensorsystem und/oder verschiedenen lokalen Sensoren erhalten werden. Dies kann das Aggregieren von Datenflüssen, die durch das Sensorsystem und/oder verschiedene lokale Sensoren ausgegeben werden, beinhalten. Die lokale(n) Sensorfusions- und Aktuatoranwendung(en) kann/können Algorithmen für maschinelles Lernen (ML)/künstliche Intelligenz (KI) und/oder Modelle enthalten. Sensordatenfusion ist üblicherweise auf Konsistenz ihrer Eingaben und dann auf ihre Zeitstempelung angewiesen, die einer gemeinsamen gegebenen Zeit entsprechen. Gemäß verschiedenen Ausführungsformen können die Sensordatenfusions- und/oder ML/AL-Techniken verwendet werden, um Belegungswerte für die vorliegend besprochenen DCROM-Ausführungsformen zu bestimmen.
  • Verschiedene ML/KI-Techniken können verwendet werden, um die Sensordatenfusion auszuführen, und/oder können für andere Zwecke verwendet werden, wie etwa die vorliegend erörterten DCROM-Ausführungsformen. In einigen Ausführungsformen, in denen die Apps 1304, 1404 und 1504 KI/ML-Funktionen sind (oder diese beinhalten), können die Apps 1304, 1404 und 1504 KI/ML-Modelle beinhalten, die die Fähigkeit aufweisen, nützliche Informationen aus Eingabedaten (z.B. Kontextinformationen usw.) gemäß überwachtem Lernen, unüberwachtem Lernen, verstärktem Lernen (RL) und/oder neuronalen Netz(en) (NN) zu lernen. Separat trainierte KI/ML-Modelle können während der Inferenz- oder Prognoseerzeugung zudem in einer KI/ML-Pipeline miteinander verkettet werden.
  • Die Eingabedaten können KI/ML,-Trainingsinformationen und/oder KI/ML-Modellinferenzinformationen beinhalten. Die Trainingsinformationen beinhalten die Daten des ML-Modells einschließlich der Eingabe- (Trainings-) Daten plus Kennzeichnungen für überwachtes Training, Hyperparameter, Parameter, Wahrscheinlichkeitsverteilungsdaten und andere Informationen, die zum Trainieren eines bestimmten KI/ML-Modells benötigt werden. Die Modellinferenzinformationen sind beliebige Informationen oder Daten, die als Eingabe für das KI/ML-Modell zur Inferenzerzeugung (oder zum Treffen von Vorhersagen) benötigt werden. Die durch ein KI/ML,-Modell zum Training und zur Inferenz verwendeten Daten können sich weitgehend überschneiden, diese Arten von Informationen beziehen sich jedoch auf unterschiedliche Konzepte. Die Eingabedaten werden Trainingsdaten genannt und weisen eine bekannte Kennzeichnung bzw. ein bekanntes Ergebnis auf.
  • Überwachtes Lernen ist eine ML-Aufgabe, die bei einem gegebenen gekennzeichneten Datensatz darauf abzielt, eine Abbildungsfunktion von der Eingabe auf die Ausgabe zu lernen. Beispiele für überwachtes Lernen beinhalten Regressionsalgorithmen (z.B. lineare Regression, logistische Regression und dergleichen), instanzbasierte Algorithmen (z.B. k-nächste-Nachbarn und dergleichen, Entscheidungsbaumalgorithmen (z.B. Classification And Regression Tree (CART), Iterative Dichotomiser 3 (ID3), C4.5, Chi-Quadrat-Automatic Interaction Detection (CHAID) usw.), Fuzzy Decision Tree (FDT), und dergleichen), Support Vector Machines (SVM), Bayes-Algorithmen (z.B. Bayes-Netzwerk (BN), ein dynamisches BN (DBN), Naiv-Bayes und dergleichen) und Ensemblealgorithmen (z.B. Extreme Gradient Boosting, Voting-Ensemble, Bootstrap-Aggregation („Bagging“), Random-Forest und dergleichen. Überwachtes Lernen kann ferner in Regressions- und Klassifikationsprobleme gruppiert werden. Eine Klassifizierung betrifft das Vorhersagen einer Kennzeichnung, wohingegen Regression das Vorhersagen einer Menge betrifft. Für unüberwachtes Lernen werden Eingabedaten nicht gekennzeichnet und weisen kein bekanntes Ergebnis auf. Unüberwachtes Lernen ist eine ML-Aufgabe, die darauf abzielt, eine Funktion zu lernen, um eine verborgene Struktur von nicht gekennzeichneten Daten zu beschreiben. Einige Beispiele für unüberwachtes Lernen sind K-Means-Clustering und Hauptkomponentenanalyse (PCA, Principal Component Analysis). Neuronale Netze (NNs) werden üblicherweise für überwachtes Lernen verwendet, können aber auch für unüberwachtes Lernen verwendet werden. Beispiele für NNS beinhalten ein tiefes NN (DNN), ein vorwärtsgekoppeltes NN (FFN), ein tiefes FNN (DFF), ein Faltungs-NN (CNN), ein tiefes CNN (DCN), ein Entfaltungs-NN (DNN), ein Deep-Belief-NN, ein Wahrnehmungs-NN, ein rekurrentes NN (RNN) (z.B. einschließlich LSTM-(Long Short Term Memory - langer Kurzzeitspeicher) Algorithmus, Gated Recurrent Unit (GRU) usw.), Deep-Stacking-Netzwerk (DSN), Verstärkungslernen (RL) ist ein zielorientiertes Lernen basierend auf Interaktion mit der Umgebung. Bei RL zielt ein Agent darauf ab, ein Langzeitziel durch Interaktion mit der Umgebung basierend auf einem Trial-and-Error-Prozess zu optimieren. Beispiele für RL-Algorithmen beinhalten Markov-Entscheidungsprozess, Markov-Kette, Q-Lernen, Lernen mit mehrarmigen Banditen und tiefes RL.
  • In einem Beispiel werden die ML/KI-Techniken zur Objektverfolgung verwendet. Die Objektverfolgungs- und/oder Computervisionstechniken können zum Beispiel Kantendetektion, Eckendetektion, Blob-Detektion, ein Kalman-Filter, Gaußsches Mischmodell, Partikelfilter, Mean-Shift-basierte Kernel-Verfolgung, eine ML,-Objektdetektionstechnik (z. B. Viola-Jones Object Detection Framework, skaleninvariante Merkmalstransformation (SIFT - Scale-Invariant Feature Transform), Histogramm orientierter Gradienten (HOG) usw.), eine Deep-Learning-Objektdetektionstechnik (z. B. FCNN (Full Convolutional Neural Network), R-CNN (Region Proposal Convolution Neural Network), Single Shot MultiBox Detector, YOLO-Algorithmus (YOLO = You Only Look Once) usw.) und/oder dergleichen umfassen.
  • In einem anderen Beispiel werden die ML/KI-Techniken zur Bewegungsdetektion basierend auf den y-Sensordaten verwendet, die von dem einen oder den mehreren Sensoren erhalten werden. Zusätzlich oder alternativ werden die ML/KI - Techniken zur Objektdetektion und/oder -klassifizierung verwendet. Die Objektdetektions- oder -erkennungsmodelle können eine Registrierungsphase und eine Auswertungsphase umfassen. Während der Registrierungsphase werden ein oder mehrere Merkmale aus den Sensordaten (z.B. Bild- oder Videodaten) extrahiert. Ein Merkmal ist eine individuelle messbare Eigenschaft oder Charakteristik. Im Kontext der Objektdetektion kann ein Objektmerkmal Objektgröße, -farbe, -form, eine Beziehung zu anderen Objekten und/oder eine beliebige Region oder einen beliebigen Teil eines Bildes, wie etwa Ränder, Kanten, Ecken, Blobs und/oder einige definierten Regionen von Interesse (ROI) und/oder dergleichen, umfassen. Die verwendeten Merkmale können implementierungsspezifisch sein und zum Beispiel auf den zu detektierenden Objekten und dem/den zu entwickelnden und/oder zu verwendenden Modell(en) basieren. In der Auswertungsphase werden Objekte identifiziert oder klassifiziert, indem gewonnene Bilddaten mit bestehenden Objektmodellen verglichen werden, die während der Registrierungsphase erstellt wurden. Während der Auswertungsphase werden aus den Bilddaten extrahierte Merkmale mit den Objektidentifikationsmodellen unter Verwendung einer geeigneten Mustererkennungstechnik verglichen. Die Objektmodelle können qualitative oder funktionale Beschreibungen, geometrische Oberflächeninformationen und/oder abstrakte Merkmalsvektoren sein und in einer geeigneten Datenbank gespeichert werden, die unter Verwendung irgendeiner Art von Indexierungsschema organisiert ist, um unwahrscheinliche Objektkandidaten leichter außer Betracht lassen zu können.
  • Für beliebige der hier besprochenen Ausführungsformen können eine oder mehrere beliebige geeignete Datenfusions- oder Datenintegrationstechniken verwendet werden, um die zusammengesetzten Informationen zu erzeugen. Zum Beispiel kann die Datenfusionstechnik eine direkte Fusionstechnik oder eine indirekte Fusionstechnik sein. Direkte Fusion kombiniert Daten, die direkt von mehreren vUEs oder Sensoren erfasst werden, die gleich oder ähnlich sein können (z.B. alle vUEs oder Sensoren führen die gleiche Art von Messung durch) oder verschieden sein können (z.B. verschiedene vUEs oder Sensortypen, historische Daten usw.). Indirekte Fusion nutzt historische Daten und/oder bekannte Umgebungseigenschaften und/oder menschliche Eingaben, um einen verfeinerten Datensatz zu erzeugen. Zusätzlich dazu kann die Datenfusionstechnik einen oder mehrere Fusionsalgorithmen beinhalten, wie etwa einen Glättungsalgorithmus (z.B. Schätzen eines Werts unter Verwendung mehrerer Messungen in Echtzeit oder nicht in Echtzeit), einen Filteralgorithmus (z.B. Schätzen eines Zustands einer Entität mit aktuellen und vergangenen Messungen in Echtzeit), und/oder einen Vorhersagezustandsschätzalgorithmus (z.B. Analysieren historischer Daten (z.B. Standort, Geschwindigkeit, Richtung und Signalmessungen) in Echtzeit, um einen Zustand (z. B. eine zukünftige Signalstärke/-qualität an einer bestimmten Standortkoordinate vorherzusagen). Als Beispiele kann der Datenfusionsalgorithmus ein strukturbasierter Algorithmus (z. B. baumbasierter (z.B. Minimum Spanning Tree (MST)), clusterbasierter, gitterbasierter und/oder zentralisierter), ein strukturfreier Datenfusionsalgorithmus, ein Kalman-Filter-Algorithmus und/oder erweiterte Kalman-Filterung, ein Fuzzy-basierter Datenfusionsalgorithmus, ein Ant-Colony-Optimization-(ACO-) Algorithmus, ein Fehlererkennungsalgorithmus, ein Dempster-Shafer-(D-S-) Argumentationsbasierter Algorithmus, ein Gaußsches-Mischmodell-Algorithmus, ein triangulationsbasierter Fusionsalgorithmus und/oder ein beliebiger anderer ähnlicher Datenfusionalgorithmus sein oder diese beinhalten.
  • Eine lokale Wahrnehmungsfunktion (die Trajektorievorhersageanwendung(en) beinhalten kann oder nicht) 1302, 1402 und 1502 wird durch die lokale Verarbeitung von Informationen bereitgestellt, die durch einen oder mehrere lokale Sensoren, die mit dem Systemelement assoziiert sind, gesammelt werden. Die lokale Wahrnehmungs- (und Trajektorievorhersage-) Funktion 1302, 1402 und 1502 beansprucht die Ausgabe der Sensordatenfusionsanwendung/-Funktion 1304, 1404 und 1504 und speist ITS-S-Anwendungen mit den Wahrnehmungsdaten (und/oder Trajektorievorhersagen). Die lokale Wahrnehmungs- (und Trajektorievorhersage-) Funktion 1302, 1402 und 1502 detektiert und charakterisiert Objekte (statisch und mobil), die wahrscheinlich die Trajektorie der betreffenden sich bewegenden Objekte kreuzen werden. Die Infrastruktur, und insbesondere die Straßeninfrastruktur 1500, kann Dienste anbieten, die für den VRU-Unterstützungsdienst relevant sind. Die Infrastruktur kann ihre eigenen Sensoren aufweisen, die die Entwicklung von VRUs 116/117 detektieren und dann ein Kollisionsrisiko berechnen, falls auch Entwicklungen lokaler Fahrzeuge detektiert werden, entweder direkt über ihre eigenen Sensoren oder aus der Ferne über einen Kooperativwahrnehmungsunterstützungsdienst wie etwa den CPS (siehe z.B. ETSI TR 103 562). Zudem können eine Straßenmarkierung (z.B. Zebrastreifen oder Fußgängerüberwege) und vertikale Zeichen als das Konfidenzniveau erhöhend betrachtet werden, das mit der VRU-Erkennung und Mobilität assoziiert ist, da VRUs 116/117 üblicherweise diese Markierung/Zeichen beachten müssen.
  • Die Bewegungsdynamikvorhersagefunktion 1303 und 1403 und die Mobilobjekttrajektorievorhersage 1503 (auf RSU-Ebene) stehen in Beziehung mit der Verhaltensvorhersage der betrachteten sich bewegenden Objekte. In einigen Ausführungsformen sagen die Bewegungsdynamikvorhersagefunktionen 1303 und 1403 die Trajektorie des Fahrzeugs 110 bzw. des VRU 116 voraus. In einigen Ausführungsformen kann die Bewegungsdynamikvorhersagefunktion 1303 Teil des VRU-Trajektorie- und Verhaltensmodellierungsmoduls und des Trajektorieabfangmoduls der V-ITS-S 110 sein. In einigen Ausführungsformen kann die Bewegungsdynamikvorhersagefunktion 1403 Teil des Koppelnavigationsmoduls und/oder des Bewegungsdetektionsmoduls der VRU-ITS-S 117 sein. Alternativ können die Bewegungsdynamikvorhersagefunktionen 1303 und 1403 den zuvor genannten Modulen Bewegungsvorhersagen bereitstellen. Zusätzlich oder alternativ sagt die Mobilobjekttrajektorievorhersage 1503 jeweilige Trajektorien entsprechender Fahrzeuge 110 und VRUs 116 voraus, die verwendet werden können, um die VRU-ITS-S 117 beim Durchführen einer Koppelnavigation zu unterstützen und/oder die V-ITS-S 110 mit einer VRU-Trajektorie- und einer Verhaltensmodellierungsentität zu unterstützen.
  • Bewegungsdynamikvorhersage beinhaltet eine Trajektorie eines beweglichen Objekts, die aus der Entwicklung der aufeinanderfolgenden Mobilpositionen resultiert. Eine Änderung der Trajektorie des beweglichen Objekts oder des Geschwindigkeitsvektors (Beschleunigung/Verlangsamung) des beweglichen Objekts beeinflusst die Bewegungsdynamikvorhersage. Wenn sich die VRUs 116/117 bewegen, weisen sie in den meisten Fällen immer noch eine große Menge an möglicher Bewegungynamik in Bezug auf mögliche Trajektorien und Geschwindigkeitsvektoren auf. Dies bedeutet, dass die Bewegungsdynamikvorhersage 1303, 1403, 1503 verwendet wird, um so schnell wie möglich zu identifizieren, welche Bewegungsdynamik durch den VRU 116 ausgewählt werden wird, und ob diese ausgewählte Bewegungsdynamik einem Kollisionsrisiko mit einem anderen VRU oder einem Fahrzeug unterliegt.
  • Die Bewegungsdynamikvorhersagefunktionen 1303, 1403, 1503 analysieren die Entwicklung mobiler Objekte und die potentiellen Trajektorien, die sich möglicherweise zu einer gegebenen Zeit treffen, um ein Kollisionsrisiko zwischen diesen zu bestimmen. Die bewegungsdynamische Vorhersage arbeitet mit der Ausgabe einer kooperativen Wahrnehmung unter Berücksichtigung der aktuellen Trajektorien der betrachteten Vorrichtung (z.B. der VRU-Vorrichtung 117) für die Berechnung der Wegvorhersage; der aktuellen Geschwindigkeitsvektoren und ihrer vergangenen Entwicklung für die betrachteten Mobilgeräte für die Berechnung der Geschwindigkeitsvektorentwicklungsvorhersage; und des Zuverlässigkeitsniveaus, das mit diesen Variablen assoziiert werden kann. Die Ausgabe dieser Funktion wird der Risikoanalysefunktion bereitgestellt (siehe z.B. 10).
  • In vielen Fällen reicht das Arbeiten nur mit der Ausgabe der kooperativen Wahrnehmung aufgrund der Unsicherheit, die hinsichtlich der VRU-Trajektorieauswahl und ihres Geschwindigkeitsvektors besteht, nicht aus, um eine zuverlässige Vorhersage zu treffen. Komplementäre Funktionen können jedoch dabei helfen, die Zuverlässigkeit der Vorhersage konsistent zu erhöhen. Beispielsweise die Verwendung des Navigationssystems der Vorrichtung (z.B. der VRU-Vorrichtung 117), das dem Benutzer (z.B. dem VRU 116) Unterstützung bereitstellt, die beste Trajektorie zum Erreichen seines geplanten Ziels auszuwählen. Mit der Entwicklung von Mobility as a Service (Maas) kann eine multimodale Routenberechnung dem VRU 116 auch gefährliche Bereiche angeben und dann bei der Bewegungsdynamikvorhersage auf Ebene des multimodalen Routenplans helfen, der vom System bereitgestellt wird. In einem anderen Beispiel kann das Wissen der Gewohnheiten und des Verhaltens des Benutzers (z.B. des VRU 116) zusätzlich oder alternativ verwendet werden, um die Konsistenz und die Zuverlässigkeit der Bewegungsvorhersagen zu verbessern. Einige Benutzer (z.B. VRUs 116/117) folgen denselben Routen, unter Verwendung einer ähnlichen Bewegungsdynamik, zum Beispiel wenn sie zu dem Hauptpunkt von Interesse (POI, Point of Interest) gehen, der mit ihrer Hauptaktivitäten zusammenhängt (z.B. zur Schule gehen, zur Arbeit gehen, Einkaufen, von Zuhause zur nächsten Haltestelle öffentlicher Verkehrsmittel gehen, zum Sportzentrum gehen usw.). Die Vorrichtung (z.B. die VRU-Vorrichtung 117) oder ein Ferndienstzentrum kann diese Gewohnheiten lernen und speichern. In einem anderen Beispiel erfolgt die Angabe seiner gewählten Trajektorie durch den Benutzer (z.B. den VRU 116) selbst, insbesondere beim Ändern derselben (z.B. Verwenden eines Rechtsabbiege- oder Linksabbiegesignals ähnlich Fahrzeugen, wenn eine Richtungsänderung angegeben wird).
  • Die Fahrzeugbewegungssteuerung 1308 kann für computergestützte und/oder automatisierte Fahrzeuge 110 enthalten sein. Sowohl die HMI-Entität 1306 als auch die Fahrzeugbewegungssteuerentität 1308 können durch eine oder mehrere ITS-S-Anwendungen ausgelöst werden. Die Fahrzeugbewegungssteuerentität 1308 kann eine Funktion unter der Verantwortung eines menschlichen Fahrers oder des Fahrzeugs sein, falls dieses in der Lage ist, im automatisierten Modus zu fahren.
  • Die Mensch-Maschine-Schnittstelle (HMI) 1306, 1406 und 1506 ermöglicht, falls vorhanden, die Konfiguration anfänglicher Daten (Parameter) in den Verwaltungsentitäten (z.B. VRU-Profilverwaltung) und in anderen Funktionen (z.B. VBS-Verwaltung). Die HMI 1306, 1406 und 1506 ermöglicht eine Kommunikation externer Ereignisse bezüglich des VBS mit dem Vorrichtungseigentümer (Benutzer), einschließlich des Warnens vor einem unmittelbaren Kollisionsrisiko (TTC < 2 s), das durch wenigstens ein Element des Systems detektiert wird, und des Signalisierens eines Kollisionsrisikos (z.B. TTC > 2 Sekunden), das durch mindestens ein Element des Systems detektiert wird. Für ein VRU-System 117 (z.B. das persönliche Rechensystem 1400) liefert die HMI ähnlich einem Fahrzeugführer die Informationen an den VRU 116 unter Berücksichtigung seines Profils (z.B. werden für eine blinde Person die Informationen unter Verwendung von Zugriffsfähigkeiten der jeweiligen Plattform des persönlichen Rechensystems 1400 mit einem klaren Schallpegel präsentiert). Bei verschiedenen Implementierungen kann die HMI 1306, 1406 und 1506 Teil des Warnsystems sein.
  • Die verbundenen Systeme 1307, 1407 und 1507 beziehen sich auf Komponenten/Vorrichtungen, die zum Verbinden eines Systems mit einem oder mehreren anderen Systemen verwendet werden. Als Beispiele können die verbundenen Systeme 1307, 1407 und 1507 Kommunikationsschaltungsanordnungen und/oder Funkeinheiten beinhalten. Das VRU-System 1400 kann ein verbundenes System sein, das aus bis zu 4 unterschiedlichen Geräteebenen besteht. Das VRU-System 1400 kann auch ein Informationssystem sein, das aus Ereignissen resultierende Informationen in Echtzeit sammelt, die gesammelten Informationen verarbeitet und sie zusammen mit verarbeiteten Ergebnissen speichert. Auf jeder Ebene des VRU-Systems 1400 beziehen sich die Informationserfassung, -verarbeitung und -speicherung auf das implementierte Funktions- und Datenverteilungsszenario.
  • 3. RECHENSYSTEM- UND HARDWAREKONFIGURATIONEN
  • 16 und 17 stellen Beispiele für Edge-Computing-Systeme und -Umgebungen dar, die beliebige der hierin erörterten Rechenknoten oder -vorrichtungen verwirklichen können. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, die in der Lage sind, mit anderen Edge-, Netzwerk- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Computing-Vorrichtung als ein Smartphone, eine mobile Rechenvorrichtung, ein Smartgerät, ein fahrzeuginternes Rechensystem (z.B. ein Navigationssystem) oder eine andere Vorrichtung oder ein anderes System umgesetzt sein, das in der Lage ist, die beschriebenen Funktionen durchzuführen.
  • 16 veranschaulicht ein Beispiel für ein Infrastrukturgerät 1600 gemäß verschiedenen Ausführungsformen. Das Infrastrukturgerät 1600 (oder „System 1600“) kann als eine Basisstation, eine Roadside Unit (RSU), eine Roadside-ITS-S (R-ITS-S), ein Radio Head, eine Relaisstation, ein Server, ein Gateway und/oder ein hier erörtertes beliebiges anderes Element/Vorrichtung implementiert sein.
  • Das System 1600 weist eine Anwendungsschaltungsanordnung 1605, eine Basisbandschaltungsanordnung 1610, ein oder mehrere Front-End-Funkmodule (RFEMs) 1615, eine Speicherschaltungsanordnung 1620, eine integrierte Leistungsverwaltungsschaltungsanordnung (PMIC) 1625, eine Leistungs-T-Schaltungsanordnung 1630, eine Netzwerksteuerungsschaltungsanordnung 1635, einen Netzwerkschnittstellenanschluss 1640, eine Positionsbestimmungsschaltungsanordnung 1645 und eine Benutzerschnittstelle 1650 auf. In einigen Ausführungsformen kann die Vorrichtung 1600 zusätzliche Elemente umfassen, wie etwa zum Beispiel Arbeitsspeicher/Datenspeicher, Anzeige, Kamera, Sensor oder E/A-Schnittstelle. Bei anderen Ausführungsformen können die unten beschriebenen Komponenten in mehr als einer Vorrichtung enthalten sein. Zum Beispiel können die Schaltungen in mehr als einer Vorrichtung für CRAN, CR, vBBU oder anderen ähnlichen Implementierungen separat enthalten sein.
  • Die Anwendungsschaltungsanordnung 1605 beinhaltet Schaltungsanordnungen, wie etwa unter anderem einen oder mehrere Prozessoren (oder Prozessorkerne), einen Cache-Speicher und eines oder mehrere von Low-Dropout-Spannungsreglern (LDOs), Interruptsteuerungen, seriellen Schnittstellen, wie etwa SPI, I2C oder einem universellen programmierbaren seriellen Schnittstellenmodul, einer Echtzeituhr (RTC), Timer-Zähler, einschließlich Intervall- und Watchdog-Timer, Allzweck-E/A, Speicherkartensteuerungen, wie etwa Secure Digital (SD) MultiMediaCard (MMC) oder dergleichen, Universal Serial Bus (USB)-Schnittstellen, Mobile Industry Processor Interface (MIPI)-Schnittstellen und Joint Test Access Group (JTAG)-Testzugangsports. Die Prozessoren (oder Kerne) der Anwendungsschaltungsanordnung 1605 können mit Speicherelementen gekoppelt sein oder diese beinhalten und dazu ausgelegt sein, Anweisungen auszuführen, die im Speicher gespeichert sind, um die Ausführung verschiedener Anwendungen oder Betriebssysteme auf dem System 1600 zu ermöglichen. In einigen Implementierungen können die Speicher-/Speicherungselemente eine chipinterne Speicherschaltungsanordnung sein, die einen beliebigen geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flashspeicher, Festkörperspeicher und/oder einen beliebigen anderen Typ von Speichervorrichtungstechnologie, wie etwa jene hier erörterten, beinhalten kann.
  • Der eine oder die mehreren Prozessoren der Anwendungsschaltungsanordnung 1605 können zum Beispiel einen oder mehrere Prozessorkerne (CPUs), einen oder mehrere Anwendungsprozessoren, eine oder mehrere Grafikverarbeitungseinheiten (GPUs), einen oder mehrere Reduced Instruction Set Computing (RISC)-Prozessoren, einen oder mehrere Acorn-RISC-Machine (ARM)-Prozessoren, einen oder mehrere Complex Instruction Set Computing (CISC)-Prozessoren, einen oder mehrere DSPs, ein oder mehrere FPGAs, ein oder mehrere PLDs, eine oder mehrere ASICs, einen oder mehrere Mikroprozessoren oder Mikrocontroller oder eine beliebige geeignete Kombination davon umfassen. In einigen Ausführungsformen kann die Anwendungsschaltungsanordnung 1605 einen Spezialprozessor/eine Spezialsteuerung zum Arbeiten gemäß den verschiedenen Ausführungsformen hierin umfassen oder sein. Als Beispiele können zu dem einen oder den mehreren Prozessoren der Anwendungsschaltungsanordnung 1605 zählen: einer oder mehrere Intel Pentium®-, Core®- oder Xeon®-Prozessoren; Advanced Micro Devices (AMD) Ryzen®-Prozessoren, Accelerated Processing Units (APUs) oder Epyc®-Prozessoren; ARM-basierte Prozessor(en), die von ARM Holdings, Ltd., lizenziert sind, wie etwa die Cortex-A-Prozessorfamilie von ARM, und den von Cavium™, Inc. bereitgestellten ThunderX2®; ein MIPS-basiertes Design von MIPS Technologies, Inc., wie etwa Warrior P-class-Prozessoren von MIPS; und/oder dergleichen. In einigen Ausführungsformen verwendet das System 1600 möglicherweise keine Anwendungsschaltungsanordnung 1605 und kann stattdessen einen Spezialprozessor/eine Spezialsteuerung zum Verarbeiten von IP-Daten umfassen, die zum Beispiel von einem EPC oder 5GC empfangen werden.
  • Bei manchen Implementierungen kann die Anwendungsschaltungsanordnung 1605 einen oder mehrere Hardwarebeschleuniger umfassen, die Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen oder dergleichen sein können. Der eine oder die mehreren Hardwarebeschleuniger können zum Beispiel Beschleuniger für Computer Vision (CV) und/oder Deep Learning (DL) beinhalten. Als Beispiele: Die programmierbaren Verarbeitungsvorrichtungen können ein oder mehrere Field Programmable Gate Arrays (FPGAs); programmierbare Logikvorrichtungen (PLDs), wie etwa komplexe PLDs (CPLDs), PLDs mit hoher Kapazität (HCPLDs) und dergleichen; ASICs, wie etwa strukturierte ASICs und dergleichen; programmierbare SoCs (PSoCs); und/oder dergleichen sein. Bei solchen Implementierungen kann die Schaltungsanordnung der Anwendungsschaltungsanordnung 1605 Logikblöcke oder Logikstruktur und andere miteinander verbundene Ressourcen umfassen, die programmiert werden können, um verschiedene Funktionen durchzuführen, wie etwa die Prozeduren, Verfahren, Funktionen usw. der verschiedenen hierin erörterten Ausführungsformen. Bei solchen Ausführungsformen kann die Schaltungsanordnung der Anwendungsschaltungsanordnung 1605 Speicherzellen (z. B. löschbaren programmierbaren Nur-Lese-Speicher (EPROM), elektrisch löschbaren programmierbaren Nur-Lese-Speicher (EEPROM), Flash-Speicher, statischen Speicher (z. B. statischen Direktzugriffsspeicher (SRAM), Antifuses usw.)) umfassen, die zum Speichern von Logikblöcken, Logikstruktur, Daten usw. in Nachschlagetabellen (LUTs) und dergleichen verwendet werden.
  • Bei einigen Implementierungen, wie etwa Implementierungen, bei denen Subsysteme der Edge-Knoten 130, Zwischenknoten 120 und/oder Endpunkte 110 von Figur XS1 einzelne Softwareagenten oder KI-Agenten sind, ist jeder Agent in einem jeweiligen Hardwarebeschleuniger implementiert, der mit einem oder mehreren geeigneten Bitströmen oder Logikblöcken konfiguriert wird, um seine jeweiligen Funktionen durchzuführen. Bei diesen Implementierungen können Prozessor(en) und/oder Hardwarebeschleuniger der Anwendungsschaltungsanordnung 1605 speziell zum Betreiben der Agenten und/oder zur Maschinenlernfunktionalität zugeschnitten sein, wie etwa ein Cluster von KI-GPUs, von Google® Inc. entwickelte Tensorverarbeitungseinheiten (TPUs), von AlphaICs® bereitgestellte Real KI-Prozessoren (RAPs™), Nervana™ Neural Network Processors (NNPs), die von Intel® Corp. bereitgestellt werden, Intel® Movidius ™ Myriad™ X Vision Processing Unit (VPU), NVIDIA® PX™-basierte GPUs, der NM500 Chip, der von General Vision® bereitgestellt wird, Hardware 3, die von Tesla® Inc., bereitgestellt wird, ein Epiphany™-basierter Prozessor, der von Adapteva® bereitgestellt wird, oder dergleichen. In einigen Ausführungsformen kann der Hardwarebeschleuniger als ein KI-beschleunigender Co-Prozessor implementiert sein, wie der Hexagon 685 DSP, der von Qualcomm® bereitgestellt wird, der PowerVR 2NX Neural Net Accelerator (NNA), der von Imagination Technologies Limited® bereitgestellt wird, der Neural Engine-Kern innerhalb des Bionic SoC Apple® A11 oder A12, die Neuronal Processing Unit innerhalb des HiSilicon Kirin 970, das von Huawei® bereitgestellt wird, und/oder dergleichen.
  • Die Basisbandschaltungsanordnung 1610 kann zum Beispiel als ein Solder-Down-Substrat mit einer oder mehreren integrierten Schaltungen, eine einzelne gekapselte integrierte Schaltung, die an eine Hauptleiterplatte gelötet ist, oder ein Mehrchipmodul, das zwei oder mehr integrierte Schaltungen enthält, implementiert sein. Die Basisbandschaltungsanordnung 1610 umfasst eine oder mehrere Verarbeitungsvorrichtungen (z.B. Basisbandprozessoren) zum Ausführen verschiedener Protokoll- und Funksteuerfunktionen. Die Basisbandschaltungsanordnung 1610 kann über eine Schnittstelle eine Verbindung mit einer Anwendungsschaltungsanordnung des Systems 1600 zum Erzeugen und Verarbeiten von Basisbandsignalen und zum Steuern von Operationen der RFEMs 1615 herstellen. Die Basisbandschaltungsanordnung 1610 kann verschiedene Funksteuerfunktionen handhaben, die Kommunikation mit einem oder mehreren Funknetzwerken über die RFEMs 1615 ermöglichen. Die Basisbandschaltungsanordnung 1610 kann eine Schaltungsanordnung, wie etwa unter anderem einen oder mehrere Einzelkern- oder Mehrkernprozessoren (z. B. einen oder mehrere Basisbandprozessoren) oder Steuerlogik, beinhalten, um Basisbandsignale, die von einem Empfangssignalpfad der RFEMs 1515 empfangen werden, zu verarbeiten und Basisbandsignale, die für die RFEMs 1515 über einen Übertragungssignalpfad bereitzustellen sind, zu generieren. Bei verschiedenen Ausführungsformen kann die Basisbandschaltungsanordnung 1610 ein Echtzeit-OS (RTOS) implementieren, um Ressourcen der Basisbandschaltungsanordnung 1610 zu managen, Aufgaben zu planen usw. Zu Beispielen für das RTOS können Operating System Embedded (OSE)™, das von Enea® bereitgestellt wird, Nukleus RTOS™, das von Mentor Graphics® bereitgestellt wird, Versatile Real-Time Executive (VRTX), das von Mentor Graphics® bereitgestellt wird, ThreadX™, das von Express Logics® bereitgestellt wird, FreeRTOS, REX-OS, das von Qualcomm® bereitgestellt wird, OKL4, das von Open Kernel (OK) Labs® bereitgestellt wird, oder jedes andere geeignete RTOS, wie etwa die hierin erörterten, zählen.
  • Obwohl in 16 nicht gezeigt, beinhaltet die Basisbandschaltungsanordnung 1610 bei einer Ausführungsform einzelne Verarbeitungsvorrichtung(en), um ein oder mehrere Drahtloskommunikationsprotokolle zu betreiben (z. B. einen „Multiprotokoll-Basisbandprozessor“ oder eine „Protokollverarbeitungsschaltungsanordnung“), und einzelne Verarbeitungsvorrichtung(en), um Funktionen der physikalischen Schicht (PHY) zu implementieren. Bei dieser Ausführungsform betreibt oder implementiert die Protokollverarbeitungsschaltungsanordnung verschiedene Protokollschichten/Entitäten eines oder mehrerer Drahtloskommunikationsprotokolle. In einem ersten Beispiel kann die Protokollverarbeitungsschaltungsanordnung LTE-Protokollentitäten und/oder 5G/NR-Protokollentitäten betreiben, wenn die RFEMs 1615 ein zellulares Hochfrequenzkommunikationssystem sind, wie eine Millimeterwellen- (mmWave-) Kommunikationsschaltungsanordnung oder eine andere geeignete zellulare Kommunikationsschaltungsanordnung. Bei dem ersten Beispiel würde die Protokollverarbeitungsschaltungsanordnung MAC, RLC, PDCP, SDAP, RRC und NAS-Funktionen betreiben. In einem zweiten Beispiel kann die Protokollverarbeitungsschaltungsanordnung ein oder mehrere IEEE-basierte Protokolle betreiben, wenn die RFEMs 1615 ein WiFi-Kommunikationssystem sind. In dem zweiten Beispiel würde die Protokollverarbeitungsschaltungsanordnung WiFi MAC- und LLC-Funktionen betreiben. Die Protokollverarbeitungsschaltungsanordnung kann eine oder mehrere Speicherstrukturen (nicht gezeigt) zum Speichern von Programmcode und Daten zum Betreiben der Protokollfunktionen sowie einen oder mehrere Verarbeitungskerne (nicht gezeigt) zum Ausführen des Programmcodes und Durchführen verschiedener Operationen unter Verwendung der Daten einschließen. Die Protokollverarbeitungsschaltungsanordnung stellt Steuerfunktionen für die Basisbandschaltungsanordnung 1610 und/oder die RFEMs 1615 bereit. Die Basisbandschaltungsanordnung 1610 kann auch Funkkommunikationen für mehr als ein drahtloses Protokoll unterstützen.
  • Fortfahrend mit der zuvor erwähnten Ausführungsform: Die Basisbandschaltungsanordnung 1610 beinhaltet eine oder mehrere einzelne Verarbeitungsvorrichtungen zum Implementieren von PHY- einschließlich HARQ-Funktionen, Verwürfeln und/oder Entwürfen, Codieren und/oder Decodieren, Schicht-Mapping und/oder -Demapping, Abbilden von Modulationssymbolen, Empfangssymbol- und/oder Bitmetrikbestimmung, Mehrantennenport-Vorcodierung und/oder -Decodierung, die eine oder mehrere von Raum-Zeit-, Raum-Frequenz- oder Raumcodierung beinhalten können, Referenzsignalgenerierung und/oder -detektion, Präambelsequenzgenerierung und/oder -decodierung, Synchronisationssequenzgenerierung und/oder -detektion, Steuerkanalsignal-Blinddecodierung, Funkfrequenzverschiebung und andere verwandte Funktionen usw. Die Modulations-/Demodulationsfunktionalität kann Fast-FourierTransformation (FFT), Vorcodierung oder Konstellations-Mapping-/-Demapping-Funktionalität umfassen. Die Codierungs-/Decodierungsfunktionalität kann Konvolutions-, Schwanzbeiß-Konvolutions-, Turbo-, Viterbi-oder LDPC-Codierung (LDPC: Low Density Parity Check) einschließen. Ausführungsformen der Modulations-/Demodulations- und Codier-/Decodier-Funktionalität sind nicht auf diese Beispiele beschränkt und können in anderen Ausführungsformen eine andere geeignete Funktionalität aufweisen.
  • Die Benutzerschnittstellenschaltungsanordnung 1650 kann eine oder mehrere Benutzerschnittstellen, die dazu ausgelegt sind, eine Benutzerinteraktion mit dem System 1600 zu ermöglichen, oder Peripheriekomponentenschnittstellen, die dazu ausgelegt sind, eine Peripheriekomponenteninteraktion mit dem System 1600 zu ermöglichen, beinhalten. Benutzerschnittstellen können unter anderem eine oder mehrere physische oder virtuelle Tasten (z.B. eine Rücksetztaste), einen oder mehrere Anzeigegeräte (z.B. Leuchtdioden (LEDs)), eine physische Tastatur oder ein physisches Tastenfeld, eine Maus, ein Touchpad, einen Touchscreen, Lautsprecher oder andere audioemittierende Vorrichtungen, Mikrofone, einen Drucker, einen Scanner, ein Headset, einen Anzeigebildschirm oder eine Anzeigevorrichtung usw. umfassen. Peripheriekomponentenschnittstellen können unter anderem einen nichtflüchtigen Speicherport, einen Universal Serial Bus (USB)-Port, eine Audiobuchse, eine Stromversorgungsschnittstelle usw. beinhalten.
  • Die Funk-Frontend-Module (RFEMs, radio front end modules) 1615 können ein Millimeterwellen- (mmWave-) RFEM und eine oder mehrere integrierte Sub-mmWave-Hochfrequenzschaltungen (RFICs) umfassen. In einigen Implementierungen können die eine oder die mehreren Sub-mmWave-RFICs physisch von dem mmWave-RFEM getrennt sein. Die HFICs können Verbindungen mit einer oder mehreren Antennen oder Antennenarrays beinhalten und das HFEM kann mit mehreren Antennen verbunden sein. Bei alternativen Implementierungen können sowohl mmWave- als auch Sub-mmWave-Funkfunktionen in demselben physischen RFEM 1615 implementiert sein, das sowohl mmWave-Antennen als auch Sub-mmWave umfasst. Das Antennenarray umfasst ein oder mehrere Antennenelemente, von denen jedes dazu konfiguriert ist, elektrische Signale in Funkwellen umzuwandeln, die sich über die Luft ausbreiten, und empfangene Funkwellen in elektrische Signale umzuwandeln. Zum Beispiel werden digitale Basisbandsignale, die durch die Basisbandschaltungsanordnung 1610 bereitgestellt werden, in analoge RF-Signale (z.B. modulierte Wellenform) konvertiert, die verstärkt und über die Antennenelemente des Antennenarrays einschließlich eines oder mehrerer Antennenelemente (nicht gezeigt) übertragen werden. Die Antennenelemente können omnidirektional, gerichtet oder eine Kombination davon sein. Die Antennenelemente können in einer Vielfalt von Anordnungen ausgebildet sein, wie bekannt ist und/oder hier erörtert wird. Das Antennenarray kann Mikrostreifenantennen oder gedruckte Antennen umfassen, die auf der Oberfläche einer oder mehrerer Leiterplatten gefertigt sind. Das Antennenarray kann als ein Patch aus Metallfolie (z.B. eine Patchantenne) in einer Vielfalt von Formen gebildet sein und kann unter Verwendung von Metallübertragungsleitungen oder dergleichen mit der HF-Schaltungsanordnung gekoppelt sein.
  • Die Speicherschaltungsanordnung 1620 kann flüchtigen Speicher, einschließlich dynamischen Direktzugriffsspeichers (DRAM) und/oder synchronen dynamischen Direktzugriffsspeichers (SDRAM), und nichtflüchtigen Speicher (NVM), einschließlich elektrisch löschbaren Hochgeschwindigkeitsspeichers (üblicherweise als Flash-Speicher bezeichnet), Phasenwechsel-Direktzugriffsspeichers (PRAM), magnetoresistiven Direktzugriffsspeichers (MRAM) usw., und kann die dreidimensionalen (3D) Crosspoint (XPOINT)-Speicher von Intel® und Micron® beinhalten. Die Speicherschaltungsanordnung 1620 kann als eingelötete integrierte Schaltungen und/oder gesockelte Speichermodule und/oder einsteckbare Speicherkarten implementiert sein.
  • Die Speicherschaltungsanordnung 1620 ist dazu konfiguriert, Rechenlogik (oder „Module“) in Form von Software-, Firmware- oder Hardwarebefehlen zu speichern, um die hierin beschriebenen Techniken zu implementieren. Die Rechenlogik oder -Module können unter Verwendung einer geeigneten Programmiersprache oder geeigneter Entwicklungstools entwickelt werden, wie etwa einer beliebigen Programmiersprache oder einem beliebigen Entwicklungstool, die bzw. das hierin erörtert wird. Die Rechenlogik kann eingesetzt werden, um Arbeitskopien und/oder permanente Kopien von Programmieranweisungen für den Betrieb verschiedener Komponenten des Appliance-Infrastrukturgeräts 1600, eines Betriebssystems des Infrastrukturgeräts 1600, einer oder mehrerer Anwendungen und/oder zum Ausführen der hierin erörterten Ausführungsformen zu speichern. Die Rechenlogik kann als Anweisungen zur Ausführung durch die Prozessoren der Anwendungsschaltungsanordnung 1605 gespeichert oder in die Speicherschaltungsanordnung 1620 geladen werden, um die hierin beschriebenen Funktionen bereitzustellen oder durchzuführen. Die verschiedenen Elemente können durch Assembleranweisungen, die durch Prozessoren der Anwendungsschaltungsanordnung 1605 unterstützt werden, oder Hochsprachen, die in solche Anweisungen kompiliert werden können, implementiert werden. Die permanente Kopie der Programmieranweisungen kann in persistenten Speichervorrichtungen der Speicherschaltungsanordnung 1620 werksseitig während der Herstellung oder vor Ort durch zum Beispiel ein (nicht gezeigtes) Verteilungsmedium, durch eine Kommunikationsschnittstelle (z.B. von einem Verteilungsserver) und/oder über die Luft (OTA, Over-the-Air) platziert werden.
  • Wie nachstehend ausführlicher erörtert, kann das Infrastrukturgerät 1600 dazu ausgelegt sein, eine spezielle V2X-RAT basierend auf der Anzahl von vUEs 121 zu unterstützen, die die spezielle V2X-RAT unterstützen (oder dazu in der Lage sind). Bei Ausführungsformen kann die Speicherschaltungsanordnung 1620 ein RAT-Konfigurationssteuermodul speichern, um die (Re-)Konfiguration des Infrastrukturgeräts 1600 zum Unterstützen einer speziellen RAT und/oder V2X-RAT zu steuern. Das Konfigurationssteuermodul stellt eine Schnittstelle zum Triggern von (Re-)Konfigurationsaktionen bereit. In einigen Ausführungsformen kann die Speicherschaltungsanordnung 1620 auch ein RAT-Software(SW)-Verwaltungsmodul speichern, um SW-Lade- oder -Bereitstellungsprozeduren und (De)aktivierungs-SW im Infrastrukturgerät 1600 zu implementieren. Bei jeder dieser Ausführungsformen kann die Speicherschaltungsanordnung 1620 mehrere V2X-RAT-Softwarekomponenten speichern, die jeweils Programmcode, Anweisungen, Module, Baugruppen, Pakete, Protokollstapel, Software-Engine(s) usw. zum Betreiben des Infrastrukturgeräts 1600 oder von Komponenten davon (z.B. RFEMs 1615) gemäß einer entsprechenden V2X-RAT umfassen. Wenn eine V2X-RAT-Komponente durch die Anwendungsschaltungsanordnung 1605 und/oder die Basisbandschaltungsanordnung 1610 konfiguriert oder ausgeführt wird, arbeitet das Infrastrukturgerät 1600 gemäß der V2X-RAT-Komponente.
  • In nem ersten Beispiel kann eine erste V2X-AT-Komponente eine C-V2X-Komponente sein, die LTE- und/oder C-V2X-Protokollstapel beinhaltet, die es dem Infrastrukturgerät 1600 ermöglichen, C-V2X zu unterstützen und/oder Zeit-/Frequenz-Funkressourcen gemäß LTE- und/oder C-V2X-Standards bereitzustellen. Solche Protokollstapel können einen Protokollstapel auf Steuerebene beinhalten, der die Non-Access-Stratum (NAS), Funkressourcensteuerung (RRC), Paketdatenkonvergenzprotokoll (PDCP), Funkverbindungssteuerung (RLC), Medienzugangssteuerung (MAC), und Physikalische (PHY)-Schichtentitäten beinhaltet; und einen Protokollstapel auf Benutzerebene, der die Schichtentitäten General Packet Radio Service (GPRS)-Tunnelingprotokoll für die Benutzerebenenschicht (GTP-U), Benutzer-Datagrammprotokoll (UDP), Internetprotokoll (IP), PDCP, RLC, MAC und PHY beinhaltet. Diese Protokollentitäten auf Steuerebene und Benutzerebene sind ausführlicher in 3GPP TS 36.300 und/oder 3GPP TS 38.300 sowie anderen 3GPP-Spezifikationen erörtert. In einigen Ausführungsformen kann die IP-Schichtenentität durch eine Zuweisungs- und Retentionspriorität-(ARP-) Schichtentität oder eine andere Nicht-IP-Protokoll-Schichtentität ersetzt werden. Einige oder alle der vorstehend erwähnten Protokollschichtentitäten können „Relais“-Versionen sein, in Abhängigkeit davon, ob das Infrastrukturgerät 1600 als ein Relais agiert. In einigen Ausführungsformen kann der Benutzerebenen-Protokollstapel der in 3GPP TS 23.303 v15.1.0 (2018-06) erörterte Protokollstapel der PC5-Benutzerebene (PC5-U) sein.
  • Bei einem zweiten Beispiel kann eine zweite V2X-RAT-Komponente eine ITS-G5-Komponente sein, die unter anderem Protokollstapel von ITS-G5 (IEEE 802.11p) und/oder Wireless Access in Vehicular Environments (WAVE) (IEEE 1609.4) beinhaltet, die es dem Infrastrukturgerät ermöglichen, ITS-G5-Kommunikationen zu unterstützen und/oder Zeit-Frequenz-Funkressourcen gemäß ITS-G5- und/oder anderen WiFi-Standards bereitzustellen. Die ITS-G5- und WAVE-Protokollstapel beinhalten unter anderem eine DSRC/WAVE-PHY und MAC-Schichtentitäten, die auf dem IEEE 802.1 1p-Protokoll basieren. Die DSRC-/WAVE-PHY-Schicht ist für das Erhalten von Daten zum Übertragen über ITS-G5-Kanäle von höheren Schichten sowie das Empfangen von Rohdaten über die ITS-G5-Kanäle und das Bereitstellen von Daten für höhere Schichten verantwortlich. Die MAC-Schicht organisiert die Datenpakete in Netzwerkrahmen. Die MAC-Schicht kann in eine untere DSRC-/WAVE-MAC-Schicht, die auf IEEE 802.11p basiert, und eine obere WAVE-MAC-Schicht (oder eine WAVE-Mehrkanalschicht), die auf IEEE 1609.4 basiert, aufgeteilt sein. IEEE 1609 baut auf IEEE 802.1 1p auf und definiert eine oder mehrere der anderen höheren Schichten. Die ITS-G5-Komponente kann auch eine Logical Link Control (LLC)-Schichtentität beinhalten, um Multiplex- und Demultiplexoperationen der Schicht 3 (L3) durchzuführen. Die LLC-Schicht (z. B. IEEE 802.2) ermöglicht es mehreren Netzwerk-L3-Protokollen, über denselben physischen Link zu kommunizieren, indem ermöglicht wird, dass die L3-Protokolle in LLC-Feldern spezifiziert werden.
  • Zusätzlich zu den V2X-RAT-Komponenten kann die Speicherschaltungsanordnung 1620 auch eine RAT-Übersetzungskomponente speichern, wobei es sich um eine Software-Engine, eine API, eine Bibliothek, Objekt(e), Engine(s) oder eine andere Funktionseinheit zum Bereitstellen von Übersetzungsdiensten für vUEs 121 handelt, die mit unterschiedlichen V2X-Fähigkeiten ausgestattet sind. Zum Beispiel kann die RAT-Übersetzungskomponente, wenn sie konfiguriert oder ausgeführt wird, das Infrastrukturgerät 1600 zum Konvertieren oder Übersetzen einer ersten Nachricht, die gemäß der ersten V2X-RAT (z. B. C-V2X) erhalten wird, in eine zweite Nachricht zur Übertragung unter Verwendung einer zweiten V2X-RAT (z. B. ITS-G5) veranlassen. Bei einem Beispiel kann die RAT-Übersetzungskomponente die Übersetzung oder Konvertierung durch Extrahieren von Daten aus einem oder mehreren Feldern der ersten Nachricht und Einfügen der extrahierten Daten in entsprechende Felder der zweiten Nachricht durchführen. Bei anderen Ausführungsformen können auch andere Übersetzungs-lU mwandlungsverfahren verwendet werden. Bei einigen Ausführungsformen kann die RAT-Übersetzungskomponente einen geeigneten Übersetzer zum Übersetzen einer oder mehrerer Quellennachrichten in einem Quellformat in eine oder mehrere Zielnachrichten in einem Zielformat einsetzen, und sie kann jede geeignete Kompilierungsstrategie für die Übersetzung einsetzen. Der Übersetzer kann in Abhängigkeit vom Typ der V2X-RATs auch unterschiedliche Implementierungen aufweisen, die durch das Infrastrukturgerät 1600 unterstützt werden (z. B. Speicherabbildung, Anweisungssatz, Programmiermodell usw.).
  • Die PMIC 1625 kann Spannungsregler, Überspannungsschutzelemente, Leistungsalarmdetektionsschaltungsanordnungen und eine oder mehrere Reserveleistungsquellen, wie etwa eine Batterie oder einen Kondensator, beinhalten. Die Leistungsalarmdetektionsschaltungsanordnung kann Zustände von Spannungsabfall (Unterspannung) und/oder Spannungsanstieg (Überspannung) detektieren. Die T-Leistungsschaltungsanordnung 330 kann elektrische Leistung bereitstellen, die von einem Netzwerkkabel entnommen wird, um sowohl eine Leistungsversorgung als auch eine Datenkonnektivität an das Infrastrukturgerät 1600 unter Verwendung eines einzigen Kabels bereitzustellen.
  • Die Netzwerksteuerungsschaltungsanordnung 1635 stellt Konnektivität mit einem Netzwerk unter Verwendung eines Standardnetzwerkschnittstellenprotokolls, wie etwa Ethernet, Ethernet über GRE-Tunnel, Ethernet über Multiprotocol Label Switching (MPLS), oder eines anderen geeigneten Protokolls, wie etwa den hierin erörterten, bereit. Netzwerkkonnektivität kann zu/von dem Infrastrukturgerät 1600 über den Netzwerkschnittstellenverbinder 1640 unter Verwendung einer physischen Verbindung bereitgestellt werden, die elektrisch (allgemein als eine „Kupferzwischenverbindung“ bezeichnet), optisch oder drahtlos sein kann. Die Netzwerksteuerungsschaltungsanordnung 1635 kann einen oder mehrere dedizierte Prozessoren und/oder ein oder mehrere dedizierte FPGAs zum Kommunizieren unter Verwendung eines oder mehrerer der zuvor genannten Protokolle beinhalten. In einigen Implementierungen kann die Netzwerksteuerungsschaltungsanordnung 1635 mehrere Steuerungen zum Bereitstellen von Konnektivität mit anderen Netzwerken unter Verwendung des gleichen oder unterschiedlicher Protokolle bereitstellen. Bei verschiedenen Ausführungsformen ermöglicht die Netzwerksteuerungsschaltungsanordnung 1635 Kommunikation mit assoziierten Geräten und/oder mit einem Backend-System (z.B. Server(n), Kernnetzwerk, Cloud-Dienst usw.), die über eine geeignete Gateway-Vorrichtung stattfinden kann.
  • Die Positionsbestimmungsschaltungsanordnung 1645 umfasst eine Schaltungsanordnung zum Empfangen und Decodieren von Signalen, die durch ein Positionsbestimmungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/rundgesendet werden. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) beinhalten das globale Positionierungssystem (GPS) der Vereinigten Staaten, das globale Navigationssystem (GLONASS) Russlands, das Galileo-System der Europäischen Union, das Navigationssatellitensystem BeiDou Chinas, ein regionales Navigationssystem oder GNSS-Erweiterungssystem (z.B. Navigation with Indian Constellation (NAVIC), Quasi-Zenit-Satellite-System (QZSS) Japans, Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) Frankreichs usw.) oder dergleichen. Die Positionsbestimmungsschaltungsanordnung 1645 umfasst verschiedene Hardwareelemente (darunter z.B. Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen), um mit Komponenten eines Positionsbestimmungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. Bei einigen Ausführungsformen kann die Positionsbestimmungsschaltungsanordnung 1645 ein Mikrotechnologie für Positionsbestimmung, Navigation und Timing (Micro-PNT)-IC beinhalten, das ein Master-Timing-Taktsignal verwendet, um eine Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen. Die Positionsbestimmungsschaltungsanordnung 1645 kann auch Teil der Basisbandschaltungsanordnung 1610 und/oder der RFEMs 1615 sein oder damit interagieren, um mit den Knoten und Komponenten des Positionsbestimmungsnetzwerks zu kommunizieren. Die Positionsbestimmungsschaltungsanordnung 1645 kann auch Positionsdaten und/oder Zeitdaten für die Anwendungsschaltungsanordnung 1605 bereitstellen, die die Daten verwenden kann, um Operationen mit verschiedenen anderen Infrastrukturgeräten oder dergleichen zu synchronisieren.
  • Die in 3 gezeigten Komponenten können unter Verwendung einer Schnittstellenschaltungsanordnung 306 oder einer Zwischenverbindung (IX, Interconnect) 1606 miteinander kommunizieren, die eine beliebige Anzahl von Bus- und/oder Zwischenverbindungs (IX)-Technologien beinhalten können, wie etwa Industriestandardarchitektur (ISA), erweiterte ISA (EISA), interintegrierte Schaltung (I2C), eine serielle Peripherieschnittstelle (SPI), Punkt-zu-Punkt-Schnittstellen, Power Management Bus (PMBus), Peripheral Component Interconnect (PCI), PCI express (PCIe), Intel® Ultra Path Interface (UPI), Intel® Accelerator Link (IAL), Common Application Programming Interface (CAPI), Intel® QuickPath Interconnect (QPI), Ultra Path Interconnect (UPI), Intel® Omni-Path Architecture (OPA) IX, RapidlO™ System IXs, Cache Coherent Interconnect for Accelerators (CCIA), Gen-Z Consortium IXs, Open Coherent Accelerator Processor Interface (OpenCAPI) IX, eine HyperTransport-Zwischenverbindung und/oder eine beliebige Anzahl anderer IX-Technologien. Die IX-Technologie kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
  • 17 veranschaulicht ein Beispiel für Komponenten, die in einem Edge-Rechenknoten 1750 zum Implementieren der hierin beschriebenen Techniken (z.B. Operationen, Prozesse, Verfahren und Methoden) vorhanden sein können. Dieser Edge-Rechenknoten 1750 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 1700 bereit, wenn er als eine Rechenvorrichtung (z.B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) oder als Teil davon implementiert ist. Der Edge-Rechenknoten 1750 kann beliebige Kombinationen der hierin erwähnten Hardware- oder Logikkomponenten umfassen, und er kann eine beliebige Vorrichtung, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendet werden kann, umfassen oder eine Verbindung damit herstellen. Die Komponenten können als ICs, Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Anweisungssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die im Edge-Computing-Knoten 1750 angepasst ist, oder als Komponenten implementiert sein, die anderweitig in einem Chassis eines größeren Systems integriert sind.
  • Der Edge-Rechenknoten 1750 beinhaltet eine Verarbeitungsschaltungsanordnung in Form eines oder mehrerer Prozessoren 1752. Die Prozessorschaltungsanordnung 1752 beinhaltet Schaltungsanordnungen, wie etwa unter anderem einen oder mehrere Prozessorkerne und eines oder mehrere von Cache-Speicher, Low-Dropout-Spannungsreglern (LDOs), Interruptsteuerungen, seriellen Schnittstellen, wie etwa SPI, I2C oder universelle programmierbare serielle Schnittstellenschaltung, Echtzeituhr (RTC), Timer-Zähler, einschließlich Intervall- und Watchdog-Timern, Allzweck-E/A, Speicherkartensteuerungen, wie etwa Secure Digital/Multimedia Card (SD/MMC) oder ähnliches, Schnittstellen, Mobile Industry Processor Interface (MIPI)-Schnittstellen und Joint Test Access Group (JTAG)-Testzugangsports. Bei manchen Implementierungen kann die Prozessorschaltungsanordnung 1752 einen oder mehrere Hardwarebeschleuniger (z.B. gleich oder ähnlich der Beschleunigungsschaltungsanordnung 1664) beinhalten, die Mikroprozessoren, programmierbare Verarbeitungsvorrichtungen (z.B. FPGA, ASIC usw.) oder dergleichen sein können. Der eine oder die mehreren Beschleuniger können zum Beispiel Computervision- und/oder Deep-Learning-Beschleuniger beinhalten. Bei manchen Implementierungen kann die Prozessorschaltungsanordnung 1752 eine On-Chip-Speicherschaltungsanordnung beinhalten, die einen beliebigen geeigneten flüchtigen und/oder nichtflüchtigen Speicher, wie etwa DRAM, SRAM, EPROM, EEPROM, Flash-Speicher, Halbleiterspeicher und/oder einen beliebigen anderen Typ von Speichervorrichtungstechnologie, wie etwa jene hierin erörterten, beinhalten kann.
  • Die Prozessorschaltungsanordnung 1752 kann zum Beispiel einen oder mehrere Prozessorkerne (CPUs), Anwendungsprozessoren, GPUs, RISC-Prozessoren, Acorn-RISC-Machine (ARM)-Prozessoren, CISC-Prozessoren, einen oder mehrere DSPs, ein oder mehrere FPGAs, eine oder mehrere PLDs, eine oder mehrere ASICs, einen oder mehrere Basisbandprozessoren, eine oder mehrere integrierte Funkfrequenzschaltungen (RFIC), einen oder mehrere Mikroprozessoren oder Mikrocontroller, einen Mehrkernprozessor, einen Multithread-Prozessor, einen Ultra-Low-Voltage-Prozessor, einen eingebetteten Prozessor oder beliebige andere bekannte Verarbeitungselemente oder jede geeignete Kombination davon beinhalten. Die Prozessoren (oder Kerne) 1752 können mit Speicher gekoppelt sein oder diese beinhalten und können dazu ausgelegt sein, Anweisungen auszuführen, die in dem Speicher gespeichert sind, um zu ermöglichen, dass verschiedene Anwendungen oder Betriebssysteme auf dem Knoten 1750 laufen. Der Prozessor (oder die Kerne) 1752 ist dazu ausgelegt, Anwendungssoftware zu betreiben, um einem Benutzer des Knotens 1750 einen spezifischen Dienst bereitzustellen. Bei manchen Ausführungsformen können der eine oder die mehreren Prozessoren 1752 Spezialprozessor(en)/-steuerung(en) sein, der (die) dazu ausgelegt (oder konfigurierbar) ist (sind), gemäß den verschiedenen Ausführungsformen hierin zu arbeiten.
  • Als Beispiele können der eine oder die mehreren Prozessoren 1752 einen Core™-basierten Intel® -Architekturprozessor, wie etwa einen i3-, einen i5-, einen i7-, einen i9-basierten Prozessor; einen Mikrocontroller-basierten Intel®-Prozessor, wie etwa einen Quark™, einen Atom™ oder einen anderen MCU-basierten Prozessor; einen oder mehrere Pentium®-Prozessoren, Xeon®-Prozessoren oder einen anderen solchen Prozessor, der von der Intel® Corporation, Santa Clara, Kalifornien, erhältlich ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa eine oder mehrere Advanced Micro Devices-Zen®-Architekturen (AMD-Zen®-Architekturen), wie etwa Ryzen®- oder EPYC®-Prozessor(en), Accelerated Processing Units (APUs), MxGPUs, Epyc®-Prozessor(en) oder dergleichen; A5-A12- und/oder S1-S4-Prozessor(en) von Apple® Inc., Snapdragon™- oder Centriq™-Prozessor(en) von QualCommon® Technologies, Inc., Texas Instruments, Inc.® Open Multimedia Applications Platform (OMAP)™-Prozessor(en); ein MIPS-basiertes Design von MIPS Technologies, Inc. wie MIPS Warrior-M-class-, Warrior I-class- und Warrior P-class-Prozessoren; ein ARM-basiertes Design, lizenziert von ARM Holdings, Ltd., wie die ARM Cortex-A-, Cortex-R- und Cortex-M-Prozessorfamilie; der von Cavium™, Inc. bereitgestellte ThunderX2®; oder dergleichen. Bei manchen Implementierungen können der eine oder die mehreren Prozessoren 1752 ein Teil eines System-on-Chip (SoC), System-in-Package (SiP), eines Multi-Chip-Package (MCP) und/oder dergleichen sein, in dem der eine oder die mehreren Prozessoren 1752 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Package gebildet sind, wie etwa den Edison™- oder Galileo™-SoC-Platinen von Intel® Corporation. Andere Beispiele für den einen oder die mehreren Prozessoren 1752 sind an anderer Stelle der vorliegenden Offenbarung erwähnt.
  • Der eine oder die mehreren Prozessoren 1752 können über eine Zwischenverbindung (IX) 1656 mit dem Systemspeicher 1756 kommunizieren. Eine beliebige Anzahl von Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR-oder Mobil-DDDR-Standards (z.B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Arbeitsspeicherkomponente einen von JEDEC veröffentlichten DRAM-Standard erfüllen, wie JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Niedrigenergie-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Andere RAM-Typen, wie etwa dynamischer RAM (DRAM), synchroner DRAM (SDRAM) und/oder dergleichen, können ebenfalls enthalten sein. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden, und Kommunikationsschnittstellen der Speichervorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Implementierungen können die einzelnen Speichereinrichtungen aus einer beliebigen Anzahl von verschiedenen Gehäusetypen sein, wie ein Ein-Rohchip-Gehäuse (SDP), Doppel-Rohchip-Gehäuse (DDP) oder Quad-Rohchip-Gehäuse (Q17P). Diese Vorrichtungen können bei manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die der Reihe nach durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z.B. Dual-Inline-Speichermodule (DIMMs) verschiedener Varianten, einschließlich unter anderem microDIMMs oder MiniDIMMs.
  • Um eine persistente Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann ein Speicher 1758 auch über die IX 1756 mit dem Prozessor 1752 gekoppelt sein. Bei einem Beispiel kann der Datenspeicher 1758 über ein Halbleiterplattenlaufwerk (SSDD) und/oder einen elektrisch löschbaren Hochgeschwindigkeitsspeicher (allgemein als „Flash-Speicher“ bezeichnet) implementiert sein. Andere Vorrichtungen, die für den Speicher 1758 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa SD-Karten, microSD-Karten, XD-Bildkarten und dergleichen, und USB-Flash-Laufwerke. In einem Beispiel kann die Speichervorrichtung eine Speichervorrichtung sein oder umfassen, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Phasenwechselspeicher (PCM - Phase Change Memory) mit einer oder mehreren Ebenen, einen resistiven Speicher, einen Nanodrahtspeicher, einen ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM - Ferroelectric Transistor Random Access Memory), einen antiferroelektrischen Speicher, einen magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristor-Technologie umfasst, einen Phasenwechsel-RAM (PRAM - Phase Change RAM), einen resistiven Speicher auf Metalloxidbasis, Sauerstoffleerstellenbasis und Conductive-Brige-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque-(STT-)MRAM, eine Vorrichtung auf der Basis eines Spintronik-Speichers mit magnetischem Übergang, eine Vorrichtung auf der Basis eines magnetischen Tunnelübergangs (MTJ - Magnetic Tunneling Junction), eine Vorrichtung auf Domänenwand- und SOT-(Spin Orbit Transfer-)Basis, eine Speichervorrichtung Thyristorbasis oder eine Kombination beliebiger der obigen oder anderen Speicher einsetzt. Die Speicherschaltungsanordnung 1754 und/oder die Speicherschaltungsanordnung 1758 können auch dreidimensionale (3D) Crosspoint (XPOINT)-Speicher von Intel® und Micron® beinhalten.
  • Bei Niedrigleistungsimplementierungen kann der Speicher 1758 ein On-Die-Speicher oder -Register sein, die mit dem Prozessor 1752 assoziiert sind. In einigen Beispielen kann die Speicherung 1658 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für den Speicher 1758 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie unter anderem Widerstandsänderungsspeicher, Phasenwechselspeicher, holographische Speicher oder chemische Speicher.
  • Die Speicherschaltungsanordnung 1758 speichert Rechenlogik 1782 (oder „Module 1782“) in der Form von Software-, Firmware- oder Hardwarebefehlen, um die hierin beschriebenen Techniken zu implementieren. Die Rechenlogik 1782 kann eingesetzt werden, um Arbeitskopien und/oder permanente Kopien von Computerprogrammen oder Daten zum Erstellen der Computerprogramme für den Betrieb verschiedener Komponenten des Knotens 1750 (z.B. Treiber usw.), eines OS des Knotens 1750 und/oder einer oder mehrerer Anwendungen zum Ausführen der hierin erörterten Ausführungsformen zu speichern. Die Rechenlogik 1782 kann als Anweisungen 1782 oder Daten zum Erzeugen der Anweisungen 1788 zur Ausführung durch die Prozessorschaltungsanordnung 1752 zum Bereitstellen der hierin beschriebenen Funktionen gespeichert oder in die Arbeitsspeicherschaltungsanordnung 1754 geladen werden. Die verschiedenen Elemente können durch Assembleranweisungen, die durch die Prozessorschaltungsanordnung 1752 unterstützt werden, oder Hochsprachen implementiert werden, die in solche Anweisungen (z. B. Anweisungen 1788 oder Daten zum Erzeugen der Anweisungen 1788) kompiliert werden können. Die permanente Kopie der Programmieranweisungen kann zum Beispiel durch ein Verteilungsmedium (nicht gezeigt), durch eine Kommunikationsschnittstelle (z. B. von einem Verteilungsserver (nicht gezeigt)) oder über die Luft (OTA) in persistente Speichervorrichtungen der Speicherschaltungsanordnung 1758 in der Fabrik oder im Feld platziert werden.
  • Bei einem Beispiel sind die Anweisungen 1788, die über die Speicherschaltungsanordnung 1754 und/oder die Speicherschaltungsanordnung 1758 von 17 bereitgestellt werden, als ein oder mehrere nichtflüchtige computerlesbare Speichermedien (siehe z.B. NTCRSM 1760) umgesetzt, die Programmcode, ein Computerprogrammprodukt oder Daten zum Erzeugen des Computerprogramms beinhalten, wobei das Computerprogramm oder die Daten die Prozessorschaltungsanordnung 1758 des Knotens 1750 anweisen, elektronische Operationen im Knoten 1750 durchzuführen und/oder eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das eine oder die mehreren zuvor dargestellten Flussdiagramme und Blockdiagramme von Operationen und Funktionalität zuvor beschrieben. Die Prozessorschaltungsanordnung 1752 greift über die Zwischenverbindung 1756 auf das eine oder die mehreren nichtflüchtigen computerlesbaren Speichermedien zu.
  • Bei alternativen Ausführungsformen können Programmieranweisungen (oder Daten zum Erzeugen der Anweisungen) auf mehreren NTCRSM 1760 angeordnet sein. In alternativen Ausführungsformen können Programmieranweisungen (oder Daten zum Erstellen der Anweisungen) auf computerlesbaren transitorischen Speichermedien, wie etwa Signalen, angeordnet sein. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstelleneinrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z.B. HTTP) nutzt. Es kann eine beliebige Kombination eines oder mehrerer computernutzbarer oder computerlesbarer Medien genutzt werden. Das computernutzbare oder computerlesbare Medium kann zum Beispiel unter anderem ein oder mehrere elektronische, magnetische, optische, elektromagnetische, Infrarot- oder Halbleitersysteme, Vorrichtungen, Geräte oder Ausbreitungsmedien sein. Beispielsweise kann das NTCRSM 1760 durch Vorrichtungen umgesetzt sein, die für die Speicherschaltungsanordnung 1758 und/oder die Speicherschaltungsanordnung 1754 beschrieben sind. Spezifischere Beispiele (eine nicht abschließende Liste) eines computerlesbaren Mediums würden Folgendes umfassen: eine elektrische Verbindung mit einem oder mehreren Drähten, eine tragbare Computerdiskette, eine Festplatte, einen Direktzugriffsspeicher (RAM), einen Nur-Lese-Speicher (ROM), einen löschbaren programmierbaren Nur-Lese-Speicher (EPROM, Flash-Speicher usw.), eine optische Faser, einen tragbaren CD-ROM (Compact Disc Read-Only Memory), eine optische Speichervorrichtung und/oder optische Platten, Übertragungsmedien, wie etwa jene, die das Internet oder ein Intranet unterstützen, eine magnetische Speichervorrichtung oder eine beliebige Anzahl anderer Hardwarevorrichtungen. Es ist anzumerken, dass das computernutzbare oder computerlesbare Medium selbst Papier oder ein anderes geeignetes Medium sein könnte, auf dem das Programm (oder Daten zum Erzeugen des Programms) ausgedruckt ist, da das Programm (oder Daten zum Erzeugen des Programms) beispielsweise über ein optisches Scannen des Papiers oder anderen Mediums elektronisch erfasst, dann kompiliert, interpretiert oder anderweitig auf eine geeignete Art und Weise verarbeitet werden kann, falls notwendig, und dann in einem Computerspeicher (mit oder ohne in einem oder mehreren Zwischenspeichermedien gestapelt worden zu sein) gespeichert werden kann. Im Kontext dieses Dokuments kann ein computernutzbares oder computerlesbares Medium ein beliebiges Medium sein, das das Programm (oder Daten zum Erstellen des Programms) zur Verwendung durch oder in Verbindung mit dem Anweisungsausführungssystem, der Anweisungsausführungseinrichtung oder der Anweisungsausführungsvorrichtung enthalten, speichern, kommunizieren, propagieren oder transportieren kann. Das computernutzbare Medium kann ein propagiertes Datensignal mit dem damit verkörperten computernutzbaren Programmcode (oder Daten zum Erzeugen des Programmcodes) entweder im Basisband oder als Teil einer Trägerwelle beinhalten. Der computernutzbare Programmcode (oder Daten zum Erzeugen des Programms) kann unter Verwendung eines beliebigen geeigneten Mediums übertragen werden, einschließlich unter anderem drahtlos, drahtgebunden, optisches Faserkabel, RF usw.
  • Bei diversen Ausführungsformen kann der hierin beschriebene Programmcode (oder können Daten zum Erzeugen des Programmcodes) in einem oder mehreren eines komprimierten Formats, eines verschlüsselten Formats, eines fragmentierten Formats, eines verpackten Formats usw. gespeichert sein. Programmcode (oder Daten zum Erzeugen des Programmcodes), wie hierin beschrieben, kann Installation und/oder Modifikation und/oder Anpassung und/oder Aktualisierung und/oder Kombination und/oder Ergänzung und/oder Konfiguration und/oder Entschlüsselung und/oder Dekomprimierung und/oder Entpacken und/oder Verteilung und/oder Neuzuweisung usw. erfordern, um sie durch eine Rechenvorrichtung und/oder eine andere Maschine direkt lesbar und/oder ausführbar zu machen. Zum Beispiel kann der Programmcode (oder Daten zum Erzeugen des Programmcodes) in mehreren Teilen gespeichert sein, die einzeln komprimiert, verschlüsselt und auf separaten Rechenvorrichtungen gespeichert sind, wobei die Teile, wenn sie entschlüsselt, dekomprimiert und kombiniert werden, einen Satz ausführbarer Anweisungen bilden, die den Programmcode (die Daten zum Erzeugen des Programmcodes) wie hierin beschrieben implementieren. In einem anderen Beispiel kann der Programmcode (oder Daten zum Erzeugen des Programmcodes) in einem Zustand gespeichert werden, in dem sie durch einen Computer gelesen werden können, aber das Hinzufügen einer Bibliothek (z.B. einer Dynamic Link Library), eines SDK (Software Development Kit), einer Anwendungsprogrammierschnittstelle (API) usw. erfordern, um die Anweisungen auf einer speziellen Rechenvorrichtung oder einer anderen Vorrichtung auszuführen. In einem anderen Beispiel muss der Programmcode (oder Daten zum Erzeugen des Programmcodes) möglicherweise konfiguriert werden (z.B. Einstellungen gespeichert, Daten eingegeben, Netzwerkadressen aufgezeichnet werden usw.), bevor der Programmcode (oder Daten zum Erzeugen des Programmcodes) vollständig oder teilweise ausgeführt/verwendet werden kann. In diesem Beispiel kann der Programmcode (oder können Daten zum Erzeugen des Programmcodes) entpackt, zur ordnungsgemäßen Ausführung konfiguriert und an einem ersten Ort gespeichert werden, wobei sich die Konfigurationsanweisungen an einem zweiten Ort befinden, der sich von dem ersten Ort unterscheidet. Die Konfigurationsanweisungen können durch eine Aktion, einen Auslöser oder eine Anweisung initiiert werden, die/der sich nicht zusammen mit den Anweisungen, welche die offenbarten Techniken ermöglichen, am Speicher- oder Ausführungsort befindet. Dementsprechend soll der offenbarte Programmcode (oder Daten zum Erzeugen des Programmcodes) derartige maschinenlesbare Anweisungen und/oder Programm(e) (oder Daten zum Erzeugen solcher maschinenlesbarer Anweisungen und/oder Programme), ungeachtet des speziellen Formats oder Zustands der maschinenlesbaren Anweisungen und/oder Programm(e), einschließen, wenn sie gespeichert oder anderweitig im Ruhezustand oder im Transit sind.
  • Computerprogrammcode zum Ausführen von Operationen der vorliegenden Offenbarung (z. B. Rechenlogik 1782, Anweisungen 1782, Anweisungen 1788, die zuvor erörtert wurden) kann in einer beliebigen Kombination von einer oder mehreren Programmiersprachen geschrieben werden, einschließlich einer objektorientierten Programmiersprache, wie etwa Python, Ruby, Scala, Smalltalk, Java™, C++, C# oder dergleichen; einer prozeduralen Programmiersprache, wie etwa der Programmiersprache „C“, der Programmiersprache Go (oder „Golang“) oder dergleichen; eine Skriptsprache, wie etwa JavaScript, Server-Side JavaScript (SSJS), JQuery, PHP, Pearl, Python, Rubin on Rails, Accelerated Mobile Pages Script (AMPcript), Lost Template Language, Handlebar Template Language, Guide Template Language (GTL), PHP, Java und/oder Java Server Pages (JSP), Node.js, ASP.NET, JAMskript und/oder dergleichen; einer Auszeichnungssprache, wie etwa Hypertext Markup Language (HTML), Extensible Markup Language (XML), Java Script Object Notion (JSON), Apex®, Kaskadieren von Stylesheet (CSS), JavaServer Seiten (JSP), MessagePack™, Apache® Thrift, Abstract Syntax Notation One (ASN. 1), Google® Protocol Buffers (Protobuf) oder dergleichen; einiger anderer geeigneter Programmiersprachen, einschließlich proprietärer Programmiersprachen und/oder Entwicklungswerkzeuge, oder beliebiger anderer Sprachwerkzeuge. Der Computerprogrammcode zum Ausführen von Operationen der vorliegenden Erfindung kann auch in einer beliebigen Kombination der hierin erörterten Programmiersprachen geschrieben sein. Der Programmcode kann vollständig auf dem System 1750, teilweise auf dem System 1750, als ein eigenständiges Softwarepaket, teilweise auf dem System 1750 und teilweise auf einem Remote-Computer oder vollständig auf dem Remote-Computer oder Server ausgeführt werden. In dem letzterem Szenario kann der Remote-Computer mit dem System 1750 durch eine beliebige Art von Netzwerk verbunden sein, einschließlich eines LAN oder WAN, oder die Verbindung kann mit einem externen Computer (z. B. durch das Internet unter Verwendung eines Internetdienstanbieters) hergestellt werden.
  • In einem Beispiel können die Anweisungen 1788 auf der Prozessorschaltungsanordnung 1752 (separat oder in Kombination mit den Anweisungen 1782 und/oder Logik/Modulen 1782, die in computerlesbaren Speicherungsmedien gespeichert sind) die Ausführung oder Operation einer vertrauenswürdigen Ausführungsumgebung (TEE) 1790 konfigurieren. Die TEE 1790 arbeitet als ein geschützter Bereich, auf den die Prozessorschaltungsanordnung 1752 zugreifen kann, um einen sicheren Zugriff auf Daten und eine sichere Ausführung von Anweisungen zu ermöglichen. In einigen Ausführungsformen kann die TEE 1790 eine physische Hardwarevorrichtung sein, die von anderen Komponenten des Systems 1750 getrennt ist, wie etwa eine sicher eingebettete Steuerung, ein dediziertes SoC oder ein manipulationssicherer Chipsatz oder Mikrocontroller mit eingebetteten Verarbeitungsvorrichtungen und Speichervorrichtungen. Zu Beispielen für solche Ausführungsformen zählen eine Desktop- und mobile Architektur-Hardware (DASH)-konforme Netzwerkschnittstellenkarte (NIC, Network Interface Card), Intel® Management/Manageability Engine, Intel® Converged Security Engine (CSE) oder Converged Security Management/Manageability Engine (CSME), Trusted Execution Engine (TXE), bereitgestellt von Intel®, die jeweils zusammen mit der Intel® Active Management Technology (AMT) und/oder der Intel® vPro™ Technology betrieben werden können; AMD® Platform Security coProcessor (PSP), AMD® PRO A-Series Accelerated Processing Unit (APU) with DASH-Manageability, Apple® Secure Enclave-Coprozessor; IBM® Crypto Express3®, IBM® 4807, 4808, 4809 und/oder 4765 Cryptographic Coprocessors, IBM® Baseboard Management Controller (BMC) mit Intelligent Platform Management Interface (IPMI), Dell™ Remote Assistant Card II (DRAC II), integrated Dell™ Remote Assistant Card (iDRAC) und dergleichen.
  • In anderen Ausführungsformen kann die TEE 1790 als sichere Enklaven implementiert sein, die isolierte Code- und/oder Datenregionen innerhalb des Prozessors und/oder der Speicher-/Speicherungsschaltungsanordnung des Systems 1750 sind. Nur Code, der innerhalb einer sicheren Enklave ausgeführt wird, kann auf Daten innerhalb derselben sicheren Enklave zugreifen, und die sichere Enklave kann nur unter Verwendung der sicheren Anwendung zugänglich sein (die durch einen Anwendungsprozessor oder einen manipulationssicheren Mikrocontroller implementiert werden kann). Verschiedene Implementierungen der TEE 1750 und eines begleitenden sicheren Bereichs in der Prozessorschaltungsanordnung 1752 oder der Speicherschaltungsanordnung 1754 und/oder der Speicherschaltungsanordnung 1758 können beispielsweise durch Verwendung von Intel® Software Guard Extensions (SGX), ARM®-TrustZone®-Hardwaresicherheitserweiterungen, Keystone Enclaves, die durch Oasis Labs™ bereitgestellt werden, und/oder dergleichen bereitgestellt werden. Andere Aspekte von Sicherheitshärtung, Hardware-Vertrauenswurzeln und vertrauenswürdigen oder geschützten Operationen können in der Vorrichtung 1750 durch die TEE 1790 und die Prozessorschaltungsanordnung 1752 implementiert werden.
  • In einigen Ausführungsformen können die Arbeitsspeicherschaltungsanordnung 1754 und/oder die Datenspeicherschaltungsanordnung 1758 in isolierte Benutzerrauminstanzen unterteilt sein, wie etwa Container, Partitionen, virtuelle Umgebungen (VEs) usw. Die isolierten Benutzerrauminstanzen können unter Verwendung einer geeigneten Virtualisierungstechnologie auf OS-Ebene, wie etwa Docker®-Container, Kubernetes®-Container, Solaris®-Container und/oder -Zonen, virtuellen privaten OpenVZ®-Servern, virtuellen DragonFly BSD®-Kerneln und/oder -Käfigen, chroot-Käfigen und/oder dergleichen, implementiert werden. In einigen Implementierungen könnten auch virtuelle Maschinen verwendet werden. In einigen Ausführungsformen können die Speicherungsschaltungsanordnung 1754 und/oder die Speicherungsschaltungsanordnung 1758 in eine oder mehrere vertrauenswürdige Speicherregionen zum Speichern von Anwendungen oder Softwaremodulen der TEE 1790 unterteilt sein.
  • Obwohl die Anweisungen 1782 als Codeblöcke gezeigt sind, die in der Speicherschaltungsanordnung 1754 enthalten sind, und die Rechenlogik 1782 als Codeblöcke in der Speicherungsschaltungsanordnung 1758 gezeigt ist, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in ein FPGA, eine ASIC oder eine andere geeignete Schaltungsanordnung eingebaut sind. Wenn die Prozessorschaltungsanordnung 1752 zum Beispiel Hardware-Beschleuniger (z.B. FPGA-basierte) sowie Prozessorkerne einschließt, können die Hardware-Beschleuniger (z.B. die FPGA-Zellen) mit der oben erwähnten Rechenlogik, um einige oder alle der zuvor erörterten Funktionen durchzuführen (anstelle des Einsatzes von Programmieranweisungen, die von dem oder den Prozessorkernen auszuführen sind) vorkonfiguriert sein (z.B. mit entsprechenden Bitströmen).
  • Die Speicherschaltungsanordnung 1754 und/oder die Speicherschaltungsanordnung 1758 können Programmcode eines Betriebssystems (OS) speichern, das ein Allzweck-OS oder ein OS sein kann, das speziell für den Computerknoten 1750 geschrieben und darauf zugeschnitten ist. Das OS kann zum Beispiel Unix oder ein Unix-ähnliches OS sein, wie z.B. etwa Linux, bereitgestellt von Red Hat Enterprise, Windows 10™, bereitgestellt von Microsoft Corp.®, macOS, bereitgestellt von Apple Inc.®, oder dergleichen. Bei einem anderen Beispiel kann das OS ein mobiles OS sein, wie etwa Android, bereitgestellt von Google Inc.®, iOS®, bereitgestellt von Apple Inc.®, Windows 10 Mobile®, bereitgestellt von Microsoft Corp.®, KaiOS, bereitgestellt von KaiOS Technologies Inc., oder dergleichen. Bei einem anderen Beispiel kann das OS ein Echtzeit-OS (RTOS) sein, wie etwa Apache Mynewt, das von der Apache Software Foundation® bereitgestellt wird, Windows 10 For loT®, das von Microsoft Corp.® bereitgestellt wird, Micro-Controller Operating Systems („MicroC/OS“ oder „pC/OS“), das von Micrium® bereitgestellt wird, Inc., FreeRTOS, VxWorks®, bereitgestellt von Wind River Systems, Inc.®, PikeOS, bereitgestellt von Sysgo AG®, Android Things®, bereitgestellt von Google Inc.®, QNX® RTOS, bereitgestellt von BlackBerry Ltd., oder ein beliebiges anderes geeignetes RTOS, wie etwa die hierin erörterten.
  • Das OS kann einen oder mehrere Treiber beinhalten, die dazu dienen, spezielle Vorrichtungen zu steuern, die in dem Knoten 1750 eingebettet, an dem Knoten 1750 angebracht oder anderweitig kommunikativ mit dem Knoten 1750 gekoppelt sind. Die Treiber können einzelne Treiber beinhalten, die anderen Komponenten des Knotens 1750 ermöglichen, mit verschiedenen E/A-Vorrichtungen, die innerhalb des Knotens 1750 vorhanden oder mit diesem verbunden sein können, zu interagieren oder sie zu steuern. Zum Beispiel können die Treiber einen Anzeigentreiber zum Steuern und Ermöglichen von Zugang zu einer Anzeigevorrichtung, einen Touchscreen-Treiber zum Steuern und Ermöglichen von Zugang zu einer Touchscreen-Schnittstelle des Knotens 1750, Sensortreiber zum Erhalten von Sensormesswerten der Sensorschaltungsanordnung 1772 und zum Steuern und Ermöglichen von Zugang zu der Sensorschaltungsanordnung 1772, Aktuatortreiber zum Erhalten von Aktuatorstellungen der Aktuatoren 1774 und/oder Steuern und Ermöglichen von Zugang zu den Aktuatoren 1774, einen Kameratreiber zum Steuerung und Ermöglichen von Zugang zu einer eingebetteten Bilderfassungsvorrichtung, Audiotreiber zum Steuern und Ermöglichen von Zugang zu einer oder mehreren Audiovorrichtungen beinhalten. Die OSs können auch eine oder mehrere Bibliotheken, Treiber, APIs, Firmware, Middleware, Softwarekleber usw. umfassen, die Programmcode und/oder Softwarekomponenten für eine oder mehrere Anwendungen bereitstellen, um die Daten von einer sicheren Ausführungsumgebung, vertrauenswürdigen Ausführungsumgebung und/oder Verwaltungs-Engine des Knotens 1750 (nicht gezeigt) zu erhalten und zu verwenden.
  • Die Komponenten der Edge-Computing-Vorrichtung 1750 können über die IX 1756 kommunizieren. Die IX 1756 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich ISA, erweiterte ISA, I2C, SPI, Punkt-zu-Punkt-Schnittstellen, Power Management Bus (PMBus), PCI, PCIe, PCIx, Intel® UPI, Intel® Accelerator Link, Intel® CXL, CAPI, OpenCAPI, Intel® QPI, UPI, Intel® OPA IX, RapidIO™ System IXs, CCIX, Gen-Z Consortium IXs, einer HyperTransport-Zwischenverbindung, NVLink, bereitgestellt durch NVIDIA®, einem Time-Trigger Protocol (TTP)-System, einem FlexRay-System und/oder einer beliebigen Anzahl anderer IX-Technologien. Die IX 1756 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird.
  • Die IX 1756 koppelt den Prozessor 1752 mit der Kommunikationsschaltungsanordnung 1766 zur Kommunikation mit anderen Vorrichtungen, wie etwa einem Remote-Server (nicht gezeigt) und/oder den verbundenen Edge-Vorrichtungen 1762. Die Kommunikationsschaltungsanordnung 1766 ist ein Hardwareelement oder eine Sammlung von Hardwareelementen, das/die zum Kommunizieren über ein oder mehrere Netzwerke (z.B. die Cloud 1763) und/oder mit anderen Vorrichtungen (z.B. den Edge-Vorrichtungen 1762) verwendet wird/werden.
  • Der Sendeempfänger 1766 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa unter anderem Übertragungen auf 2,4 Gigahertz (GHz) gemäß dem IEEE 802.15.4-Standard unter Verwendung des Bluetooth® Low Energy (BLE)-Standards, wie durch die Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Eine beliebige Anzahl von Funkgeräten, die für ein spezielles Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 1762 verwendet werden. Zum Beispiel kann eine Wireless Local Area Network (WLAN)-Einheit verwendet werden, um WiFi®-Kommunikationen gemäß dem Institute of Electrical and Electronics Engineers (IEEE) 802.11-Standard zu implementieren. Außerdem können Funkfernnetzkommunikationen, z.B. in Übereinstimmung mit einem Mobilfunk- oder anderen Funkfernnetzprotokoll über eine Funkfernnetz- (WWAN-) Einheit stattfinden.
  • Der Drahtlosnetzwerk-Sendeempfänger 1766 (oder mehrere Sendeempfänger) kann (können) unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen mit unterschiedlicher Reichweite kommunizieren. Zum Beispiel kann der Edge-Computing-Knoten 1750 mit nahen Vorrichtungen, z.B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf BLE oder einem anderen Niedrigleistungsfunk kommunizieren, um Leistung einzusparen. Weiter entfernte verbundene Edge-Vorrichtungen 1762, z.B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Mittelleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln erfolgen oder können über separate Sendeempfänger erfolgen, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten vermaschten Sendeempfänger, der ZigBee® verwendet.
  • Ein Drahtlosnetzwerk-Sendeempfänger 1766 (z.B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 1763 über Orts- oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 1766 kann ein LPWA-Sendeempfänger sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g entspricht. Der Edge-Rechenknoten 1763 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network), entwickelt von Semtech und der LoRa Alliance, kommunizieren. Die vorliegend beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite, niedriger Bandbreite implementieren, wie etwa Sigfox, und anderen Technologien. Ferner können andere Kommunikationstechniken, wie Kanalsprung mit Zeitschlitzen, beschrieben in der Spezifikation IEEE 802.15.4e, verwendet werden.
  • Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den für den Drahtlosnetzwerk-Sendeempfänger 1766 erwähnten Systemen verwendet werden, wie hier beschrieben. Der Sendeempfänger 1766 kann zum Beispiel einen zellularen Sendeempfänger beinhalten, der Spreizspektrum (SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa WiFi®-Netzwerke für Mittelgeschwindigkeitskommunikationen und Bereitstellung von Netzwerkkommunikationen. Der Sendeempfänger 1766 kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen kompatibel sind, wie etwa LTE und SG/NR-Kommunikationssysteme, die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden. Eine Netzwerkschnittstellensteuerung (NIC) 1768 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 1763 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 1762 (die z.B. vernetzt arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway Plus (DH+), PROFIBUS oder PROFINET und vielen anderen. Eine zusätzliche NIC 1768 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 1768 Kommunikationen mit dem Cloud-over-Ethernet bereitstellt und eine zweite NIC 1768 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
  • Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die durch die Vorrichtung verwendet wird, eine beliebige oder mehrere der Komponenten 1764, 1766, 171668 oder 1770 beinhalten oder durch diese umgesetzt sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z.B. Empfangen, Übertragen usw.) durch eine derartige Kommunikationsschaltungsanordnung ausgebildet sein.
  • Der Edge-Computing-Knoten 1750 kann eine Beschleunigungsschaltungsanordnung 1764 umfassen oder mit dieser gekoppelt sein, die durch einen oder mehrere KI-Beschleuniger, einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, einen oder mehrere SoCs (einschließlich programmierbarer SoCs), eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs (einschließlich programmierbarer ASICs), PLDs, wie etwa CPLDs oder HCPLDs, und/oder andere Formen spezialisierter Prozessoren oder Schaltungen umgesetzt ist, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben konzipiert sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objekterkennung, Regelanalyse oder dergleichen umfassen. Bei FPGA-basierten Implementierungen kann die Beschleunigungsschaltungsanordnung 1764 Logikblöcke oder Logikstruktur und andere miteinander verbundene Ressourcen umfassen, die programmiert (konfiguriert) werden können, um verschiedene Funktionen durchzuführen, wie etwa die Prozeduren, Verfahren, Funktionen usw. der verschiedenen hier erörterten Ausführungsformen. Bei solchen Implementierungen kann die Beschleunigungsschaltungsanordnung 1764 auch Speicherzellen (z. B. EPROM, EEPROM, Flash-Speicher, statischer Speicher (z. B. SRAM, Anti-Fuses usw.) beinhalten, die zum Speichern von Logikblöcken, Logikstruktur, Daten usw. in LUTs und dergleichen verwendet werden.
  • Die IX 1756 koppelt auch den Prozessor 1752 mit einem Sensorhub oder einer externen Schnittstelle 1770, die zum Anschließen zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die zusätzlichen/externen Vorrichtungen können die Sensoren 1772, die Aktuatoren 1774 und die Positionsbestimmungsschaltungsanordnung 1745 beinhalten.
  • Die Sensorschaltungsanordnung 1772 beinhaltet Vorrichtungen, Module oder Subsysteme, deren Zweck darin besteht, Ereignisse oder Änderungen in ihrer Umgebung zu detektieren und die Informationen (Sensordaten) über die detektierten Ereignisse an irgendeine andere Vorrichtung, ein Modul, ein Subsystem usw. zu senden. Beispiele für solche Sensoren 1772 beinhalten unter anderem Trägheitsmesseinheiten (IMU), die Beschleunigungsmesser, Gyroskope und/oder Magnetometer umfassen; mikroelektromechanische Systeme (MEMS) oder nanoelektromechanische Systeme (NEMS), die 3-Achsen-Beschleunigungsmesser, 3-Achsen-Gyroskope und/oder Magnetometer umfassen; Füllstandssensoren; Strömungssensoren; Temperatursensoren (z.B. Thermistoren); Drucksensoren; Atmosphärendrucksensoren; Gravimeter; Höhenmesser; Bilderfassungsvorrichtungen (z.B. Kameras); Light Detection And Ranging (LiDAR)-Sensoren; Näherungssensoren (z.B. Infrarotstrahlungsdetektor und dergleichen); Tiefensensoren, Umgebungslichtsensoren; optische Lichtsensoren; Ultraschallsendeempfänger; Mikrofone; und dergleichen.
  • Zusätzlich oder alternativ dazu können manche der Sensoren 172 Sensoren sein, die für verschiedene Fahrzeugsteuersysteme verwendet werden, und können unter anderem beinhalten: Abgassensoren einschließlich Abgassauerstoffsensoren, um Sauerstoffdaten zu erhalten, und Krümmerabsolutdruck (MAP)-Sensoren, um Krümmerdruckdaten zu erhalten, Luftmassen (MAF)-Sensoren, um Ansaugluftstromdaten zu erhalten; Ansaugtemperatur (IAT)-Sensoren, um IAT-Daten zu erhalten; Umgebungslufttemperatur (AAT)-Sensoren, um AAT-Daten zu erhalten; Umgebungsluftdruck (AAP)-Sensoren, um AAP-Daten (z.B. Reifendruckdaten) zu erhalten; Katalysatorsensoren einschließlich Katalysatortemperatur (CCT), um CCT-Daten zu erhalten, und Katalysatorsauerstoff (CCO)-Sensoren, um CCO-Daten zu erhalten; Fahrzeuggeschwindigkeitssensoren (VSS), um VSS-Daten zu erhalten; Abgasrückführungs-(EGR)-Sensoren einschließlich EGR-Drucksensoren, um ERG-Druckdaten zu erhalten, und EGR-Stellungssensoren, um Stellungs-/Ausrichtungsdaten eines EGR-Ventilzapfens zu erhalten; Drosselklappenstellungssensor (TPS), um Drosselklappenstellungs-/Ausrichtungs-/Winkeldaten zu erhalten; einen Kurbelwellen-/Nockenstellungssensor, um Kurbelwellen-/Nocken-/Kolbenstellungs-/Ausrichtungs-/Winkeldaten zu erhalten; Kühlmitteltemperatursensoren; Antriebsstrangsensoren, um Antriebsstrangsensordaten (z.B. Getriebefluidpegel) zu sammeln, Fahrzeugkarosseriesensoren, um Fahrzeugkarosseriedaten zu sammeln (z.B. Daten, die mit einem Einbeulen des Kühlergrills bzw. der vorderen Kotflügel, der Seitentüren, der hinteren Kotflügel, des hinteren Kofferraums und so weiter assoziiert sind); und so weiter. Die Sensoren 172 können andere Sensoren, wie etwa einen Gaspedalstellungssensor (APP), Beschleunigungsmesser, Magnetometer, Füllstandssensoren, Durchfluss-/Fluidsensoren, Atmosphärendrucksensoren und dergleichen, beinhalten. Sensordaten von den Sensoren 172 des Hostfahrzeugs können Motorsensordaten beinhalten, die durch verschiedene Motorsensoren gesammelt werden (z.B. Motortemperatur, Öldruck und so weiter).
  • Die Aktuatoren 1774 ermöglichen dem Knoten 1750, seinen Zustand, seine Stellung und/oder seine Ausrichtung zu ändern oder einen Mechanismus oder ein System zu bewegen oder zu steuern. Die Aktuatoren 1774 umfassen elektrische und/oder mechanische Vorrichtungen zum Bewegen oder Steuern eines Mechanismus oder Systems und konvertieren Energie (z.B. elektrischen Strom oder sich bewegende Luft und/oder Flüssigkeit) in irgendeine Art von Bewegung. Die Aktuatoren 1774 können eine oder mehrere elektronische (oder elektrochemische) Vorrichtungen umfassen, wie etwa piezoelektrische Biomorphe, Festkörperaktuatoren, Festkörperrelais (SSRs), Aktuatoren auf der Basis von Formgedächtnislegierungen, Aktuatoren auf der Basis von elektroaktiven Polymeren, integrierte Relaistreiberschaltungen (ICs) und/oder dergleichen. Die Aktuatoren 1774 können eine oder mehrere elektromechanische Vorrichtungen umfassen, wie etwa pneumatische Aktuatoren, hydraulische Aktuatoren, elektromechanische Schalter, einschließlich elektromechanischer Relais (EMRs), Motoren (z.B. DC-Motoren, Schrittmotoren, Servomechanismen usw.), Leistungsschalter, Ventilaktuatoren, Räder, Schubdüsen, Propeller, Klauen, Klemmen, Haken, Hörschallgenerator, optische Warnvorrichtungen und/oder andere ähnliche elektromechanische Komponenten. Der Knoten 1750 kann dazu ausgelegt sein, einen oder mehrere Aktuatoren 1774 basierend auf einem oder mehreren erfassten Ereignissen und/oder Anweisungen oder Steuersignalen zu betreiben, die von einem Dienstanbieter und/oder verschiedenen Clientsystemen empfangen werden.
  • In einigen Ausführungsformen können die Aktuatoren 1774 Antriebssteuereinheiten (z.B. DCUs 174 aus 1) sein. Zu Beispielen für DCUs 1774 zählen eine Antriebsstrangsteuereinheit, eine Motorsteuereinheit (ECU), ein Motorsteuermodul (ECM), EEMS, ein Antriebsstrangsteuermodul (PCM), ein Getriebesteuermodul (TCM), ein Bremssteuermodul (BCM) mit einem Antiblockiersystem (ABS)-Modul und/oder einem elektronischen Stabilitätssteuerungs (ESC)-System, ein zentrales Steuermodul (CCM), ein zentrales Timingmodul (CTM), ein allgemeines elektronisches Modul (GEM), ein Karosseriesteuermodul (BCM), ein Aufhängungssteuermodul (SCM), eine Türsteuereinheit (DCU), eine Geschwindigkeitssteuereinheit (SCU), eine Mensch-Maschine-Schnittstellen (HMI)-Einheit, eine Telematiksteuereinheit (TTU), ein Batteriemanagementsystem, ein transportierbares Emissionsmesssystem (PEMS), ein Ausweichmanöverassistenz (EMA)-Modul/System und/oder eine beliebige andere Entität oder Knoten in einem Fahrzeugsystem. Zu Beispielen für die CSD, die durch die DCUs 174 generiert werden können, können unter anderem zählen: in Echtzeit berechnete Motorlastwerte von einem Motorsteuermodul (ECM), wie etwa Motordrehzahlen pro Minute (RPM) eines Motors des Fahrzeugs; Kraftstoffeinspritzventilaktivierungs-Timing-Daten eines oder mehrerer Zylinder und/oder eines oder mehrerer Einspritzventile des Motors, Zündzeitpunktdaten des einen oder der mehreren Zylinder (z. B. eine Angabe von Zündereignissen relativ zum Kurbelwinkel des einen oder der mehreren Zylinder), Getriebeübersetzungsdaten und/oder Getriebezustandsdaten (die dem ECM durch eine Getriebesteuereinheit (TCU) zugeführt werden können); und/oder dergleichen.
  • In einigen Fahrzeugausführungsformen können die Aktuatoren/DCUs 1774 mit Steuersystemkonfigurationen (CSCs) versehen sein, die Sammlungen von Softwaremodulen, Softwarekomponenten, Logikblöcken, Parametern, Kalibrierungen, Varianten usw. sind, die zum Steuern und/oder Überwachen verschiedener durch den Knoten 1750 implementierter Systeme verwendet werden (z.B. wenn der Knoten 1750 ein CA/AD-Fahrzeug 110 ist). Die CSCs definieren, wie die DCUs 1774 Sensordaten der Sensoren 1772 und/oder CSD anderer DCUs 1774 unter Verwendung mehrdimensionaler Leistungsfähigkeitskennfelder oder Nachschlagetabellen interpretieren sollen, und definieren, wie Aktuatoren/Komponenten basierend auf den Sensordaten angepasst/modifiziert werden sollen. Die CSCs und/oder die Softwarekomponenten, die durch einzelne DCUs 1774 auszuführen sind, können unter Verwendung einer beliebigen geeigneten objektorientierten Programmiersprache (z.B. C, C++, Java usw.), Schemasprache (z.B. XML-Schema, AUTomotive Open System Architecture (AUTOSAR) XML-Schema usw.), Skriptsprache (VBScript, JavaScript usw.) oder dergleichen entwickelt werden. Die CSCs und Softwarekomponenten können unter Verwendung einer Hardware-Beschreibungssprache (HDL), wie etwa Register-Transferlogik (RTL), Very High Speed Integrated Circuit (VHSIC)-HDL (VHDL), Verilog usw., für DCUs 1774 definiert werden, die als feldprogrammierbare Vorrichtungen (FPDs, Field Programmable Device) implementiert sind. Die CSCs und Softwarekomponenten können unter Verwendung einer Modellierungsumgebung oder modellbasierter Entwicklungswerkzeuge generiert werden. Gemäß verschiedenen Ausführungsformen können die CSCs durch einen oder mehrere autonome Software-Agenten und/oder KI-Agenten basierend auf erlernten Erfahrungen, ODDs und/oder anderen ähnlichen Parametern generiert oder aktualisiert werden. Bei einem anderen Beispiel, bei Ausführungsformen, bei denen eine oder mehrere DCUs 1774.
  • Das IVS 101 und/oder die DCUs 1774 sind konfigurierbar oder betreibbar zum Betreiben eines oder mehrerer Aktuatoren basierend auf einem oder mehreren erfassten Ereignissen (wie durch Sensordaten angegeben, die durch die Sensoren 1772 erfasst werden) und/oder Anweisungen oder Steuersignale, die von Benutzereingaben empfangen werden, Signalen, die über die Luft von einem Diensteanbieter empfangen werden, oder dergleichen. Zusätzlich dazu können eine oder mehrere DCUs 1774 zum Betreiben eines oder mehrerer Aktuatoren durch Übertragen/Senden von Anweisungen oder Steuersignalen an die Aktuatoren basierend auf detektierten Ereignissen (wie durch Sensordaten angegeben, die durch die Sensoren 1772 erfasst werden) konfigurierbar oder betreibbar sein. Eine oder mehrere DCUs 1774 können in der Lage sein, Sensordaten von einem oder mehreren Sensoren 1772 zu lesen oder anderweitig zu erhalten, die Sensordaten zu verarbeiten, um Steuersystemdaten (oder CSCs) zu generieren, und die Steuersystemdaten einem oder mehreren Aktuatoren zum Steuern verschiedener Systeme des Fahrzeugs 110 bereitzustellen. Eine eingebettete Vorrichtung/ein eingebettetes System, die/das als eine zentrale Steuerung oder Hub agiert, kann auch auf die Steuersystemdaten zur Verarbeitung unter Verwendung eines geeigneten Treibers, API, ABI, einer Bibliothek, einer Middleware, Firmware und/oder dergleichen zugreifen; und/oder die DCUs 1774 können konfigurierbar oder funktionsfähig sein, die Steuersystemdaten einem zentralen Hub und/oder anderen Vorrichtungen/Komponenten auf periodischer oder aperiodischer Basis und/oder bei Triggerung bereitzustellen.
  • Die verschiedenen Subsysteme, einschließlich der Sensoren 1772 und/oder der DCUs 1774, können durch einen oder mehrere KI-Agenten betrieben und/oder gesteuert werden. Die KI-Agenten sind autonome Entitäten, die konfigurierbar oder betreibbar sind, Umgebungsbedingungen zu beobachten und Aktionen zu bestimmen, die zur Förderung eines speziellen Ziels durchgeführt werden sollen. Die zu beobachtenden speziellen Umgebungsbedingungen und die durchzuführenden Aktionen können auf einer Betriebsgestaltungsdomäne (ODD) basieren. Eine ODD beinhaltet die Betriebsbedingungen, unter denen ein gegebener KI-Agent oder ein gegebenes Merkmal davon speziell für die Funktion ausgelegt ist. Eine ODD kann Betriebseinschränkungen, wie etwa Umgebungs-, geographische und Tageszeiteinschränkungen, und/oder das erforderliche Vorhandensein oder Nichtvorhandensein gewisser Verkehrs- oder Straßeneigenschaften beinhalten.
  • Bei Ausführungsformen sind einzelne KI-Agenten konfigurierbar oder betreibbar, um jeweilige Steuersysteme des Hostfahrzeugs zu steuern, von denen manche die Verwendung einer oder mehrerer DCUs 1774 und/oder eines oder mehrerer Sensoren 1772 beinhalten können. Bei diesen Ausführungsformen können die zu ergreifenden Aktionen und die speziellen Ziele, die erreicht werden sollen, basierend auf dem Steuersystem selbst spezifisch oder individualisiert sein. Zusätzlich dazu können manche der Aktionen oder Ziele dynamische Fahraufgaben (DDT, Dynamic Driving Tasks), Objekt- und Ereignisdetektions- und Antwort (OEDR, Object and Event Detection and Response)-Aufgaben oder andere nicht fahrzeugbetriebsbezogene Aufgaben in Abhängigkeit von dem speziellen Kontext sein, in dem ein KI-Agent implementiert ist. DDTs beinhaltet alle Echtzeitbetriebs- und taktischen Funktionen, die erforderlich sind, um ein Fahrzeug 110 im Straßenverkehr zu betreiben, ausgenommen die strategischen Funktionen (z.B. Fahrtplanung und Auswahl von Zielen und Wegpunkten). DDTs beinhalten taktische und operative Aufgaben, wie etwa seitliche Fahrzeugbewegungssteuerung über Lenken (operativ); Fahrzeuglängsbewegungssteuerung über Beschleunigung und Verlangsamung (operativ); Überwachen der Fahrumgebung über Objekt- und Ereignisdetektion, -erkennung, -klassifizierung und -reaktionsvorbereitung (operativ und taktisch); Objekt- und Ereignisreaktionsausführung (operativ und taktisch); Manöverplanung (taktisch); und Verbesserung der Auffälligkeit mittels Beleuchtung, Signalisierung und Gestik usw. (taktisch). OEDR-Aufgaben können Teilaufgaben von DDTs sein, die das Überwachen der Fahrumgebung (z.B. Detektieren, Erkennen und Klassifizieren von Objekten und Ereignissen und Vorbereiten einer Reaktion nach Bedarf) und Ausführen einer geeigneten Reaktion auf solche Objekte und Ereignisse, zum Beispiel nach Bedarf, um die DDT oder Fallback-Aufgabe abzuschließen, beinhalten.
  • Um Umgebungsbedingungen zu beobachten, sind die KI-Agenten konfigurierbar oder funktionsfähig, Sensordaten von einem oder mehreren Sensoren 1772 zu empfangen oder auf diese zu überwachen und Steuersystemdaten (CSD) von einer oder mehreren DCUs 1774 des Hostfahrzeugs 110 zu empfangen. Der Vorgang des Überwachens kann Erfassen von CSD und/oder Sensordaten von einzelnen Sensoren 172 und DCUs 1774 beinhalten. Das Überwachen kann Abfragen (z.B. periodisches Abfragen, sequentielles (Roll-Call) Abfragen usw.) eines oder mehrerer Sensoren 1772 auf Sensordaten und/oder einer oder mehrerer DCUs 1774 auf CSD für einen spezifizierten/ausgewählten Zeitraum beinhalten. Bei anderen Ausführungsformen kann das Überwachen das Senden einer Anforderung oder eines Befehls für Sensordaten/CSD als Reaktion auf eine externe Anforderung von Sensordaten/CSD beinhalten. In einigen Ausführungsformen kann das Überwachen Warten auf Sensordaten/CSD von verschiedenen Sensoren/Modulen basierend auf Triggern oder Ereignissen beinhalten, wie etwa, wenn das Hostfahrzeug vorbestimmte Geschwindigkeiten und/oder Distanzen in einer vorbestimmten Zeitdauer (mit oder ohne intermittierte Stopps) erreicht. Die Ereignisse/Trigger können KI-agentenspezifisch sein und können sich in Abhängigkeit von einer speziellen Ausführungsform unterscheiden. In einigen Ausfuhrungsformen kann das Überwachen durch eine Anwendung oder ein Subsystem des IVS 101 oder durch eine Remote-Vorrichtung, wie etwa den Computerknoten 140 und/oder einen oder mehrere Server 160, getriggert oder aktiviert werden.
  • In einigen Ausführungsformen können einer oder mehrere der KI-Agenten konfigurierbar oder betreibbar sein, um die Sensordaten und CSD zu verarbeiten, um interne und/oder externe Umgebungsbedingungen zu identifizieren, bei denen gehandelt werden soll. Zu Beispielen für die Sensordaten können unter anderem zählen: Bilddaten von einer oder mehreren Kameras des Fahrzeugs, die Frontal-, Heck- und/oder Seitenansichten mit Blick aus dem Fahrzeug bereitstellen; Sensordaten von Beschleunigungsmessern, Trägheitsmesseinheiten (IMU) und/oder Gyroskope des Fahrzeugs, die Geschwindigkeits-, Beschleunigungs- und Neigungsdaten des Hostfahrzeugs bereitstellen; Audiodaten, die von Mikrofonen bereitgestellt werden; und Steuersystemsensordaten, die von einem oder mehreren Steuersystemsensoren bereitgestellt werden. In einem Beispiel können einer oder mehrere der KI-Agenten konfigurierbar oder betreibbar sein, um Bilder, die durch die Sensoren 1772 (Bilderfassungsvorrichtungen) erfasst werden, zu verarbeiten und/oder Bedingungen, die durch ein anderes Subsystem (z.B. ein EMA-Subsystem, CAS- und/oder CPS-Entitäten und/oder dergleichen) identifiziert werden, zu bewerten, um einen Zustand oder Beschaffenheit der Umgebung (z.B. Existenz von Schlaglöchern, umgestürzten Bäumen/Strommasten, Schäden an Straßenbegrenzungen, Fahrzeugtrümmerteilen und so weiter) zu bestimmen. Bei einem anderen Beispiel können einer oder mehrere der KI-Agenten konfigurierbar oder betreibbar sein, CSD zu verarbeiten, die durch eine oder mehrere DCUs 1774 bereitgestellt werden, um eine aktuelle Menge an Emissionen oder den Kraftstoffverbrauch des Hostfahrzeugs zu bestimmen. Die KI-Agenten können auch konfigurierbar oder funktionsfähig sein, die Sensordaten und/oder CSDs mit Trainingssatzdaten zu vergleichen, um Umgebungsbedingungen zum Steuern entsprechender Steuersysteme des Fahrzeugs zu bestimmen oder dazu beizutragen.
  • Um die Aktionen zu bestimmen, die zur Förderung eines speziellen Ziels durchgeführt werden sollen, ist jeder der KI-Agenten konfigurierbar oder funktionsfähig, einen aktuellen Zustand des IVS 101, der Hostfahrzeuge 110 und/oder des KI-Agenten selbst zu identifizieren, eines oder mehrere Modelle (z.B. ML-Modelle) zu identifizieren oder zu erhalten, Zielinformationen zu identifizieren oder zu erhalten und ein Ergebnis des Durchführens einer oder mehrerer Aktionen zu prognostizieren, basierend auf dem aktuellen Zustand/Kontext, dem einen oder den mehreren Modellen und den Zielinformationen. Das eine oder die mehreren Modelle können beliebige Algorithmen oder Objekte sein, die erzeugt werden, nachdem ein KI-Agent mit einem oder mehreren Trainingsdatensätzen trainiert wurde, und das eine oder die mehreren Modelle können die möglichen Aktionen angeben, die basierend auf dem aktuellen Zustand durchgeführt werden können. Das eine oder die mehreren Modelle können auf der ODD basieren, die für einen speziellen KI-Agenten definiert ist. Der aktuelle Zustand ist eine Konfiguration oder ein Satz von Informationen in dem IVS 101 und/oder einem oder mehreren anderen Systemen des Hostfahrzeugs 110 oder ein Maß verschiedener Bedingungen in dem IVS 101 und/oder einem oder mehreren anderen Systemen des Hostfahrzeugs 110. Der aktuelle Zustand wird innerhalb eines KI-Agenten gespeichert und in einer geeigneten Datenstruktur gehalten. Die KI-Agenten sind dazu konfigurierbar oder betreibbar, mögliche Ergebnisse als ein Ergebnis des Durchführens gewisser Aktionen, die durch die Modelle definiert sind, zu prognostizieren. Die Zielinformationen beschreiben gewünschte Ergebnisse (oder Zielzustände), die bei dem aktuellen Zustand wünschenswert sind. Jeder der KI-Agenten kann ein Ergebnis aus den prognostizierten möglichen Ergebnissen auswählen, das einen speziellen Zielzustand erreicht, und Signale oder Befehle für verschiedene andere Subsysteme des Fahrzeugs 110 bereitstellen, um eine oder mehrere Aktionen durchzuführen, von denen bestimmt worden ist, dass sie zu dem ausgewählten Ergebnis führen. Die KI-Agenten können auch ein Lernmodul beinhalten, das dazu konfigurierbar oder betreibbar ist, aus einer Erfahrung in Bezug auf das ausgewählte Ergebnis und manche Leistungsmaßnahme(n) zu lernen. Die Erfahrung kann Sensordaten und/oder neue Zustandsdaten beinhalten, die nach Durchführung der einen oder der mehreren Aktionen des ausgewählten Ergebnisses gesammelt wurden. Die erlernte Erfahrung kann verwendet werden, um neue oder aktualisierte Modelle zum Bestimmen zukünftiger durchzuführender Aktionen zu erzeugen.
  • Die Positionierungsschaltungsanordnung 1745 beinhaltet eine Schaltungsanordnung zum Empfangen und Decodieren von Signalen, die durch ein Positionierungsnetzwerk eines globalen Navigationssatellitensystems (GNSS) übertragen/rundgesendet werden. Beispiele für Navigationssatellitenkonstellationen (oder GNSS) beinhalten das globale Positionierungssystem (GPS) der Vereinigten Staaten, das globale Navigationssystem (GLONASS) Russlands, das Galileo-System der Europäischen Union, das Navigationssatellitensystem BeiDou Chinas, ein regionales Navigationssystem oder GNSS-Erweiterungssystem (z.B. Navigation with Indian Constellation (NAVIC), Quasi-Zenit-Satellite-System (QZSS) Japans, Doppler Orbitography and Radiopositioning Integrated by Satellite (DORIS) Frankreichs usw.) oder dergleichen. Die Positionierungsschaltungsanordnung 1745 umfasst verschiedene Hardwareelemente (z.B. einschließlich Hardwarevorrichtungen, wie etwa Schalter, Filter, Verstärker, Antennenelemente und dergleichen, um OTA-Kommunikationen zu ermöglichen), um mit Komponenten eines Positionierungsnetzwerks, wie etwa Navigationssatellitenkonstellationsknoten, zu kommunizieren. Bei einigen Ausführungsformen kann die Positionsbestimmungsschaltungsanordnung 1745 ein Mikrotechnologie für Positionsbestimmung, Navigation und Timing (Micro-PNT)-IC beinhalten, das ein Master-Timing-Taktsignal verwendet, um eine Positionsverfolgung/-schätzung ohne GNSS-Unterstützung durchzuführen. Die Positionsbestimmungsschaltungsanordnung 1745 kann auch Teil der Kommunikationsschaltungsanordnung 1766 sein oder damit interagieren, um mit den Knoten und Komponenten des Positionsbestimmungsnetzwerks zu kommunizieren. Die Positionsbestimmungsschaltungsanordnung 1745 kann auch Positionsdaten und/oder Zeitdaten für die Anwendungsschaltungsanordnung bereitstellen, welche die Daten verwenden kann, um Operationen mit diverser Infrastruktur (z.B. Funkbasisstationen) für Turn-by-Turn-Navigation oder dergleichen zu synchronisieren. Wenn kein GNSS-Signal verfügbar ist oder wenn eine GNSS-Positionsgenauigkeit für eine bestimmte Anwendung oder einen bestimmten Dienst nicht ausreicht, kann eine Positionierungserweiterungstechnologie verwendet werden, um erweiterte Positionierungsinformationen und -daten für die Anwendung oder den Dienst bereitzustellen. Solch eine Positionsbestimmungserweiterungstechnologie kann zum Beispiel satellitenbasierte Positionsbestimmungserweiterung (z.B. EGNOS) und/oder bodenbasierte Positionsbestimmungserweiterung (z.B. DGPS) umfassen. In einigen Implementierungen ist oder umfasst die Positionsbestimmungsschaltungsanordnung 1745 ein INS, das ein System oder eine Vorrichtung ist, das/die eine Sensorschaltungsanordnung 1772 (z.B. Bewegungssensoren, wie etwa Beschleunigungsmesser, Drehsensoren, wie etwa Gyroskope, und Höhenmesser, Magnetsensoren, und/oder dergleichen) verwendet, um ohne Notwendigkeit externer Referenzen kontinuierlich eine Position, Orientierung und/oder Geschwindigkeit (einschließlich Richtung und Geschwindigkeit der Bewegung) des Knotens 1750 zu berechnen (z.B. unter Verwendung von Koppelnavigationsverfahren, Triangulation oder dergleichen).
  • In einigen optionalen Beispielen können verschiedene Eingabe/Ausgabe- (E/A-) Vorrichtungen, die in 17 als Eingabeschaltungsanordnung 1786 und Ausgabeschaltungsanordnung 1784 bezeichnet werden, innerhalb des Edge-Rechenknotens 1750 vorhanden oder damit verbunden sein. Die Eingabeschaltungsanordnung 171686 und die Ausgabeschaltungsanordnung 1784 beinhalten eine oder mehrere Benutzerschnittstellen, die dazu ausgelegt sind, Benutzerinteraktion mit dem Knoten 1750 zu ermöglichen, und/oder Peripheriekomponentenschnittstellen, die dazu ausgelegt sind, Interaktion von Peripheriekomponenten mit dem Knoten 1750 zu ermöglichen. Die Eingabeschaltungsanordnung 1786 kann ein beliebiges physisches oder virtuelles Mittel zum Annehmen einer Eingabe beinhalten, einschließlich unter anderem eine oder mehrere physische oder virtuelle Tasten (z.B. eine Rücksetztaste), eine physische Tastatur, ein Tastenfeld, eine Maus, ein Touchpad, einen Touchscreen, Mikrofone, einen Scanner, ein Headset und/oder dergleichen. Die Ausgabeschaltungsanordnung 1784 kann beinhaltet sein, um Informationen zu zeigen oder anderweitig Informationen zu übermitteln, wie etwa Sensormesswerte, Aktuatorstellung(en) oder andere ähnliche Informationen. Daten und/oder Grafiken können auf einer oder mehreren Benutzerschnittstellenkomponenten der Ausgabeschaltungsanordnung 1784 angezeigt werden. Die Ausgabeschaltungsanordnung 1784 kann eine beliebige Anzahl und/oder Kombinationen von akustischen oder visuellen Anzeigen umfassen, einschließlich unter anderem eine oder mehrere einfache visuelle Ausgaben/Anzeigegeräte (z. B. binäre Statusanzeigegeräte (z. B. Leuchtdioden (LEDs)) und visuelle Mehrzeichenausgaben oder komplexere Ausgaben, wie etwa Anzeigevorrichtungen oder Touchscreens (z.B. Flüssigkristallanzeigen (LCD), LED-Anzeigen, Quantenpunktanzeigen, Projektoren usw.), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Knotens 1650 generiert oder erzeugt wird. Die Ausgabeschaltungsanordnung 1784 kann auch Lautsprecher oder andere Audioemissionsvorrichtungen, Drucker und/oder dergleichen beinhalten. In einigen Ausführungsformen kann die Sensorschaltungsanordnung 1772 als die Eingabeschaltungsanordnung 1784 (z.B. eine Bilderfassungsvorrichtung, Bewegungserfassungsvorrichtung oder dergleichen) verwendet werden und können ein oder mehrere Aktuatoren 1774 als die Ausgabevorrichtungsschaltungsanordnung 1784 (z.B. ein Aktuator zum Bereitstellen einer haptischen Rückmeldung oder dergleichen) verwendet werden. In einem anderen Beispiel kann eine Nahfeldkommunikation-(NFC-)Schaltungsanordnung, die eine NFC-Steuerung umfasst, die mit einem Antennenelement und einer Verarbeitungsvorrichtung gekoppelt ist, enthalten sein, um elektronische Tags zu lesen und/oder eine Verbindung mit einer anderen NFC-fähigen Vorrichtung herzustellen. Peripheriekomponentenschnittstellen können unter anderem einen nichtflüchtigen Speicheranschluss, einen USB-Anschluss, eine Audio-Buchse, eine Stromversorgungsschnittstelle usw. umfassen. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um Ausgaben bereitzustellen und Eingaben eines Edge-Computing-Systems zu empfangen; Komponenten oder Dienste eines Edge-Computing-Systems zu verwalten; einen Zustand einer Edge-Computing-Komponente oder eines Edge-Computing-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Management- oder Verwaltungsfunktionen oder Dienstanwendungsfällen durchzuführen.
  • Eine Batterie 1776 kann den Edge-Computing-Knoten 1750 mit Strom versorgen, obwohl sie in Beispielen, in denen der Edge-Computing-Knoten 1750 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als Backup oder für temporäre Fähigkeiten verwendet werden kann. Die Batterie 1776 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
  • Ein Batterieüberwachungs-/-ladegerät 1778 kann in dem Edge-Computing-Knoten 1750 enthalten sein, um den Ladezustand (SoCh) der Batterie 1776, falls enthalten, zu verfolgen. Das Batterieüberwachungs-/-ladegerät 1778 kann verwendet werden, um andere Parameter der Batterie 1776 zu überwachen, um Störungsprädiktionen, wie etwa den Gesundheitszustand (SoH, State of Health) und den Funktionszustand (SoF, State of Function) der Batterie 1776 bereitzustellen. Das Batterieüberwachungs-/-ladegerät 1778 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor aus Phoenix Arizona oder einen IC aus der UCD90xxx-Familie von Texas Instruments aus Dallas, TX. Das Batterieüberwachungs-/-ladegerät 1778 kann die Informationen über die Batterie 1776 über die IX 1756 an den Prozessor 1752 kommunizieren. Das Batterieüberwachungs-/-ladegerät 1778 kann auch einen Analog-Digital-Wandler (ADC) umfassen, der es dem Prozessor 1752 ermöglicht, die Spannung der Batterie 1776 oder den Stromfluss aus der Batterie 1776 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Computing-Knoten 1750 durchführen kann, wie etwa Übertragungsfrequenz, vermaschten Netzwerkbetrieb, Abtastfrequenz und dergleichen.
  • Ein Leistungsblock 1780 oder eine andere Leistungsversorgung, die mit einem Stromnetz gekoppelt ist, kann mit dem Batterieüberwachungs-/-ladegerät 1778 gekoppelt sein, um die Batterie 1776 zu laden. In einigen Beispielen kann der Leistungsblock 1780 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Schleifenantenne im Edge-Rechenknoten 1750, zu erhalten. Eine drahtlose Batterieladeschaltung, wie etwa unter anderem ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in dem Batterieüberwachungs-/-ladegerät 1778 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1776 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance vertriebenen Airfuel Standards, des von dem Wireless Power Consortium vertriebenen Qi-Drahtlosladestandards oder des von der Alliance for Wireless Power vertriebenen Rezence-Ladestandards durchgeführt werden.
  • Der Speicher 1758 kann Anweisungen 1782 in der Form von Software-, Firmware- oder Hardwarebefehlen beinhalten, um die hier beschriebenen Techniken zu implementieren. Obwohl solche Anweisungen 1782 als Codeblöcke gezeigt sind, die in dem Speicher 1754 und dem Speicher 1758 beinhaltet sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC, Application Specific Integrated Circuit) eingebaut sind.
  • Bei einem Beispiel können die Anweisungen 1782, die über den Speicher 1754, den Speicher 1758 oder den Prozessor 1752 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 1760 umgesetzt sein, das Code beinhaltet, um den Prozessor 1752 anzuweisen, elektronische Operationen in dem Edge-Computing-Knoten 1750 durchzuführen. Der Prozessor 1752 kann über die IX 1756 auf das nichtflüchtige maschinenlesbare Medium 1760 zugreifen. Beispielsweise kann das nichtflüchtige maschinenlesbare Medium 1760 durch Vorrichtungen umgesetzt sein, die für den Speicher 1758 beschrieben sind, oder es kann spezifische Speichereinheiten, wie etwa optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichtflüchtige, maschinenlesbare Medium 1760 kann Anweisungen beinhalten, um den Prozessor 1752 anzuweisen, eine spezifische Sequenz oder einen spezifischen Fluss von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das eine oder die mehreren Flussdiagramme und Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
  • Bei weiteren Beispielen beinhaltet ein maschinenlesbares Medium ein beliebiges greifbares Medium, das dazu in der Lage ist, Anweisungen zur Ausführung durch eine Maschine zu speichern, zu codieren oder zu tragen, welche bewirken, dass die Maschine eine oder mehrere der Methodologien der vorliegenden Offenbarung durchführt, oder das dazu in der Lage ist, Datenstrukturen, die durch solche Anweisungen genutzte oder mit diesen assoziiert sind, zu speichern, zu codieren oder zu tragen. Ein „maschinenlesbares Medium“ kann dementsprechend unter anderem Festkörperspeicher und optische und magnetische Medien beinhalten. Spezifische Beispiele maschinenlesbarer Medien beinhalten nichtflüchtigen Speicher, einschließlich unter anderem beispielsweise von Halbleiter-Speichervorrichtungen (z.B. elektrisch programmierbarer schreibgeschützter Speicher (EPROM), elektrisch löschbarer programmierbarer schreibgeschützter Speicher (EEPROM)) und Flashspeichervorrichtungen; Magnetplatten, wie z.B. interne Festplatten und Wechselplatten; magneto-optischen Platten; und CD-ROM- und DVD-ROM-Platten. Die durch ein maschinenlesbares Medium verkörperten Anweisungen können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstelleneinrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z.B. HTTP) nutzt.
  • Ein maschinenlesbares Medium kann durch eine Speichervorrichtung oder eine andere Einrichtung bereitgestellt sein, die in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. In einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen Anweisungen repräsentieren, wie etwa Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcodes, codierte Anweisungen (z.B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z.B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die Informationen, welche die Anweisungen in dem maschinenlesbaren Medium repräsentieren, können durch eine Verarbeitungsschaltungsanordnung zu den Anweisungen verarbeitet werden, um beliebige der hier erörterten Operationen zu implementieren. Zum Beispiel kann das Ableiten der Anweisungen aus den Informationen (z.B. Verarbeiten durch die Verarbeitungsschaltungsanordnung) Folgendes beinhalten: Kompilieren (z.B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z.B. dynamisches oder statisches Linken), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitiges Manipulieren der Informationen in die Anweisungen.
  • In einem Beispiel kann das Ableiten der Anweisungen Assemblieren, Kompilieren oder Interpretieren der Informationen (z.B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder einem vorverarbeiteten Format zu erzeugen, das durch das maschinenlesbare Medium bereitgestellt wird. Die Informationen können, wenn sie in mehreren Teilen bereitgestellt werden, kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarem Binär-Code usw.) auf einem oder mehreren entfernten Servern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk bewegt werden, und bei Bedarf entschlüsselt, entkomprimiert, zusammengesetzt (z.B. verlinkt) werden und in einer lokalen Maschine kompiliert oder interpretiert werden (z.B. in eine Bibliothek, eigenständige ausführbare Datei usw.) und von der lokalen Maschine ausgeführt werden.
  • Die Veranschaulichungen der 16 und 17 sollen eine Ansicht auf hoher Ebene von Komponenten einer variierenden Vorrichtung, eines variierenden Subsystems oder einer variierenden Anordnung eines Edge-Rechenknotens darstellen. Jedoch können manche der gezeigten Komponenten weggelassen werden, zusätzliche Komponenten können vorhanden sein, und eine andere Anordnung der Komponenten kann bei anderen Implementierungen auftreten. Ferner sind diese Anordnungen in einer Vielzahl von Anwendungsfällen und Umgebungen verwendbar, einschließlich jener, die hierin erörtert werden (z. B. ein mobiles UE in Industrial Compute für die intelligente Stadt oder die intelligente Fabrik, unter vielen anderen Beispielen). Die jeweiligen Rechenplattformen der 16 und 17 können mehrere Edge-Instanzen (z.B. Edge-Cluster) durch Verwenden von Mandanten-Containern unterstützen, die auf einer einzigen Rechenplattform ausgeführt werden. Gleichermaßen können mehrere Edge-Knoten als Unterknoten existieren, die auf Mandanten innerhalb derselben Rechenplattform ausgeführt werden. Dementsprechend kann basierend auf verfügbarer Ressourcenpartitionierung ein einzelnes System oder eine einzelne Rechenplattform in mehrere unterstützende Mandanten- und Edge-Knoteninstanzen partitioniert oder unterteilt werden, von denen jede mehrere Dienste und Funktionen unterstützen kann - selbst während sie potenziell in mehreren Rechenplattforminstanzen durch mehrere Besitzer betrieben oder gesteuert wird. Diese verschiedenen Arten von Partitionen können komplexe Multi-Mandanten und viele Kombinationen von Multi-Stakeholdern durch die Verwendung eines LSM oder einer anderen Implementierung einer Isolations-/Sicherheitsrichtlinie unterstützen. Hinweise auf die Verwendung eines LSM und Sicherheitsmerkmale, die solche Sicherheitsmerkmale verbessern oder implementieren, werden daher in den folgenden Abschnitten erwähnt. Gleichermaßen können Dienste und Funktionen, die auf diesen verschiedenen Typen von Mehrentitätspartitionen arbeiten, lastausgeglichen, migriert und orchestriert werden, um notwendige Dienstziele und Operationen zu erreichen.
  • 4. BEISPIELHAFTE EDGE-COMPUTING-SYSTEMKONFIGURATIONEN UND -ANORDNUNGEN
  • Edge-Computing bezieht sich auf die Implementierung, Koordination und Verwendung von Berechnung und Ressourcen an Orten näher am „Rand“ (Edge) oder der Ansammlung von „Rändern“ eines Netzwerks. Das Einsetzen von Rechenressourcen am Rand des Netzwerks kann Anwendungs- und Netzwerklatenz reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch reduzieren, Dienstfähigkeiten verbessern, die Einhaltung von Sicherheits- oder Datenschutzanforderungen verbessern (insbesondere im Vergleich zu herkömmlichem Cloud-Computing) und die Gesamtbetriebskosten verbessern.
  • Einzelne Rechenplattformen oder andere Komponenten, die Edge-Computing-Operationen ausführen können (als „Edge-Rechennoten“, „Edge-Knoten“ oder dergleichen bezeichnet), können sich an einem beliebigen Ort befinden, der von der Systemarchitektur oder dem Ad-hoc-Dienst benötigt wird. In vielen Edge-Computing-Architekturen werden Edge-Knoten an NANs, Gateways, Netzwerkroutern und/oder anderen Vorrichtungen bereitgestellt, die näher an Endpunktvorrichtungen (zum Beispiel UEs, IoT-Vorrichtungen usw.) liegen, die Daten produzieren und konsumieren. Als Beispiele können Edge-Knoten in einem Hochleistungsrechendatenzentrum oder einer Hochleistungs-Cloud-Installation; einem designierten Edge-Knoten-Server, einem Unternehmensserver, einem Straßenrandserver, einer Telekommunikationszentrale; oder einer lokalen oder Peer-at-the Edge-Vorrichtung, die bedient wird und Edge-Dienste konsumiert, implementiert werden.
  • Edge-Rechenknoten können Ressourcen (z.B. Speicher, CPU, GPU, Interruptsteuerung, E/A-Steuerung, Speichersteuerung, Buscontroller, Netzwerkverbindungen oder -sitzungen usw.) partitionieren, wobei jeweilige Partitionierungen Sicherheits- und/oder Integritätsschutzfunktionen enthalten können. Edge-Knoten können auch Orchestrierung mehrerer Anwendungen über isolierte Benutzerrauminstanzen, wie etwa Container, Partitionen, virtuelle Umgebungen (VEs), virtuelle Maschinen (VMs), FaaS(Function-as-a-Service)-Engines, Servlets, Server und/oder andere ähnliche Rechenabstraktionen, bereitstellen. Container sind begrenzte einsetzbare Softwareeinheiten, die Code und benötigte Abhängigkeiten bereitstellen. Verschiedene Edge-Systemanordnungen/-architekturen behandeln VMs, Container und funktionieren gleichermaßen hinsichtlich der Anwendungszusammensetzung. Die Edge-Knoten werden basierend auf Edge-Bereitstellungsfunktionen koordiniert, während der Betrieb der verschiedenen Anwendungen mit Orchestrierungsfunktionen (zum Beispiel VM oder Container-Engine usw.) koordiniert wird. Die Orchestrierungsfunktionen können verwendet werden, um die isolierten Benutzerrauminstanzen einzusetzen, die die Verwendung spezifischer Hardware, sicherheitsbezogener Funktionen (z.B. Schlüsselverwaltung, Vertrauensankerverwaltung usw.) und anderer Aufgaben in Bezug auf die Bereitstellung und den Lebenszyklus isolierter Benutzerräume identifizieren und planen.
  • Anwendungen, die für Edge-Computing angepasst wurden, beinhalten unter anderem Virtualisierung traditioneller Netzwerkfunktionen, darunter zum Beispiel softwaredefinierte Vernetzung (SDN), Netzwerkfunktionsvirtualisierung (NFV), verteilte RAN-Einheiten und/oder RAN-Clouds und dergleichen. Zusätzliche beispielhafte Verwendungsfälle für Edge-Computing beinhalten rechnerisches Offloading, Content-Data-Network-(CDN-) Dienste (z.B. Video on Demand, Content-Streaming, Sicherheitsüberwachung, Alarmsystemüberwachung, Gebäudezugang, Daten-/Content-Caching usw.), Gaming-Dienste (z.B. AR/VR usw.), beschleunigtes Browsen, IoT- und Industrieanwendungen (z.B. Fabrikautomatisierung), Medienanalytik, Live-Streaming/Transcodierung und V2X-Anwendungen (z.B. Fahrassistenz- und/oder Autonomfahranwendungen).
  • Internet-der-Dinge- (IoT-) Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktuatoren und andere Eingabe/Ausgabe-Komponenten beinhalten können, etwa zum Erfassen von Daten oder Durchführen von Aktionen aus einer realen Umgebung. IoT-Vorrichtungen können zum Beispiel Vorrichtungen mit niedriger Leistung beinhalten, die in alltäglichen Dingen eingebettet oder an diese angeschlossen sind, wie etwa Gebäuden, Fahrzeugen, Paketen usw., um ein zusätzliches Niveau an künstlicher Sinneswahrnehmung dieser Dinge bereitzustellen. In letzter Zeit sind IoT-Vorrichtungen immer beliebter geworden, und daher haben sich Anwendungen, die diese Vorrichtungen verwenden, stark verbreitet. Der Einsatz von IoT-Vorrichtungen und MEC- (Multizugriff-Edge-Computing-) hat eine Reihe fortgeschrittener Verwendungsfälle und -szenarien eingeführt, die am Rand (Edge) des Netzwerks auftreten oder diesen anderweitig beinhalten.
  • Edge-Rechnen kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen oder hosten, um Orchestrierung und Verwaltung von Anwendungen und koordinierten Dienstinstanzen unter vielen Arten von Speicher- und Rechenressourcen zu bieten. Es wird auch erwartet, dass Edge-Computing eng in existierende Verwendungsfälle und Technologie integriert wird, die für IoT- und Fog-/verteilte Vernetzungskonfigurationen entwickelt werden, da Endpunktvorrichtungen, Clients und Gateways versuchen, auf Netzwerkressourcen und Anwendungen an Orten zuzugreifen, die näher am Rand/der Edge des Netzwerks liegen.
  • Die vorliegende Offenbarung stellt spezifische Beispiele bereit, die für Edge-Rechenkonfigurationen relevant sind, die innerhalb von Mehrfachzugriff-Edge-Rechnen (MEC) und SG-Netzwerkimplementierungen bereitgestellt werden. Viele andere Standards und Netzimplementierungen sind jedoch auf die vorliegend erörterten Edge- und Dienstverwaltungskonzepte anwendbar. Zum Beispiel können die vorliegend besprochenen Ausführungsformen auf viele andere Edge-Computing-/Networking-Technologien in verschiedenen Kombinationen und Layouts von Vorrichtungen, die sich am Rand eines Netzwerks befinden, anwendbar sein. Beispiele für derartige anderen Edge-Computing-/Networking-Technologien, die die vorliegenden Ausführungsformen umsetzen können, beinhalten Content Delivery Networks (CDNs) (auch als „Content Distribution Networks“ oder dergleichen bezeichnet); Mobility-Service-Provider-Edge-Computing-(MSP-Edge-Computing-) und/oder Mobility-as-a-Service-Anbietersysteme (MaaS-Anbietersysteme) (zum Beispiel in AECC-Architekturen verwendet); Nebula-Edge-Cloud-Systeme; Fog-Computing-Systeme; Cloudlet-Edge-Cloud-Systeme; Mobile-Cloud-Computing-Systeme (MCC-Systeme); Central Office Re-Architected as a Datacenter (CORD), Mobile-CORD (M-CORD) und/oder Converged-Multi-Access-and-Core-Systeme (COMAC-Systeme); und/oder dergleichen. Weiter können vorliegend offenbarte Techniken andere IoT-Edge-Netzwerksysteme und -konfigurationen betreffen und andere zwischengeschaltete Verarbeitungsentitäten und Architekturen können ebenfalls verwendet werden, um die vorliegend beschriebenen Ausführungsformen umzusetzen.
  • 18 ist ein Blockdiagramm 1800, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als „Edge-Cloud“ bezeichnet wird. Eine „Edge-Cloud“ kann sich auf ein austauschbares Cloud-Ökosystem beziehen, das Speicherungs- und Rechenressourcen umfasst, die sich am Rand eines Netzwerks befinden und durch ein skalierbares anwendungsbewusstes Netzwerk miteinander verbunden sind, das sich ändernde Bedürfnisse in Echtzeit und auf eine sichere Weise erfassen und sich an diese anpassen kann. Eine Edge-Cloud-Architektur wird verwendet, um Rechenressourcen und -leistung an die Ränder eines oder mehrerer Netzwerke (z.B. Endpunktvorrichtungen und/oder Zwischenknoten, wie etwa Client-Vorrichtungen/UEs) zu dezentralisieren. Traditionell wird die Rechenleistung von Servern verwendet, um Aufgaben durchzuführen und verteilte Systeme zu erstellen. Innerhalb des Cloud-Modells werden solche intelligenten Aufgaben durch Server (z.B. in einem Datenzentrum) durchgeführt, so dass sie zu anderen Vorrichtungen mit weniger oder nahezu keiner Rechenleistung transferiert werden können. In derEdge-Cloud 1810 werden einige oder alle dieser Verarbeitungsaufgaben zu Endpunktknoten und Zwischenknoten verschoben, wie etwa Client-Vorrichtungen, IoT-Vorrichtungen, Netzwerkvorrichtungen/-geräte und/oder dergleichen. Es ist anzumerken, dass ein Endpunktknoten in einigen Kontexten das Ende eines Kommunikationspfads sein kann, während in anderen Kontexten ein Endpunktknoten ein Zwischenknoten sein kann; gleichermaßen kann ein Zwischenknoten in einigen Kontexten das Ende eines Kommunikationspfads sein, während in anderen Kontexten ein Zwischenknoten ein Endpunktknoten sein kann.
  • Wie gezeigt, befindet sich die Edge-Cloud 1810 gemeinsam an einem Randort, wie etwa einem Zugangspunkt oder einer Basisstation 1840, einem lokalen Verarbeitungs-Hub 1850 oder einer Zentrale 1820, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 1810 befindet sich viel näher an den Endpunkt- (Verbraucher und Erzeuger) Datenquellen 1860 (z.B. autonome Fahrzeuge 1861, Benutzergerät 1862, Geschäfts- und Industriegerät 1863, Videoaufnahmevorrichtungen 1864, Drohnen 1865, intelligente Städte und Gebäudevorrichtungen 1866, Sensoren und IoT-Vorrichtungen 1867 usw.) als das Cloud-Datenzentrum 1830. Rechen-, Speicher- und Speicherungsressourcen, die an den Edges in der Edge-Cloud 1810 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 1860 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 1810 zum Cloud-Rechenzentrum 1830, wodurch neben anderen Vorteilen Energieverbrauch und Gesamtnetzwerknutzungen verbessert werden.
  • Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit von dem Edge-Ort ab (wobei z.B. weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen verfügbar sind als an einer Basisstation als an einer Zentrale). Je näher sich der Edge-Standort jedoch am Endpunkt (z.B. Endgerät (UE)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Computing die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sich sowohl geographisch als auch in der Netzwerkzugriffszeit näher befinden, zu reduzieren. Auf diese Weise versucht Edge-Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
  • Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere potenzielle Einsätze abdeckt und Einschränkungen anspricht, die manche Netzwerkbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten Variation von Konfigurationen basierend auf dem Edge-Ort (weil Edges auf einer Basisstationsebene zum Beispiel mehr eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art von Berechnung, Speicher, Speicherung, Fabric, Beschleunigung oder ähnlichen Ressourcen, die Edge-Orten, Stufen von Orten oder Gruppen von Orten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und zugehörige Ziele zum Erreichen der Nutzbarkeit und Leistungsfähigkeit von Enddiensten. Diese Einsätze können die Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Abstands- und Timing-Charakteristiken als „Near Edge“-, „Close Edge“-, „Local Edge“-, „Middle Edge“- oder „Far Edge“-Schichten betrachtet werden können.
  • Edge-Computing ist ein sich entwickelndes Paradigma, bei dem die Berechnung an oder näher der „Edge“ (dem „Rand“) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z.B. x86- oder ARM-Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die sich viel näher an Endpunktvorrichtungen befinden, die Daten erzeugen und verbrauchen. Edge-Gateway-Server können zum Beispiel mit Pools von Arbeitsspeicher- und Massenspeicherressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Verwendungsfälle mit niedriger Latenz (z.B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Benutzergeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Oder als weiteres Beispiel kann zentrale Büronetzwerkverwaltungshardware durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucheranwendungen für angebundene Vorrichtungen bietet. Innerhalb von Edge-Rechennetzwerken kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien geben, in denen die Daten zur Rechenressource „verschoben“ werden. Oder als ein Beispiel können Rechen-, Beschleunigungs- und Netzwerkressourcen an der Basisstation Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf zu skalieren, indem nicht genutzte Kapazität (Subskription, Capacity on Demand) aktiviert wird, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
  • 19 veranschaulicht Betriebsschichten unter Endpunkten, eine Edge-Cloud und Cloud-Rechenumgebungen. Insbesondere stellt 19 Beispiele für Rechenanwendungsfälle 1905 dar, welche die Edge-Cloud 1810 unter mehreren veranschaulichenden Schichten von Netzwerk-Computing nutzen. Die Schichten beginnen an einer Endpunkt-Schicht (Vorrichtungen und Dinge) 1900, die auf die Edge-Cloud 1810 zugreift, um Datenerzeugungs-, Analyse- und Datenverbrauchsaktivitäten durchzuführen. Die Edge-Cloud 1810 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Vorrichtungsschicht 1910 mit Gateways, Vor-Ort-Servern oder Netzwerkgeräten (Knoten 1915), die sich in physisch nahen Edge-Systemen befinden; eine Netzwerkzugangsschicht 1920, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerkhubs, regionale Datenzentren (DZ) oder lokale Netzwerkgeräte (Geräte 1925); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 1912, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 1810 und inmitten der verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
  • Beispiele für Latenz, die aus Netzwerkkommunikationsdistanz- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn unter der Endpunktschicht 1900, unter 5 ms auf der Edge-Vorrichtungsschicht 1910 bis sogar zwischen 10 und 40 ms reichen, wenn mit Knoten auf der Netzwerkzugangsschicht 1920 kommuniziert wird. Jenseits der Edge-Cloud 1810 befinden sich Schichten des Kernnetzes 1930 und des Cloud-Rechenzentrums 1940, jeweils mit zunehmender Latenz (z. B. zwischen 50-60 ms an der Kernnetzschicht 1930, bis 100 oder mehr ms an der Cloud-Rechenzentrumsschicht). Infolgedessen werden Operationen in einem Kernnetz-Datenzentrum 1935 oder einem Cloud-Datenzentrum 1945 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Anwendungsfälle 1905 zu erfüllen. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. In manchen Beispielen können jeweilige Abschnitte des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als Schichten „Close Edge“, „Local Edge“, „Near Edge“, „Middle Edge“ oder „Far Edge“ kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetzwerk-Datenzentrums 1935 oder eines Cloud-Datenzentrums 1945 ein Zentral- oder Inhaltsdatennetzwerk als innerhalb einer „Near Edge“-Schicht („nahe“ zu der Cloud, mit hohen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Anwendungsfälle 1905 kommuniziert wird) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein On-Premise-Server oder ein Netzwerk-Gateway als innerhalb einer „Far Edge“-Schicht („fern“ von der Cloud, mit niedrigen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Anwendungsfälle 1905 kommuniziert wird) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als eine „Close“, „Local“, „Near“, „Middle“ oder „Far“ Edge bildend auf Latenz, Entfernung, Anzahl von Netzwerksprüngen oder anderen messbaren Charakteristiken basieren können, wie von einer Quelle in einer beliebigen der Netzwerkschichten 1900-1940 gemessen.
  • Die diversen Verwendungsfälle 1905 können aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, auf Ressourcen unter Nutzungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 1810 ausgeführt werden, variierende Anforderungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS) (z.B. Verkehr für ein autonomes Fahrzeug kann hinsichtlich der Antwortzeitanforderung eine höhere Priorität als ein Temperatursensor aufweisen; oder eine Leistungsfähigkeitsempfindlichkeit/ein Leistungsfähigkeitsengpass kann an einer Rechen-Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource in Abhängigkeit von der Anwendung existieren); (b) Zuverlässigkeit und Widerstandsfähigkeit (z.B. müssen manche Eingangsströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wohingegen manche anderen Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physische Beschränkungen (z.B. Leistung, Kühlung und Formfaktor).
  • Die Ende-zu-Ende-Dienstansicht für diese Anwendungsfälle beinhaltet den Begriff eines Dienstflusses und ist einer Transaktion zugeordnet. Die Transaktion gibt die Gesamtdienstanforderung für die Entität an, die den Dienst in Anspruch nimmt, sowie die zugehörigen Dienste für die Ressourcen, Workloads, Arbeitsabläufe und Unternehmensfunktions- und Unternehmensebenenanforderungen. Die Dienste, die mit den beschriebenen „Bedingungen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihre vereinbarte SLA verfehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten im System zu erweitern, um die Gesamttransaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
  • Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 1810 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 1905 (z. B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu versorgen und auf diese zu reagieren und Voraussetzungen für ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (VNFs (Virtual Network Functions), FaaS (Function as a Service), Edge as a Service (EaaS), Standardprozesse usw.), die herkömmliches Cloud-Computing aufgrund von Latenz oder anderen Einschränkungen nicht nutzen können.
  • Mit den Vorteilen von Edge-Computing ergeben sich jedoch die folgenden Vorbehalte. Die am Edge befindlichen Vorrichtungen sind häufig ressourcenbeschränkt, sodass Druck auf die Nutzung von Edge-Ressourcen besteht. Typischerweise wird dies durch das Zusammenfassen von Arbeitsspeicher- und Massenspeicherressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Die Edge kann in Leistung und Kühlung eingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen, die die meiste Leistung verbrauchen, berücksichtigt werden muss. Es kann inhärente Leistungs-Leistungsfähigkeits-Kompromisse in diesen gebündelten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen für mehr Leistung eine größere Speicherbandbreite notwendig ist. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Funktionen mit Stammvertrauenstellung ebenfalls erforderlich, da Edge-Standorte unbemannt sein können und sogar genehmigten Zugriff benötigen können (z.B. wenn sie an einem Standort von Drittanbietern untergebracht sind). Derartige Probleme werden in der Edge-Cloud 1810 in einer Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriffssituation vergrößert, bei der Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere, da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Beteiligten, Anwendungsfälle und Dienste ändert.
  • Auf einer allgemeineren Ebene kann ein Edge-Rechensystem so beschrieben werden, dass es eine beliebige Anzahl von Bereitstellungen in den zuvor besprochenen Schichten umfasst, die in der Edge-Cloud 1810 arbeiten (Netzwerkschichten 1900-1940), die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gatewayknoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kernrechenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telco“ oder „TSP“), eines Internet-der-Dinge-Dienstanbieters, eines Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Computing-Systems können dynamisch bereitgestellt werden, wie etwa bei Orchestrierung, um Dienstziele zu erfüllen.
  • Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -vorrichtung, -gerät oder anderem Ding ausgebildet sein, die bzw. das fähig ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Kennzeichnung „Knoten“ oder „Vorrichtung“, wie sie in dem Edge-Computing-System verwendet wird, nicht notwendigerweise, dass ein solcher Knoten oder Vorrichtung in einer Client- oder Agent-/Minion-/Folger-Rolle arbeitet; vielmehr beziehen sich beliebige der Knoten oder Vorrichtungen in dem Edge-Computing-System auf einzelne Entitäten, Knoten oder Subsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 1810 zu ermöglichen oder zu verwenden.
  • Von daher ist die Edge-Cloud 1810 aus Netzwerkkomponenten und Funktionsmerkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 1910-1930 betrieben werden. Die Edge-Cloud 1810 kann somit als eine beliebige Art von Netzwerk ausgebildet sein, das Edge-Rechen- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z.B. Mobilrechenvorrichtungen, IoT-Vorrichtungen, Smartvorrichtungen usw.) befinden, die vorliegend besprochen sind. Anders ausgedrückt kann man sich die Edge-Cloud 1810 als ein „Rand“ vorstellen, der die Endpunktvorrichtungen und herkömmliche Netzwerkzugangspunkte verbindet, die als ein Zugriffspunkt zu Kernnetzen von Dienstanbietern dienen, einschließlich Netzwerken von mobilen Trägern (z.B. Netzwerke des Global System for Mobile Communications (GSM), Long-Term-Evolution(LTE)-Netzwerke, 5G/6G-Netzwerke usw.), während er auch Speicher- oder Rechenfunktionen bereitstellt. Andere Arten und Formen von Netzwerkzugang (z.B. WiFi, Long-Range-Wireless, drahtgebundene Netzwerke einschließlich optischer Netzwerke) können auch anstelle von oder in Kombination mit solchen 3 GPP-Trägernetzen genutzt werden.
  • Die Netzwerkkomponenten der Edge-Cloud 1810 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 1810 eine Geräterechenvorrichtung beinhalten, die eine eigenständige elektronische Einrichtung mit einer Einhausung, einem Chassis, einem Gehäuse oder einer Schale ist. Unter einigen Umständen kann die Einhausung für Portabilität dimensioniert sein, sodass es von einem Menschen getragen und/oder versandt werden kann. Beispielhafte Einhausungen können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (z.B. EMI, Vibration, extreme Temperaturen) beinhalten kann und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Einhausungen können Leistungsschaltungsanordnungen beinhalten, um Leistung für stationäre und/oder tragbare Implementierungen bereitzustellen, wie etwa AC-Leistungseingänge, DC-Leistungseingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnungen, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Beispielhafte Einhausungen und/oder Oberflächen davon können Montagehardware beinhalten oder mit dieser verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (z. B. Masten, Antennenstrukturen usw.) und/oder Racks (z. B. Server-Racks, Bladebefestigungen usw.), zu ermöglichen. Beispielhafte Gehäuse und/oder Oberflächen davon können einen oder mehrere Sensoren (z.B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, kapazitive Sensoren, Näherungssensoren usw.) unterstützen. Ein oder mehrere derartige Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderweitig in dieser eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Einhausungen und/oder Oberflächen davon können mechanische Konnektivität unterstützen, wie etwa Antriebshardware (z.B. Räder, Propeller usw.) und/oder Gelenkhardware (z.B. Roboterarme, schwenkbare Anhänge usw.). Unter manchen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellenhardware (z.B. Tasten, Schalter, Wählscheiben, Schieber usw.). Unter manchen Umständen beinhalten beispielhafte Einhausungen Ausgabevorrichtungen, die darin enthalten sind, dadurch getragen werden, darin eingebettet und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Ports (z.B. USB) usw. beinhalten. Unter manchen Umständen sind Edge-Vorrichtungen Vorrichtungen, die im Netzwerk für einen spezifischen Zweck (z.B. eine Verkehrsampel) präsentiert werden, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Derartige Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und können mit einem Gehäuse versehen sein, das einen Formfaktor aufweist, der für ihren primären Zweck geeignet ist; sie ist aber dennoch für andere Rechenaufgaben verfügbar, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Vorrichtungen des Internets der Dinge. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten umfassen, um lokale Belange, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Stromprobleme, physische und Netzwerksicherheit usw., zu handhaben. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 16 und 17 beschrieben. Die Edge-Cloud 1810 kann auch einen oder mehrere Server und/oder einen oder mehrere mandantenfähige Server beinhalten. Ein solcher Server kann ein Betriebssystem und eine virtuelle Rechenumgebung beinhalten. Eine virtuelle Rechenumgebung kann einen Hypervisor beinhalten, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (erzeugt, einsetzt, zerstört usw.). Derartige virtuelle Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, anderer Code oder andere Skripte ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
  • Die von der Edge-Cloud 1810 bereitgestellten Speicherungs- und/oder Rechenfähigkeiten können spezifische Beschleunigungstypen beinhalten, die konfiguriert oder identifiziert werden können, um sicherzustellen, dass eine Dienstdichte über die Edge-Cloud hinweg erfüllt ist. In einigen Implementierungen können vier primäre Beschleunigungstypen in einer Edge-Cloud-Konfiguration eingesetzt werden: (1) Allgemeine Beschleunigung (z.B. FPGAs) zum Implementieren von Basisrechenblöcken, wie etwa einer schnellen Fouriertransformation (FFT), einem k-Nearest-Neighbors-Algorithmus (KNN) und Maschinenlernarbeitslasten; (2) Bild-, Video- und Transcodierungsbeschleuniger; (3) Inferenzbeschleuniger; (4) krypto- und kompressionsbezogene Arbeitslasten (z.B. implementiert wie in Intel® QuickAssist™-Technologie). In einigen Implementierungen kann die Edge-Cloud 1810 eine Neuronalnetz- (NN-) Beschleunigung bereitstellen, um NN-Dienste für eine oder mehrere Arten von NN-Topologien bereitzustellen, wie etwa Faltungs-NN (CNN), rekurrentes NN (RNN), einen LSTM- (Long Short Term Memory) Algorithmus, ein tiefes CNN (DCN), ein Entfaltungs-NN (DNN), eine gategesteuerte rekurrente Einheit (GRU), ein Deep-Belief-NN, ein Vorwärtskopplungs-NN (FFN), ein tiefes FNN (DFF), ein Deep-Stacking-Netzwerk, eine Markov-Kette, ein Wahrnehmungs-NN, ein Bayessches Netzwerk (BN), ein Dynamisches BN (DBN), ein lineardynamisches System (LDS), ein Schalt-LDS (SLDS), ein Kalman-Filter, Gauss'sches Mischmodell, Partikelfilter, Mean-Shift-basierte Kernelverfolgung, eine ML-Objektdetektionstechnik (z.B. Viola-Jones-Objektdetektions-Framework, skaleninvariante Merkmalstransformation (SIFT), ein Histogramm von orientierten Gradienten (HOG) usw.), eine Deep-Learning-Objektdetektionstechnik (z.B. FCNN (Fully Convolutional Neural Network, vollständig faltendes neuronales Netz), ein neuronales Bereichsvorschlag-Faltungsnetz (R-CNN, Region Proposal Convolution Neural Network), Single-Shot-Multibox-Detektor, ‚Man sieht nur einmal‘- (YOLO-, You Only Look Once) Algorithmus usw.) und so weiter. Die spezielle Gestaltung oder Konfiguration der Edge-Plattformfähigkeiten kann berücksichtigen, welches der richtige Typ von Beschleunigungs- und Plattformproduktmodellen ist, der ausgewählt werden muss, um die Dienst- und Durchsatzdichte sowie verfügbare Leistung zu gewährleisten.
  • In 20 tauschen verschiedene Client-Endpunkte 2010 (in der Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 2010 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anfragen und Antworten 2022 durch ein Vor-Ort-Netzwerksystem 2032 ausgetauscht werden. Einige Client-Endpunkte 2010, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 2024 durch einen Zugangspunkt (z.B. Mobilfunknetzturm) 2034 ausgetauscht werden. Manche Client-Endpunkte 2010, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anforderungen und Antworten 2026 über ein drahtloses Fahrzeugnetzwerk durch ein Straßennetzwerksystem 2036 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 2042, 2044 innerhalb der Edge-Cloud 1810 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 1810 verschiedene Rechen- und Speicherressourcen bereitstellen, wie etwa an Edge-Aggregationsknoten 2040, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 2040 und andere Systeme der Edge-Cloud 1810 sind mit einer Cloud oder einem Rechenzentrum 2060 verbunden, das ein Backhaul-Netzwerk 2050 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Rechenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 2040 und der Aggregationspunkte 2042, 2044, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 1810 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
  • 21 veranschaulicht eine beispielhafte Softwareverteilungsplattform 2105 zum Verteilen von Software 2160, wie etwa der beispielhaften computerlesbaren Anweisungen 1760 aus 17, an eine oder mehrere Vorrichtungen, wie etwa an eine oder mehrere beispielhafte Prozessorplattformen 2100 und/oder eine oder mehrere beispielhafte verbundene Edge-Vorrichtungen 1762 (siehe z.B. 17) und/oder beliebige der anderen hier erörterten Rechensysteme/Vorrichtungen. Die beispielhafte Softwareverteilungsplattform 2105 kann durch einen beliebigen Computerserver, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, der/die in der Lage ist, Software zu speichern und zu anderen Rechenvorrichtungen (z.B. Dritte, die beispielhaften verbundenen Edge-Vorrichtungen 1762 aus 17) zu übertragen. Beispielhafte verbundene Edge-Vorrichtungen können Kunden, Clients, Verwaltungsvorrichtungen (z.B. Server), Dritte (z.B. Kunden einer Entität, die die Softwareverteilungsplattform 2105 besitzt und/oder betreibt) sein. Beispielhafte verbundene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. In einigen Beispielen ist eine Drittpartei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa den beispielhaften computerlesbaren Anweisungen 1760 aus 17. Die Drittparteien können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung und/oder zum Weiterverkauf und/oder zum Sublizenzieren erwerben und/oder lizenzieren. In einigen Beispielen bewirkt verteilte Software, dass eine Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs) die eine oder die mehreren Vorrichtungen (z.B. verbundene Edge-Vorrichtungen) identifiziert, die geographisch und/oder logisch voneinander getrennt sind (z.B. physisch getrennte IoT-Vorrichtungen, denen die Verantwortung von Wasserverteilungssteuerung (z.B. Pumpen), Stromverteilungssteuerung (z.B. Relais) usw. erteilt ist).
  • Bei dem veranschaulichten Beispiel aus 21 beinhaltet die Softwareverteilungsplattform 2105 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen. Die Speicherungsvorrichtungen speichern computerlesbare Anweisungen 2160, die den beispielhaften computerlesbaren Anweisungen 1760 aus 17 entsprechen können, wie oben beschrieben. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 2105 stehen in Kommunikation mit einem Netzwerk 2110, das dem Internet und/oder beliebigen der beispielhaften Netzwerke 158, 1810, 1830, 1910, 2010 und/oder dergleichen, wie vorliegend beschrieben, entsprechen können. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anfragen, die Software als Teil einer kommerziellen Transaktion an eine anfragende Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittanbieter-Zahlungsentität gehandhabt werden. Die Server ermöglichen Käufer und/oder Lizenzgeber, die computerlesbaren Anweisungen 2160 von der Softwareverteilungsplattform 2105 herunterzuladen. Zum Beispiel kann die Software 2160, die den beispielhaften computerlesbaren Anweisungen 1760 aus 17 entsprechen kann, auf die eine oder die mehreren beispielhaften Prozessorplattformen 2100 heruntergeladen werden, die die computerlesbaren Anweisungen 2160 ausführen sollen, um Funk-Apps und/oder die vorliegend besprochenen Ausführungsformen zu implementieren.
  • In einigen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 2105 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 2160 laufen müssen. In einigen Beispielen bieten ein oder mehrere Server des Softwareverteilungsplattform 2105 periodisch Aktualisierungen an der Software (z.B. den beispielhaften computerlesbaren Anweisungen 1760 aus 17) an, übertragen und/oder setzen diese durch, um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewendet werden.
  • Bei dem veranschaulichten Beispiel aus 21 sind die computerlesbaren Anweisungen 2160 auf Speichervorrichtungen der Softwareverteilungsplattform 2105 in einem besonderen Format gespeichert. Ein Format von computerlesbaren Anweisungen beinhaltet unter anderem eine bestimmte Codesprache (z.B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen speziellen Codezustand (z.B. uncompilierten Code (z.B. ASCII), interpretierten Code, gelinkten Code, ausführbaren Code (z.B. eine Binärdatei) usw.). In einigen Beispielen befinden sich die computerlesbaren Anweisungen D 182, die in der Softwareverteilungsplattform 2105 gespeichert sind, in einem ersten Format, wenn sie an die eine oder die mehreren beispielhaften Prozessorplattformen 2100 übertragen werden. In einigen Beispielen ist das erste Format eine ausführbare Binärdatei, in der bestimmte Arten der Prozessorplattform(en) 2100 arbeiten können. In einigen Beispielen ist das erste Format jedoch unkompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, um eine Ausführung auf der/den beispielhaften Prozessorplattform(en) 2100 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 2100 möglicherweise die computerlesbaren Anweisungen 2160 im ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der auf der/den Prozessorplattform(en) 2100 ausgeführt werden kann. In anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der ein oder mehreren Prozessorplattformen 2100 durch einen Interpreter interpretiert wird, um die Ausführung von Anweisungen zu ermöglichen.
  • 5. IMPLEMENTIERUNGSBEISPIELE
  • Zusätzliche Beispiele für die vorliegend beschriebenen Verfahrens-, System- und Vorrichtungsausführungsformen beinhalten die folgenden, nicht einschränkenden Konfigurationen. Jedes der nicht einschränkenden Beispiele kann für sich allein stehen oder in einer beliebigen Permutation oder Kombination mit einem oder mehreren der anderen Beispiele, die nachstehend oder durch die gesamte vorliegende Offenbarung bereitgestellt werden, kombiniert werden.
  • Beispiel 1 beinhaltet ein Verfahren, das durch eine Ursprungs-ITS-S (Intelligent Transport System Station, Station eines intelligenten Transportsystems) durchzuführen ist, wobei das Verfahren Folgendes umfasst: Sammeln und Verarbeiten von Sensordaten; Erzeugen einer dynamischen kontextbezogenen Straßenbelegungskarte (DCROM, Dynamic Contextual Road Occupancy Map) basierend auf den gesammelten und verarbeiteten Sensordaten; Konstruieren einer VAM (Vulnerable Road User Awareness Message, Bewusstmachungsnachricht bezüglich ungeschützter Verkehrsteilnehmer), die ein oder mehrere Datenfelder (DFs) zum Teilen von DCROM-Informationen beinhaltet; und Übertragen oder Rundsenden der VAM an einen Satz von ITS-Ss einschließlich eines oder mehrerer ungeschützter Verkehrsteilnehmer (VRUs).
  • Beispiel 2 beinhaltet das Verfahren nach Beispiel 1 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die DCROM eine Belegungskarte mit einer Vielzahl von Zellen ist, wobei jede Zelle der Vielzahl von Zellen einen Belegungswert beinhaltet und der Belegungswert jeder Zelle eine Wahrscheinlichkeit ist, dass eine entsprechende Zelle von einem Objekt belegt ist.
  • Beispiel 3a beinhaltet das Verfahren nach Beispiel 2 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die DCROM-Informationen eines oder mehrere der Folgenden beinhalten: einen Referenzpunkt, der einen Standort der Ursprungs-ITS-S in einem durch die DCROM abgedeckten Bereich angibt; eine Gittergröße, die Abmessungen des Gitters angibt; eine Zellengröße, die Abmessungen jeder Zelle der Vielzahl von Zellen angibt; und eine Startposition, die eine Startzelle des Belegungsgitters angibt, wobei andere Zellen der Vielzahl von Zellen basierend auf ihrer Beziehung zur Startzelle zu kennzeichnen sind.
  • Beispiel 3b beinhaltet das Verfahren nach Beispiel 3a und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei der Zellengrößen- und/oder der Gittergrößenparameter eine Gesamtanzahl von Stufen angeben.
  • Beispiel 3c beinhaltet das Verfahren nach Beispiel 3b und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die Gesamtanzahl an Stufen eine erste Stufe, die 8 Zellen umfasst, die die DCROM der Ursprungs-ITS-S umgeben, und eine zweite Stufe beinhaltet, die 16 zusätzliche Zellen umfasst, die die 8 Zellen der ersten Stufe umgeben.
  • Beispiel 4 beinhaltet das Verfahren der Beispiele 3a-3c und/oder eines oder mehrerer anderer vorliegender Beispiele, wobei die DCROM-Informationen ferner Folgendes beinhalten: Belegungswerte, die die Belegung jeder Zelle in dem Gitter darstellen; und Konfidenzwerte, die jeder Zelle in dem Gitter entsprechen.
  • Beispiel 5 beinhaltet das Verfahren nach Beispiel 4 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die DCROM-Informationen ferner eine Bitmap der Belegungswerte beinhalten und die Konfidenzwerte mit der Bitmap assoziiert werden.
  • Beispiel 6 beinhaltet das Verfahren nach Beispiel 1-5 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die VAM eine erste VAM ist und das Verfahren ferner Folgendes umfasst: Empfangen einer zweiten VAM von zumindest einer ersten ITS-S des Satzes von ITS-Ss, wobei die erste ITS-S eine VRU-ITS-S ist.
  • Beispiel 7 beinhaltet das Verfahren nach Beispiel 6 und/oder einem oder mehreren anderen vorliegenden Beispielen, ferner umfassend: Empfangen einer dritten VAM oder einer dezentralen Umgebungsbenachrichtigungsnachricht (DENM, Decentralized Environmental Notification Message) von zumindest einer zweiten ITS-S des Satzes von ITS-Ss, wobei die zweite ITS-S eine VRU-ITS-S oder eine Nicht-VRU-ITS-S ist
  • Beispiel 8 beinhaltet das Verfahren nach Beispiel 7 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei: die erste VAM ein Belegungsstatusindikator- (OSI-, Occupancy Status Indicator) Datenfeld (DF) mit einem ersten OSI-Wert und ein Gitterstandortindikator- (GLI-, Grid Location Indicator) Feld mit einem ersten GLI-Wert beinhaltet, die zweite VAM ein OSI-Feld mit einem zweiten OSI-Wert und ein GLI-Feld mit einem zweiten GLI-Wert beinhaltet und die dritte VAM oder die DENM ein OSI-Feld mit einem dritten OSI-Wert und ein GLI-Feld mit einem dritten GLI-Wert beinhaltet.
  • Beispiel 9 beinhaltet das Verfahren nach Beispiel 8 und/oder einem oder mehreren anderen vorliegenden Beispielen, ferner umfassend: Aktualisieren der DCROM basierend auf den zweiten OSI- und GLI-Werten oder den dritten OSI- und GLI-Werten.
  • Beispiel 10 beinhaltet das Verfahren der Beispiele 8-9 und/oder einiger anderer vorliegender Beispiele, wobei: der erste GLI-Wert Zellen um eine erste Referenzzelle der Vielzahl von Zellen herum angibt, wobei die erste Referenzzelle eine Zelle in der DCROM ist, die durch die Ursprungs-ITS-S belegt ist, der zweite GLI-Wert relative Zellen um eine zweite Referenzzelle herum angibt, die zweite Referenzzelle eine Zelle in der DCROM ist, die durch die erste ITS-S belegt ist, und der dritte GLI-Wert relative Zellen um eine dritte Referenzzelle herum angibt, wobei die dritte Referenzzelle eine Zelle in der DCROM ist, die durch die zweite ITS-S belegt ist.
  • Beispiel 11 umfasst das Verfahren nach Beispiel 10 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei: der erste OSI-Wert ein probabilistischer Indikator ist, der eine geschätzte Unsicherheit benachbarter Zellen um die Ursprungs-ITS-S herum anzeigt, der zweite OSI-Wert ein probabilistischer Indikator ist, der eine geschätzte Unsicherheit benachbarter Zellen um die erste ITS-S herum anzeigt, und der dritte OSI-Wert ein probabilistischer Indikator ist, der eine geschätzte Unsicherheit benachbarter Zellen um die zweite ITS-S herum anzeigt.
  • Beispiel 12 beinhaltet das Verfahren nach Beispiel 1-11 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die gesammelten Sensordaten Sensordaten beinhalten, die von Sensoren der Ursprungs-ITS-S gesammelt werden.
  • Beispiel 13 beinhaltet das Verfahren nach Beispiel 1-12 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die Sensordaten eine Ego-VRU-Kennung (ID) und/oder Positionsdaten und/oder Profildaten und/oder Geschwindigkeitsdaten und/oder Richtungsdaten und/oder Orientierungsdaten und/oder Trajektoriedaten und/oder Geschwindigkeitsvektordaten und/oder andere Sensordaten beinhalten.
  • Beispiel 14 beinhaltet das Verfahren nach Beispiel 1-13 und/oder einem oder mehreren anderen vorliegenden Beispielen, ferner umfassend: Durchführen einer Kollisionsrisikoanalyse (CRA, Collision Risk Analysis) basierend auf den Belegungswerten jeweiliger Zellen in der DCROM, wobei die CRA Folgendes beinhaltet: Durchführen von Trajektorienabfangwahrscheinlichkeits- (TIP-, Trajectory Interception Probability) Berechnungen; oder Durchführen einer TCC- (Time To Collision, Zeit bis Kollision) Berechnung.
  • Beispiel 15 beinhaltet das Verfahren nach Beispiel 14 und/oder einem oder mehreren anderen vorliegenden Beispielen, ferner umfassend: Bestimmen einer Kollisionsvermeidungsstrategie basierend auf der CRA; Auslösen einer Kollisionsrisikovermeidung basierend auf der Kollisionsvermeidungsstrategie; und Auslösen eines Manöverkoordinationsdienstes (MCS, Maneuver Coordination Service) zum Ausführen von Kollisionsvermeidungsaktionen der Kollisionsvermeidungsstrategie.
  • Beispiel 16 beinhaltet das Verfahren nach Beispiel 15 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die CRA Durchführen der TIP-Berechnungen beinhaltet und das Verfahren ferner Folgendes umfasst: Erzeugen einer weiteren VAM mit einem Trajektorieabfangindikator (TII, Trajectory Interception Indicator) und einer Manöverkennung (MI, Maneuver Identifier), wobei der TII widerspiegelt, wie wahrscheinlich eine Trajektorie der Ursprungs-ITS-S von einer oder mehreren benachbarten ITSs abgefangen werden wird, und die MI einen Manövertyp angibt, der von den Kollisionsvermeidungsaktionen erforderlich ist; und Übertragen oder Rundsenden der weiteren VAM
  • Beispiel 17 beinhaltet das Verfahren nach Beispiel 3a-16 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die DCROM eine geschichtete Kostenkarte ist, die eine Master-Kostenkarte und eine Vielzahl von Schichten beinhaltet.
  • Beispiel 18 beinhaltet das Verfahren nach Beispiel 17 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei das Erzeugen der DCROM Folgendes umfasst: auf jeder Schicht der Vielzahl von Schichten erfolgendes Verfolgen von Daten bezüglich einer spezifischen Funktionalität oder eines spezifischen Sensortyps; und Akkumulieren der Daten aus jeder Schicht in die Master-Kostenkarte, wobei die Master-Kostenkarte die DCROM ist.
  • Beispiel 19 beinhaltet das Verfahren nach Beispiel 18 und/oder einem oder mehreren anderen Beispielen, wobei die Vielzahl von Schichten eine statische Kartenschicht beinhaltet, die eine statische Karte eines oder mehrerer statischer Objekte in dem durch die DCROM abgedeckten Bereich beinhaltet.
  • Beispiel 20 beinhaltet das Verfahren nach Beispiel 19 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei das Erzeugen der DCROM Folgendes umfasst: Erzeugen der statischen Karte unter Verwendung eines SLAM- (Simultaneous Localization and Mapping, simultane Lokalisierung und Abbildung) Algorithmus; oder Erzeugen der statischen Karte aus einem Architekturdiagramm.
  • Beispiel 21 beinhaltet das Verfahren nach Beispiel 18-20 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die Vielzahl von Schichten ferner eine Hindernisschicht beinhaltet, die eine Hindernisschicht-Belegungskarte mit Sensordaten in Zellen der Vielzahl von Zellen mit detektierten Objekten gemäß den Sensordaten beinhaltet.
  • Beispiel 22 beinhaltet das Verfahren nach Beispiel 21 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei das Erzeugen der DCROM Folgendes umfasst: Erzeugen der Hindernisschicht-Belegungskarte durch Überschreiben der statischen Karte mit den gesammelten Sensordaten.
  • Beispiel 23 beinhaltet das Verfahren nach Beispiel 18-22 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die Vielzahl von Schichten ferner eine Proxemikschicht beinhaltet, die eine Proxemikschicht-Belegungskarte mit detektierten VRUs und einem die detektierten VRUs umgebenden Raum in Zellen der Vielzahl von Zellen mit detektierten Objekten gemäß den Sensordaten beinhaltet.
  • Beispiel 24 beinhaltet das Verfahren nach Beispiel 23 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die Vielzahl von Schichten ferner eine Aufweitungsschicht beinhaltet, die eine Aufweitungsschicht-Belegungskarte mit jeweiligen Pufferzonen um detektierte Objekte herum beinhaltet, die als fatale Objekte bestimmt werden.
  • Beispiel 25 beinhaltet das Verfahren nach Beispiel 7-24 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei: die Ursprungs-ITS-S eine VRU-ITS-S mit geringer Komplexität (LC, Low Complexity) oder eine VRU-ITS-S mit hoher Komplexität (HC, High Complexity) ist, die erste ITS-S eine LC-VRU-ITS-S oder eine HC-VRU-ITS-S ist und die zweite ITS-S eine HC-VRU-ITS-S, eine Fahrzeug-ITS-S oder eine Straßenrand-ITS-S ist.
  • Beispiel Z01 beinhaltet ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei die Ausführung der Anweisungen durch eine Prozessorschaltungsanordnung bewirken soll, dass die Prozessorschaltungsanordnung das Verfahren nach einem der Beispiele 1-25 und/oder einem oder mehreren anderen vorliegenden Beispielen durchführt. Beispiel Z02 beinhaltet ein Computerprogramm, das die Anweisungen nach Beispiel Z01 umfasst. Beispiel Z03a beinhaltet eine Anwendungsprogrammierschnittstelle, die Funktionen, Verfahren, Variablen, Datenstrukturen und/oder Protokolle für das Computerprogramm nach Beispiel Z02 definiert.
  • Beispiel Z03b beinhaltet eine API oder Spezifikation, die Funktionen, Verfahren, Variablen, Datenstrukturen, Protokolle usw. definiert, die die Verwendung eines beliebigen der Beispiele 1-25 oder von Teilen davon definieren oder beinhalten oder anderweitig mit einem beliebigen der Beispiele 1-25 oder Teilen davon in Zusammenhang stehen. Beispiel Z04 beinhaltet eine Einrichtung, die eine Schaltungsanordnung umfasst, die mit den Anweisungen nach Beispiel Z01 geladen ist. Beispiel Z05 beinhaltet eine Einrichtung, die eine Schaltungsanordnung umfasst, die betreibbar ist, um die Anweisungen nach Beispiel Z01 auszuführen. Beispiel Z06 beinhaltet eine integrierte Schaltung, die die Prozessorschaltungsanordnung nach Beispiel Z01 und/oder das eine oder die mehreren computerlesbaren Medien nach Beispiel Z01 umfasst. Beispiel Z07 beinhaltet ein Rechensystem, das das eine oder die mehreren computerlesbaren Medien und die Prozessorschaltungsanordnung nach Beispiel Z01 umfasst.
  • Beispiel Z08 beinhaltet eine Einrichtung, die Mittel zum Ausführen der Anweisungen nach Beispiel Z01 umfasst. Beispiel Z09 beinhaltet ein Signal, das als Ergebnis des Ausführens der Anweisungen nach Beispiel Z01 erzeugt wird. Beispiel Z10 beinhaltet eine Dateneinheit, die als Ergebnis des Ausführens der Anweisungen nach Beispiel Z01 erzeugt wird. Beispiel Z 11 beinhaltet die Dateneinheit nach Beispiel Z10 und/oder einem oder mehreren anderen vorliegenden Beispielen, wobei die Dateneinheit ein Datagramm, ein Netzwerkpaket, ein Datenrahmen, ein Datensegment, eine Protokolldateneinheit (PDU, Protocol Data Unit), eine Dienstdateneinheit (SDU, Service Data Unit), eine Nachricht oder ein Datenbankobjekt ist.
  • Beispiel Z12 beinhaltet ein Signal, das mit der Dateneinheit nach Beispiel Z10 und/oder Z11 codiert ist. Beispiel Z 13 beinhaltet ein elektromagnetisches Signal, das die Anweisungen nach Beispiel Z01 trägt. Beispiel Z14 beinhaltet eine Einrichtung, die Mittel zum Durchführen des Verfahrens nach einem der Beispiele 1-25 und/oder einem oder mehreren anderen vorliegenden Beispielen umfasst. Beispiel Z15 beinhaltet einen MEC- (Multi-access Edge Computing, Multizugriff-Edge-Computing-) Host, der einen Dienst als Teil einer oder mehrerer MEC-Anwendungen ausführt, die auf einer Virtualisierungsinfrastruktur instanziiert sind, wobei sich der Dienst auf beliebige der Beispiele 1-25 oder Teile davon und/oder ein oder mehrere andere vorliegende Beispiele bezieht, und wobei der MEC-Host zum Arbeiten gemäß einem Standard aus einer oder mehreren ETSI-MEC-Standardfamilien konfigurierbar oder betreibbar ist.
  • Ein beliebiges der oben beschriebenen Beispiele kann mit einem beliebigen anderen Beispiel (oder einer beliebigen Kombination von Beispielen) kombiniert werden, sofern nicht explizit anders angegeben. Die Implementierung der vorhergehenden Techniken kann durch eine beliebige Anzahl von Spezifikationen, Konfigurationen oder Einsatzbeispiele von Hardware und Software erreicht werden. Es versteht sich, dass die in dieser Beschreibung beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder gekennzeichnet worden sein können, um ihre Implementierungsunabhängigkeit genauer hervorzuheben. Derartige Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen realisiert werden. Zum Beispiel kann eine Komponente oder ein Modul als eine Hardwareschaltung umgesetzt sein, die angepasste VLSI- (Very-Large-Scale-Integration, Größtintegrations-) Schaltungen oder Gate-Arrays, handelsübliche Halbleiter wie etwa Logikchips, Transistoren oder andere diskrete Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert werden, wie etwa frei programmierbaren Gate-Arrays, programmierbarer Arraylogik, programmierbaren Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert sein. Eine identifizierte Komponente oder ein identifiziertes Modul von ausführbaren Codes kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Elemente einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen angeordnet sein, sondern können heterogene Anweisungen umfassen, die an unterschiedlichen Orten gespeichert sind, die, wenn sie logisch miteinander verbunden werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erfüllen.
  • Tatsächlich kann eine Komponente oder ein Modul eines ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere unterschiedliche Codesegmente, unter verschiedenen Programmen und über mehrere Speichervorrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können manche Aspekte des beschriebenen Prozesses (wie etwa Codeumschreiben und Codeanalyse) auf einem anderen Verarbeitungssystem (z. B. in einem Computer in einem Datenzentrum) als jenem stattfinden, in dem der Code eingesetzt wird (z. B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Auf ähnliche Weise können Betriebsdaten vorliegend innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht werden und können in einer beliebigen geeigneten Form ausgeführt und in einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz gesammelt werden oder über verschiedene Orte, einschließlich verschiedener Speichervorrichtungen, verteilt sein und zumindest teilweise lediglich als elektronische Signale in einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein und Agenten umfassen, die betrieben werden können, um gewünschte Funktionen auszuführen.
  • 6. TERMINOLOGIE
  • Die hierin verwendete Terminologie dient nur dem Zweck des Beschreibens von speziellen Ausführungsbeispielen und ist nicht als Einschränkung der Offenbarung beabsichtigt. Die vorliegende Offenbarung wird unter Bezugnahme auf Veranschaulichungen von Flussdiagrammen und/oder Blockdiagrammen von Verfahren, Einrichtungen (Systemen) und Computerprogrammprodukten gemäß Ausführungsformen der vorliegenden Offenbarung beschrieben. In den Zeichnungen können einige Struktur- oder Verfahrensmerkmale in spezifischen Anordnungen und/oder Reihenfolgen gezeigt sein. Es versteht sich jedoch, dass solche spezifischen Anordnungen und/oder Ordnungen möglicherweise nicht erforderlich sind. Vielmehr können solche Merkmale bei einigen Ausführungsformen auf eine andere Weise und/oder Reihenfolge als in den illustrativen Figuren gezeigt angeordnet sein. Zusätzlich bedeutet das Einschließen eines Struktur- oder Verfahrensmerkmals in einer speziellen Figur nicht, dass ein derartiges Merkmal in allen Ausführungsformen erforderlich ist, und in einigen Ausführungsformen ist es möglicherweise nicht enthalten oder mit anderen Merkmalen kombiniert.
  • So wie sie hierin verwendet werden, sollen die Singularformen „ein“, „eine“ und „der/die/das“ auch Pluralformen umfassen, es sei denn, dass der Zusammenhang eindeutig etwas anderes angibt. Es versteht sich ferner, dass die Begriffe „umfasst“ und/oder „umfassend“, wenn in dieser Patentschrift verwendet, das Vorhandensein aufgeführter Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente und/oder Komponenten spezifiziert, aber nicht das Vorhandensein oder das Hinzufügen eines oder mehrerer anderer Merkmale, ganzer Zahlen, Schritte, Operationen, Elemente, Komponenten und/oder Gruppen davon ausschließt. Der Ausdruck „A und/oder B“ bedeutet (A), (B) oder (A und B). Für die Zwecke der vorliegenden Offenbarung bedeutet die Formulierung „A, B und/oder C“ (A), (B), (C), (A und B), (A und C), (B und C) oder (A, B und C). Die Beschreibung kann die Ausdrücke „in einer Ausführungsform“ oder „in einigen Ausführungsformen“ verwenden, die sich jeweils auf eine oder mehrere der gleichen oder unterschiedlichen Ausführungsformen beziehen können. Weiterhin sind die Ausdrücke „umfassend“, „beinhaltend“, „aufweisend“ und dergleichen, wie sie mit Bezug auf Ausführungsformen der vorliegenden Offenbarung verwendet werden, synonym.
  • Die Begriffe „gekoppelt“, „kommunikativ gekoppelt“ werden, zusammen mit Ableitungen davon, hierin verwendet. Der Begriff „gekoppelt“ kann bedeuten, dass sich zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt miteinander befinden, kann bedeuten, dass sich zwei oder mehr Elemente indirekt berühren, aber immer noch miteinander zusammenwirken oder interagieren, und/oder kann bedeuten, dass ein oder mehrere andere Elemente zwischen den Elementen gekoppelt oder verbunden sind, die als miteinander gekoppelt bezeichnet werden. Der Begriff „direkt gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem Kontakt miteinander stehen. Der Begriff „kommunikativ gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente durch ein Kommunikationsmittel, einschließlich über einen Draht oder eine andere Zusammenschaltungsverbindung, über einen Drahtloskommunikationskanal oder -Link und/oder dergleichen, miteinander in Kontakt stehen können.
  • Der Begriff „Schaltungsanordnung“ bezieht sich auf eine Schaltung oder ein System mehrerer Schaltungen, die bzw. das dazu konfiguriert ist, eine spezielle Funktion in einer elektronischen Vorrichtung durchzuführen. Die Schaltung oder das System von Schaltungen kann Teil einer oder mehrerer Hardwarekomponenten sein oder diese umfassen, wie etwa eine Logikschaltung, ein Prozessor (gemeinsam genutzt, dediziert oder Gruppe) und/oder ein Speicher (gemeinsam genutzt, dediziert oder als Gruppe), eine ASIC, ein FPGA, eine programmierbare Logiksteuerung (PLC), ein SoC, ein SiP, ein Mehrchipgehäuse (MCP), einen DSP usw., die dazu konfiguriert sind, die beschriebene Funktionalität bereitzustellen Außerdem kann der Begriff „Schaltungsanordnung“ auf eine Kombination eines oder mehrerer Hardwareelemente mit dem Programmcode verweisen, der zum Ausführen der Funktionalität dieses Programmcodes verwendet wird. Einige Arten von Schaltungsanordnungen können ein oder mehrere Software- oder Firmware-Programme ausführen, um wenigstens einen Teil der beschriebenen Funktionalität bereitzustellen. Eine solche Kombination von Hardwareelementen und Programmcode kann als ein bestimmter Typ von Schaltungsanordnung bezeichnet werden.
  • Es versteht sich, dass die in dieser Beschreibung beschriebenen Funktionseinheiten oder Fähigkeiten als Komponenten oder Module bezeichnet oder beschriftet worden sein können, um ihre Implementierungsunabhängigkeit genauer hervorzuheben. Derartige Komponenten können durch eine beliebige Anzahl von Software- oder Hardwareformen realisiert werden. Eine Komponente oder ein Modul kann zum Beispiel als eine Hardware-Schaltung implementiert werden, die kundenspezifische Very-Large-Scale-Integration- (VLSI-) Schaltungen oder Gate-Arrays, handelsübliche Halbleiter wie Logikchips, Transistoren oder andere diskrete Komponenten umfasst. Eine Komponente oder ein Modul kann auch in programmierbaren Hardwarevorrichtungen implementiert werden, wie etwa feldprogrammierbaren Gate-Arrays, programmierbarer Arraylogik, programmierbaren Logikvorrichtungen oder dergleichen. Komponenten oder Module können auch in Software zur Ausführung durch verschiedene Arten von Prozessoren implementiert sein. Eine identifizierte Komponente oder ein identifiziertes Modul von ausführbaren Codes kann beispielsweise einen oder mehrere physische oder logische Blöcke von Computeranweisungen umfassen, die beispielsweise als ein Objekt, eine Prozedur oder eine Funktion organisiert sein können. Nichtsdestotrotz müssen die ausführbaren Dateien einer identifizierten Komponente oder eines identifizierten Moduls nicht physisch zusammen angeordnet sein, sondern können getrennte Befehle umfassen, die an verschiedenen Orten gespeichert sind, die, wenn sie logisch zusammengefügt werden, die Komponente oder das Modul umfassen und den angegebenen Zweck für die Komponente oder das Modul erreichen.
  • Tatsächlich kann eine Komponente oder ein Modul eines ausführbaren Codes eine einzige Anweisung oder viele Anweisungen sein und kann sogar über mehrere unterschiedliche Codesegmente, unter verschiedenen Programmen und über mehrere Speichervorrichtungen oder Verarbeitungssysteme hinweg verteilt sein. Insbesondere können einige Aspekte des beschriebenen Prozesses (wie etwa ein Codeumschreiben und eine Codeanalyse) auf einem anderen Verarbeitungssystem (z.B. in einem Computer in einem Rechenzentrum) als dem stattfinden, in dem der Code eingesetzt wird (z.B. in einem Computer, der in einen Sensor oder Roboter eingebettet ist). Gleichermaßen können Betriebsdaten vorliegend innerhalb von Komponenten oder Modulen identifiziert und veranschaulicht werden und können in einer beliebigen geeigneten Form umgesetzt und innerhalb einer beliebigen geeigneten Art von Datenstruktur organisiert sein. Die Betriebsdaten können als ein einziger Datensatz erfasst werden oder können über verschiedene Orte, einschließlich über verschiedene Speicherungsvorrichtungen, verteilt werden und können zumindest teilweise lediglich als elektronische Signale in einem System oder Netzwerk existieren. Die Komponenten oder Module können passiv oder aktiv sein und Agenten umfassen, die betrieben werden können, um gewünschte Funktionen auszuführen.
  • Der Begriff „Prozessorschaltungsanordnung“, wie hierin verwendet, bezieht sich auf eine Schaltungsanordnung, die zum sequenziellen und automatischen Ausführen einer Sequenz arithmetischer oder logischer Operationen oder zum Aufzeichnen, Speichern und/oder Transfer digitaler Daten in der Lage ist, ist Teil davon oder beinhaltet eine solche. Der Begriff „Prozessorschaltung“ kann sich auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische CPU, einen Einkernprozessor, einen Doppelkernprozessor, einen Dreikernprozessor, einen Vierkernprozessor und/oder eine beliebige andere Vorrichtung beziehen, die in der Lage ist, computerausführbare Anweisungen, wie etwa Programmcode, Softwaremodule und/oder Funktionsprozesse, auszuführen oder anderweitig zu betreiben. Die Begriffe „Anwendungsschaltungsanordnung“ und/oder „Basisbandschaltungsanordnung“ können als synonym zu „Prozessorschaltungsanordnung“ angesehen werden und können als solche bezeichnet werden.
  • Der Begriff „Speicher“ und/oder „Speicherschaltungsanordnung“, wie hier verwendet, bezieht sich auf eine oder mehrere Hardwarevorrichtungen zum Speichern von Daten, einschließlich RAM, MRAM, PRAM, DRAM und/oder SDRAM, Kernspeicher, ROM, Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen oder andere maschinenlesbare Medien zum Speichern von Daten. Der Begriff „computerlesbares Medium“ kann unter anderem Speicher, portable oder feste Speicherungsvorrichtungen, optische Speicherungsvorrichtungen und verschiedene andere Medien beinhalten, die dazu in der Lage sind, Anweisungen oder Daten zu speichern, zu halten oder zu tragen.
  • Der Begriff „Schnittstellenschaltungsanordnung“, wie hierin verwendet, bezieht sich auf eine Schaltungsanordnung, die den Austausch von Informationen zwischen zwei oder mehr Komponenten oder Vorrichtungen ermöglicht, ist Teil davon oder beinhaltet eine solche. Der Begriff „Schnittstellenschaltungsanordnung“ kann sich auf eine oder mehrere Hardwareschnittstellen beziehen, zum Beispiel Busse, E/A-Schnittstellen, Peripheriekomponentenschnittstellen, Netzwerkschnittstellenkarten und/oder dergleichen.
  • Der Begriff „Element“ bezieht sich auf eine Einheit, die auf einem gegebenen Abstraktionsniveau unteilbar ist und eine klar definierte Grenze aufweist, wobei ein Element eine beliebige Art von Entität sein kann, die zum Beispiel eine oder mehrere Vorrichtungen, Systeme, Steuerungen, Netzwerkelemente, Module usw. oder Kombinationen davon beinhaltet. Der Begriff „Vorrichtung“ bezieht sich auf eine physische Entität, die innerhalb einer anderen physischen Entität in ihrer Nähe eingebettet oder an dieser angebracht ist, mit Fähigkeiten zum Übermitteln von digitalen Informationen von oder zu dieser physischen Entität. Der Begriff „Entität“ bezieht sich auf eine individuelle Komponente einer Architektur oder Vorrichtung oder als Nutzlast übertragene Informationen. Der Begriff „Steuerung“ bezieht sich auf ein Element oder eine Entität, das/die die Fähigkeit aufweist, eine physische Entität zu beeinflussen, wie etwa durch Ändern ihres Zustands oder Bewirken, dass sich die physische Entität bewegt.
  • Wie hier verwendet, umfasst der Begriff „Edge-Computing“ viele Implementierungen verteilten Rechnens, die Verarbeitungsaktivitäten und -ressourcen (z.B. Rechen-, Speicher-, Beschleunigungsressourcen) in Richtung des „Edge“ des Netzwerks bewegen, im Bemühen, die Latenz zu reduzieren und den Durchsatz für Endpunktbenutzer (Client-Vorrichtungen, Benutzergerät usw.) zu erhöhen. Solche Edge-Computing-Implementierungen beinhalten typischerweise das Anbieten solcher Aktivitäten und Ressourcen in Cloud-ähnlichen Diensten, Funktionen, Anwendungen und Subsystemen von einem oder mehreren Standorten, auf die über drahtlose Netzwerke zugegriffen werden kann. Somit sind die Verweise auf ein „Edge“ eines Netzwerks, Clusters, einer Domäne, eines Systems oder einer Rechenanordnung, die hier verwendet werden, Gruppen oder Gruppierungen funktioneller verteilter Rechenelemente und stehen daher allgemein nicht in Beziehung zu „Kanten“ (Links oder Verbindungen), wie sie in der Graphentheorie verwendet werden. Bestimmte Anordnungen von Edge-Rechenanwendungen und Diensten, die über mobile Drahtlosnetzwerke (z. B. Mobilfunk- und WiFi-Datennetze) zugänglich sind, können als „mobiles Edge-Computing“ oder „Mehrfahrzugriffs-Edge-Computing“ bezeichnet werden, was durch das Akronym „MEC“ referenziert werden kann. Die Verwendung von „MEC“ kann sich vorliegend auch auf eine standardisierte Implementierung beziehen, die vom Europäischen Institut für Telekommunikationsnormen (ETSI) verbreitet wird und als „ETSI-MEC“ bezeichnet wird. Terminologie, die durch die ETSI-MEC-Spezifikation verwendet wird, wird vorliegend allgemein durch Bezugnahme aufgenommen, es sei denn, eine widersprüchliche Definition oder Verwendung wird vorliegend bereitgestellt.
  • Wie hier verwendet, bezieht sich der Begriff „Rechenknoten“ oder „Rechenvorrichtung“ auf eine identifizierbare Entität, die einen Aspekt von Edge-Rechenoperationen implementiert, sei es Teil eines größeren Systems, einer verteilten Sammlung von Systemen oder einer eigenständigen Einrichtung. In einigen Beispielen kann ein Rechenknoten als ein „Edge-Knoten“, eine „Edge-Vorrichtung“, ein „Edge-System“ bezeichnet werden, sei es im Betrieb als ein Client, Server oder eine Zwischenentität. Spezifische Implementierungen eines Rechenknotens können in einen Server, eine Basisstation, ein Gateway, eine Straßenrandinheit, eine Vor-Ort-Einheit, einer UE oder eine Endverbrauchervorrichtung oder dergleichen integriert sein.
  • Der Begriff „Computersystem“, wie hierin verwendet, bezieht sich auf eine beliebige Art von zusammengeschalteten elektronischen Vorrichtungen, Computervorrichtungen oder Komponenten davon. Außerdem kann sich der Begriff „Computersystem“ und/oder „System“ auf verschiedene Komponenten eines Computers beziehen, die kommunikativ miteinander gekoppelt sind. Des Weiteren kann sich der Begriff „Computersystem“ und/oder „System“ auf mehrere Computervorrichtungen und/oder mehrere Rechensysteme beziehen, die kommunikativ miteinander gekoppelt und dazu ausgelegt sind, Rechen- und/oder Vernetzungsressourcen gemeinsam zu nutzen.
  • Der Begriff „Architektur“, wie hier verwendet, bezieht sich auf eine Computerarchitektur oder eine Netzwerkarchitektur. Eine „Netzwerkarchitektur“ ist eine physische und logische Gestaltung oder Anordnung von Software- und/oder Hardwareelementen in einem Netzwerk einschließlich Kommunikationsprotokollen, Schnittstellen und Medienübertragung. Eine „Computerarchitektur“ ist eine physische und logische Gestaltung oder Anordnung von Software- und/oder Hardwareelementen in einem Rechensystem oder einer Rechenplattform einschließlich Technologiestandards für Interaktionen dazwischen.
  • Der Begriff „Gerät“, „Computergerät“ oder dergleichen, wie hierin verwendet, bezieht sich auf eine Computervorrichtung oder ein Computersystem mit Programmcode (z.B. Software oder Firmware), die speziell zum Bereitstellen einer spezifischen Rechenressource konzipiert ist. Ein „virtuelles Gerät“ ist ein virtuelles Maschinenabbild, das durch eine mit einem Hypervisor ausgestattete Vorrichtung zu implementieren ist, die ein Computergerät virtualisiert oder emuliert oder anderweitig dazu dediziert ist, eine spezifische Rechenressource bereitzustellen.
  • Der Begriff „Benutzergerät“ oder „UE“, wie hierin verwendet, bezieht sich auf eine Vorrichtung mit Funkkommunikationsfähigkeiten und kann einen entfernten Benutzer von Netzwerkressourcen in einem Kommunikationsnetzwerk beschreiben. Der Begriff „Benutzergerät“ oder „UE“ kann als Synonym für Client, Mobilteil, Mobilvorrichtung, Mobilendgerät, Benutzerendgerät, Mobileinheit, Station, Mobilstation, Mobilbenutzer, Teilnehmer, Benutzer, entfernte Station, Zugangsagent, Benutzeragent, Empfänger, Funkgerät, rekonfigurierbares Funkgerät, rekonfigurierbare Mobilvorrichtung usw. angesehen und als solche bezeichnet werden. Des Weiteren kann der Begriff „Benutzergerät“ oder „UE“ eine beliebige Art von drahtloser/drahtgebundener Vorrichtung oder eine beliebige Rechenvorrichtung mit einer Drahtloskommunikationsschnittstelle beinhalten. Der Begriff „Station“ oder „STA“ bezieht sich auf eine logische Entität, die eine einzeln adressierbare Instanz einer Schnittstelle einer Medienzugangssteuerungs (MAC)-Schicht und einer physikalischen Schicht (PHY) zu dem drahtlosen Medium (WM) ist. Der Begriff „drahtloses Medium“ oder „WM“ bezieht sich auf das Medium, das verwendet wird, um die Übertragung von Protokolldateneinheiten (PDUs) zwischen gleichrangigen Entitäten der physikalischen Schicht (PHY) eines lokalen Drahtlosnetzwerks (LAN) zu implementieren.
  • Der Begriff „Netzwerkelement“, wie hierin verwendet, bezieht sich auf ein physisches oder virtualisiertes Gerät und/oder eine physische oder virtualisierte Infrastruktur, die zum Bereitstellen von drahtgebundenen oder Drahtloskommunikationsnetzwerkdiensten verwendet werden. Der Begriff „Netzwerkelement“ kann als Synonym für einen vernetzten Computer, eine Netzwerk-Hardware, ein Netzwerkgerät, einen Netzwerkknoten, einen Router, einen Switch, einen Hub, eine Bridge, eine Funknetzwerksteuerung, eine RAN-Vorrichtung, einen RAN-Knoten, ein Gateway, einen Server, eine virtualisierte VNF, eine NFVI und/oder dergleichen angesehen und/oder als solche bezeichnet werden.
  • Wie hier verwendet, bezieht sich der Begriff „Zugangspunkt“ oder „AP“ auf eine Entität, die eine Station (STA) enthält und über das drahtlose Medium (WM) Zugang für assoziierte STAs zu den Verteilungsdiensten bereitstellt. Ein AP umfasst eine STA und eine Verteilsystemzugangsfunktion (DSAF). Wie hier verwendet, bezieht sich der Begriff „Basisstation“ auf ein Netzwerkelement in einem Funkzugangsnetzwerk (RAN - radio access network), wie etwa einem Mobilkommunikationsnetz der vierten Generation (4G) oder der fünften Generation (5G), das für die Übertragung und den Empfang von Funksignalen in einer oder mehreren Zellen zu oder von einem Benutzergerät (UE) verantwortlich ist. Eine Basisstation kann eine integrierte Antenne aufweisen oder über Feeder-Kabel mit einem Antennenarray verbunden sein. Eine Basisstation verwendet spezialisierte digitale Signalverarbeitung und Netzwerkfunktionshardware. In einigen Beispielen kann die Basisstation für Flexibilität, Kosten und Leistungsfähigkeit in mehrere Funktionsblöcke aufgeteilt sein, die in Software arbeiten. In einigen Beispielen kann eine Basisstation einen evolvierten NodeB (eNB) oder einen NodeB der nächsten Generation (gNB) umfassen. Bei manchen Beispielen kann die Basisstation Rechenhardware betreiben oder beinhalten, um als ein Rechenknoten zu arbeiten. In vielen der hier erörterten Szenarien kann jedoch eine RAN-Basisstation durch einen Zugangspunkt (z.B. einen Drahtlosnetzwerkzugangspunkt) oder eine andere Netzwerkzugangshardware ersetzt werden.
  • Wie hier verwendet, gibt der Begriff „Zentrale“ (oder CO - central office) einen Aggregationspunkt für eine Telekommunikationsinfrastruktur innerhalb eines zugänglichen oder definierten geografischen Gebiets an, wo Telekommunikationsdienstanbieter traditionell Vermittlungseinrichtungen für einen oder mehrere Typen von Zugangsnetzen angeordnet haben. Die CO kann physisch so ausgestaltet sein, dass sie Telekommunikationsinfrastrukturausrüstung oder Rechen-, Datenspeicherungs- und Netzwerkressourcen beherbergt. Die CO muss jedoch kein designierter Ort eines Telekommunikationsdienstleisters sein. Die CO kann eine beliebige Anzahl von Rechenvorrichtungen für Edge-Anwendungen und -Dienste oder sogar lokale Implementierungen von Cloud-ähnlichen Diensten hosten.
  • Der Begriff „Cloud-Computing“ oder „Cloud“ bezieht sich auf ein Paradigma zum Ermöglichen von Netzwerkzugang zu einem skalierbaren und elastischen Pool von gemeinsam nutzbaren Rechenressourcen mit Self-Service-Bereitstellung und -Verwaltung bei Bedarf und ohne aktives Management durch Benutzer. Cloud-Computing stellt Cloud-Computing-Dienste (oder Cloud-Dienste) bereit, bei denen es sich um eine oder mehrere über Cloud-Computing angebotene Fähigkeiten handelt, die unter Verwendung einer definierten Schnittstelle (e.g., einer API oder dergleichen) aufgerufen werden. Der Begriff „Rechenressource“ oder einfach „Ressource“ bezieht sich auf eine beliebige physische oder virtuelle Komponente oder Nutzung solcher Komponenten mit eingeschränkter Verfügbarkeit innerhalb eines Computersystems oder Netzwerks. Beispiele für Ressourcen umfassen Nutzung von/Zugang zu Servern, Prozessor(en), Speichergeräten, Speichervorrichtungen, Speicherbereichen, Netzwerken, elektrischer Leistung, (periphere) Eingabe-/Ausgabevorrichtungen, mechanischen Vorrichtungen, Netzwerkverbindungen (z.B. Kanäle/Links, Ports, Netzwerkbuchsen usw.), Betriebssystemen, virtuellen Maschinen (VMs), Software/Anwendungen, Computerdateien und/oder dergleichen für eine Zeitdauer. Eine „Hardwareressource“ kann sich auf Rechen-, Speicherungs- und/oder Netzwerkressourcen beziehen, die durch ein oder mehrere physische Hardwareelemente bereitgestellt werden. Eine „virtualisierte Ressource“ kann sich auf Rechen-, Speicherungs- und/oder Netzwerkressourcen beziehen, die durch Virtualisierungsinfrastruktur für eine Anwendung, eine Vorrichtung, ein System usw. bereitgestellt werden. Der Begriff „Netzwerkressource“ oder „Kommunikationsressource“ kann sich auf Ressourcen beziehen, auf die Computervorrichtungen/-systeme über ein Kommunikationsnetzwerk zugreifen können. Der Begriff „Systemressourcen“ kann sich auf eine beliebige Art gemeinsam genutzter Entitäten beziehen, um Dienste bereitzustellen, und kann Rechen- und/oder Netzwerkressourcen beinhalten. Systemressourcen können als ein Satz kohärenter Funktionen, Netzwerkdatenobjekte oder Dienste betrachtet werden, auf die durch einen Server zugegriffen werden kann, wobei sich solche Systemressourcen auf einem einzigen Host oder mehreren Hosts befinden und eindeutig identifizierbar sind.
  • Der Begriff „Arbeitslast“ bezieht sich auf eine Menge an Arbeit, die durch ein Datenverarbeitungssystem, eine Vorrichtung, eine Entität usw. während eines Zeitraums oder zu einem speziellen Zeitpunkt durchgeführt wird. Eine Arbeitslast kann als ein Benchmark repräsentiert werden, wie etwa eine Reaktionszeit, ein Durchsatz (z.B. wie viel Arbeit über einen Zeitraum erreicht wird) und/oder dergleichen. Zusätzlich oder alternativ dazu kann die Arbeitslast als eine Speicherarbeitslast (z.B. eine Menge an Speicherplatz, der zur Programmausführung benötigt wird, um temporäre oder permanente Daten zu speichern und Zwischenberechnungen durchzuführen), eine Prozessorarbeitslast (z.B. eine Anzahl an Anweisungen, die von einem Prozessor während einer gegebenen Zeitdauer oder zu einem bestimmten Zeitpunkt ausgeführt werden), eine E/A-Arbeitslast (z.B. eine Anzahl an Ein- und Ausgaben oder Systemzugriffen während einer gegebenen Zeitdauer oder zu einem bestimmten Zeitpunkt), Datenbankarbeitslasten (z.B. eine Anzahl an Datenbankabfragen während einer Zeitdauer), eine netzwerkbezogene Arbeitslast (z.B. eine Anzahl an Netzwerkanhängen, eine Anzahl an Mobilitätsaktualisierungen, eine Anzahl an Funk-Link-Ausfällen, eine Anzahl an Handovers, eine Menge an über eine Luftschnittstelle zu übertragenden Daten usw.) und/oder dergleichen repräsentiert werden. Verschiedene Algorithmen können verwendet werden, um eine Arbeitslast und/oder Arbeitslastcharakteristiken zu bestimmen, die auf einem beliebigen der zuvor genannten Arbeitslasttypen basieren können.
  • Wie hier verwendet, gibt der Begriff „Cloud-Dienstanbieter“ (oder CSP) eine Organisation an, die in der Regel großmaßstäbliche „Cloud“-Ressourcen betreibt, die aus zentralisierten, regionalen und Edge-Rechenzentren (z.B. wie im Kontext der öffentlichen Cloud verwendet) bestehen. In anderen Beispielen kann ein CSP auch als Cloud-Dienstbetreiber (CSO - Cloud Service Operator) bezeichnet werden. Verweise auf „Cloud-Computing“ beziehen sich allgemein auf Rechenressourcen und -dienste, die von einem CSP oder einem CSO an fernen Orten mit wenigstens etwas erhöhter Latenz, Entfernung oder Einschränkungen relativ zu Edge-Computing angeboten werden.
  • Wie hier verwendet, bezieht sich der Begriff „Rechenzentrum“ auf eine zweckentworfene Struktur, die mehrere Hochleistungsrechen- und Datenspeicherknoten beherbergen soll, so dass eine große Menge an Rechen-, Datenspeicher- und Netzwerkressourcen an einem einzigen Ort vorhanden ist. Dabei handelt es sich häufig um spezialisierte Rack- und Gehäusesysteme, geeignete Heiz-, Kühl-, Lüftungs-, Sicherheits-, Brandschutz- und Stromversorgungssysteme. Der Begriff kann in manchen Zusammenhängen auch auf einen Rechen- und Datenspeicherungsknoten verweisen. Ein Datenzentrum kann im Maßstab zwischen einem zentralisierten oder Cloud-Datenzentrum (z.B. größtes), einem regionalen Datenzentrum und einem Edge-Datenzentrum (z.B. kleinstes) variieren.
  • Wie hier verwendet, gibt der Begriff „Zugangs-Edge-Schicht“ die Unterschicht der Infrastruktur-Edge an, die dem Endbenutzer oder der Endvorrichtung am nächsten ist. Eine solche Schicht kann zum Beispiel durch ein Edge-Datenzentrum umgesetzt werden, das an einem zellularen Netzwerkstandort bereitgestellt wird. Die Zugangs-Edge-Schicht fungiert als die vorderste Front des Infrastruktur-Edge und kann mit einer in der Hierarchie höheren Aggregations-Edge-Schicht verbunden sein.
  • Wie hier verwendet, gibt der Begriff „Aggregations-Edge-Schicht“ die Schicht der Infrastruktur-Edge einen Sprung von der Zugangs-Edge-Schicht entfernt an. Diese Schicht kann entweder als ein Datenzentrum mittlerer Größe an einem einzigen Ort existieren oder aus mehreren miteinander verbundenen Mikrodatenzentren gebildet sein, um eine hierarchische Topologie mit der Zugangs-Edge zu bilden, um bessere Zusammenarbeit, Arbeitslastausfallsicherung und Skalierbarkeit als die Zugangs-Edge allein zu ermöglichen.
  • Wie hier verwendet, gibt der Begriff „Netzwerkfunktionsvirtualisierung“ (oder NFV) die Migration von NFs aus eingebetteten Diensten innerhalb proprietärer Hardwaregeräte zu softwarebasierten virtualisierten NFs (oder VNFs) an, die auf standardisierten CPUs (z.B. innerhalb standardmäßiger x86®- und ARM®-Server wie etwa jenen, die Intel® Xeon™- oder AMD® Epyc™- oder Opteron™-Prozessoren umfassen) unter Verwendung von Virtualisierungs- und Cloud-Computing-Technologien nach Industriestandard ausgeführt werden. Bei einigen Aspekten werden die NFV-Verarbeitung und Datenspeicherung an den Edge-Datenzentren, die direkt mit dem lokalen zellularen Standort verbunden sind, innerhalb des Infrastruktur-Edge stattfinden.
  • Wie hier verwendet, bezeichnet der Begriff „virtualisierte NF“ (oder VNF) eine softwarebasierte NF, die auf Multifunktions-Mehrzweck-Rechenressourcen (z.B. x86, ARM-Verarbeitungsarchitektur) arbeitet, die von NFV anstelle von dedizierten physischen Geräten verwendet werden. Bei einigen Aspekten werden mehrere VNFs auf einem Edge-Datenzentrum am Infrastruktur-Edge arbeiten.
  • Wie hierin verwendet, bezieht sich der Begriff „Edge-Computing“ auf die Implementierung, Koordination und Verwendung von Berechnung und Ressourcen an Orten näher am „Rand“ oder einer Sammlung von „Rändern“ eines Netzwerks. Das Einsetzen von Rechenressourcen am Rand des Netzwerks kann Anwendungs- und Netzwerklatenz reduzieren, Netzwerk-Backhaul-Verkehr und assoziierten Energieverbrauch reduzieren, Dienstfähigkeiten verbessern, die Einhaltung von Sicherheits- oder Datenschutzanforderungen verbessern (insbesondere im Vergleich zu herkömmlichem Cloud-Computing) und die Gesamtbetriebskosten verbessern. Wie hier verwendet, bezieht sich der Begriff „Edge-Rechenknoten“ auf eine reale, logische oder virtualisierte Implementierung eines rechenfähigen Elements in Form einer Vorrichtung, eines Gateways, einer Brücke, eines Systems oder eines Subsystems, einer Komponente, ob in einem Server-, Client-, Endpunkt- oder Peer-Modus gearbeitet wird und ob er sich an einem „Rand“ eines Netzwerks oder an einem verbundenen Ort weiter innerhalb des Netzwerks befindet. Bezugnahmen auf einen „Knoten“, die hierin verwendet werden, sind im Allgemeinen mit „Vorrichtung“, „Komponente“ und „Subsystem“ austauschbar; Bezugnahmen auf ein „Edge-Computing-System“ oder „Edge-Computing-Netzwerk“ beziehen sich jedoch im Allgemeinen auf eine verteilte Architektur, Organisation oder Sammlung mehrerer Knoten und Vorrichtungen, die organisiert ist, um einen gewissen Aspekt von Diensten oder Ressourcen in einer Edge-Computing-Umgebung zu erreichen oder anzubieten.
  • Der Begriff „Internet der Dinge“ oder „IoT“ (Internet of Things) bezieht sich auf ein System von miteinander in Beziehung stehenden Rechenvorrichtungen sowie mechanischen und digitalen Maschinen, die in der Lage sind, Daten mit geringer oder keiner menschlichen Interaktion zu übertragen, und kann Technologien, wie etwa Echtzeitanalytik, maschinelles Lernen und/oder AI, eingebettete Systeme, drahtlose Sensornetzwerke, Steuersysteme, Automatisierung (z.B. Technologien für intelligente Heime, intelligente Gebäude und/oder intelligente Städte) und dergleichen umfassen. IoT-Vorrichtungen sind üblicherweise Niedrigleistungsvorrichtungen ohne schwere Rechen- oder Speicherungsfähigkeiten. „Edge-IoT-Vorrichtungen“ können jede Art von IoT-Vorrichtungen sein, die am Rand eines Netzwerks eingesetzt werden.
  • Wie hier verwendet, bezieht sich der Begriff „Cluster“ auf einen Satz oder eine Gruppierung von Entitäten als Teil eines Edge-Rechensystems (oder von Edge-Computing-Systemen) in Form physischer Entitäten (z.B. unterschiedlicher Rechensysteme, Netzwerke oder Netzwerkgruppen), logischer Entitäten (z.B. Anwendungen, Funktionen, Sicherheitskonstrukten, Containern) und dergleichen. An einigen Stellen wird ein „Cluster“ auch als eine „Gruppe“ oder eine „Domäne“ bezeichnet. Die Zugehörigkeit zu einem Cluster kann basierend auf Bedingungen oder Funktionen modifiziert oder beeinflusst werden, einschließlich aus dynamischer oder eigenschaftsbasierter Zugehörigkeit, aus Netzwerk- oder Systemverwaltungsszenarien oder aus verschiedenen unten besprochenen beispielhaften Techniken, die eine Entität in einem Cluster hinzufügen, modifizieren oder entfernen können. Cluster können auch mehrere Schichten, Ebenen oder Eigenschaften, einschließlich Variationen von Sicherheitsmerkmalen und Ergebnissen basierend auf solchen Schichten, Ebenen oder Eigenschaften, beinhalten oder damit assoziiert sein.
  • Wie hier verwendet, bezieht sich der Begriff „Funktechnologie“ auf Technologie für drahtlose Übertragung und/oder Empfangen elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugangstechnologie“ oder „RAT“ bezieht sich auf die Technologie, die für die zugrundeliegende physische Verbindung mit einem funkbasierten Kommunikationsnetzwerk verwendet wird. Der Begriff „V2X“ bezieht sich auf Kommunikationen von Fahrzeug zu Fahrzeug (V2V), Fahrzeug zu Infrastruktur (V2I), Infrastruktur zu Fahrzeug (I2V), Fahrzeug zu Netzwerk (V2N) und/oder Netzwerk zu Fahrzeug (N2V) und assoziierte Funkzugangstechnologien.
  • Wie hier verwendet, bezieht sich der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) auf einen Satz standardisierter Regeln oder Anweisungen, die durch eine Kommunikationsvorrichtung und/oder ein Kommunikationssystem implementiert werden, um mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, einschließlich Anweisungen zum Paketieren/Depaketieren von Daten, Modulieren/Demodulieren von Signalen, Implementieren von Protokollstapeln und/oder dergleichen.
  • Der Begriff „Kanal“, wie hierin verwendet, bezieht sich auf ein beliebiges gegenständliches oder nichtgegenständliches Übertragungsmedium, das verwendet wird, um Daten oder einen Datenstrom zu kommunizieren. Der Begriff „Kanal“ kann synonym mit und/oder äquivalent zu „Kommunikationskanal“, „Datenkommunikationskanal“, „Übertragungskanal“, „Datenübertragungskanal“, „Zugangskanal“, „Datenzugangskanal“, „Link“, „Datenlink“, „Träger“, „Funkfrequenzträger“ und/oder einem beliebigen anderen ähnlichen Begriff sein, der einen Pfad oder ein Medium bezeichnet, über den/das Daten kommuniziert werden. Außerdem bezieht sich der Begriff „Link“, wie hierin verwendet, auf eine Verbindung zwischen zwei Vorrichtungen durch eine RAT zum Zweck des Übertragens und Empfangens von Informationen.
  • Wie hier verwendet, bezieht sich der Begriff „Funktechnologie“ auf Technologie für drahtlose Übertragung und/oder Empfangen elektromagnetischer Strahlung zur Informationsübertragung. Der Begriff „Funkzugangstechnologie“ oder „RAT“ bezieht sich auf die Technologie, die für die zugrundeliegende physische Verbindung mit einem funkbasierten Kommunikationsnetzwerk verwendet wird.
  • Wie hier verwendet, bezieht sich der Begriff „Kommunikationsprotokoll“ (entweder drahtgebunden oder drahtlos) auf einen Satz standardisierter Regeln oder Anweisungen, die durch eine Kommunikationsvorrichtung und/oder ein Kommunikationssystem implementiert werden, um mit anderen Vorrichtungen und/oder Systemen zu kommunizieren, einschließlich Anweisungen zum Paketieren/Depaketieren von Daten, Modulieren/Demodulieren von Signalen, Implementieren von Protokollstapeln und/oder dergleichen. Beispiele für Drahtloskommunikationsprotokolle können bei verschiedenen Ausführungsformen verwendet werden, einschließlich einer Global System for Mobile Communications (GSM)-Funkkommunikationstechnologie, einer General Packet Radio Service (GPRS)-Funkkommunikationstechnologie, eine Enhanced Data Rates for GSM Evolution (EDGE)-Funkkommunikationstechnologie und/oder einer Third Generation Partnership Project (3GPP)-Funkkommunikationstechnologie, einschließlich zum Beispiel 3GPP der fünften Generation (5G) oder New Radio (NR), Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), Long Term Evolution (LTE), LTE-Advanced (LTE Advanced), LTE-Extra, LTE-A Pro, cdmaOne (2G), Code Division Multiple Access 2000 (CDMA 2000), Cellular Digital Packet Data (CDPD), Mobitex, Circuit Switched Data (CSD), High Speed CSD (HSCSD), Universal Mobile Telecommunications System (UMTS), Wideband Code Division Multiple Access (W-CDM), High Speed Packet Access (HSPA), HSPA Plus (HSPA+), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-SCDMA), LTE LAA, MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UTRA (E-UTRA), Evolution-Data Optimized oder Evolution-Data Only (EV-DO), Advanced Mobile Phone System (AMPS), Digital AMPS (D-AMPS), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Pushto-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), Cellular Digital Packet Data (CDPD), DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Personal Handyphone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), auch als 3GPP Generic Access Network oder GAN-Standard bezeichnet), Bluetooth®, Bluetooth Low Energy (BLE), IEEE 802.15.4 basierte Protokolle (z. B. IPv6 over Low Power Wireless Personal Area Networks (6LoWPAN), WirelessHART, MiWi, Thread, 802.1 1a usw.), WiFi-direct, ANT/ANT+, ZigBee, Z-Wave, 3GPP-Gerät-zu-Gerät (D2D) oder Proximity Services (ProSe), Universal Plug and Play (UPnP), Low-Power Wide-Area-Network (LPWAN), Long Range Wide Area Network (LoRA) oder LoRaWAN™, entwickelt von Semtech und der LoRa Alliance, Sigfox, Wireless Gigabit Alliance (WiGig)-Standard, Worldwide Interoperability for Microwave Access (WiMAX), mmWave-Standards im Allgemeinen (z. B. drahtlose Systeme, die bei 10 - 300 GHz und darüber arbeiten, wie etwa WiGig, IEEE 802.11ad, IEEE 802.11ay usw.), V2X-Kommunikationstechnologien (einschließlich C-V2X), Dedicated Short Range Communications (DSRC)-Kommunikationssysteme, wie etwa intelligente Transportsysteme (ITS) einschließlich der europäischen ITS-G5, ITS-G5B, ITS-G5C usw. Zusätzlich zu den oben aufgelisteten Standards kann unter anderem eine beliebige Anzahl von Satelliten-Uplink-Technologien für Zwecke der vorliegenden Offenbarung verwendet werden, einschließlich zum Beispiel Funkgeräten, die Standards entsprechen, die von der International Telecommunication Union (ITU) oder dem European Telecommunications Standards Institute (ETSI) ausgegeben werden. Die hier bereitgestellten Beispiele sind somit so zu verstehen, dass sie auf verschiedene andere Kommunikationstechnologien, sowohl existierende als auch noch nicht formulierte, anwendbar sind.
  • Der Begriff „V2X“ bezieht sich auf Kommunikationen von Fahrzeug zu Fahrzeug (V2V), Fahrzeug zu Infrastruktur (V2I), Infrastruktur zu Fahrzeug (I2V), Fahrzeug zu Netzwerk (V2N) und/oder Netzwerk zu Fahrzeug (N2V) und assoziierte Funkzugangstechnologien.
  • Der Begriff „lokal begrenztes Netzwerk“, wie hierin verwendet, kann sich auf ein lokales Netzwerk beziehen, das eine begrenzte Anzahl von verbundenen Fahrzeugen in einem gewissen Bereich oder einer gewissen Region abdeckt. Der Begriff „verteiltes Berechnen“, wie vorliegend verwendet, kann sich auf Rechenressourcen beziehen, die geographisch in der Nähe von Abschlüssen eines oder mehrerer lokal begrenzter Netzwerke verteilt sind. Der Begriff „lokale Datenintegrationsplattform“, wie vorliegend verwendet, kann sich auf eine Plattform, eine Vorrichtung, ein System, ein Netzwerk oder Element(e) beziehen, die lokale Daten durch Nutzen einer Kombination eines oder mehrerer lokal begrenzter Netzwerke und verteilter Berechnung integrieren.
  • Die Begriffe „Instanziieren“, „Instanziierung“ und dergleichen, wie hierin verwendet, beziehen sich auf die Erzeugung einer Instanz. Eine „Instanz“ bezieht auch auf ein konkretes Auftreten eines Objekts, das zum Beispiel während der Ausführung von Programmcode auftreten kann. Der Begriff „Informationselement“ bezieht sich auf ein Strukturelement, das ein oder mehrere Felder enthält. Der Begriff „Feld“ bezieht sich auf einzelne Inhalte eines Informationselements oder eines Datenelements, das Inhalt enthält. Der Begriff „Datenbankobjekt“, „Datenstruktur“ oder dergleichen kann sich auf eine beliebige Repräsentation von Informationen beziehen, die in Form eines Objekts, Attribut-Wert-Paars (AVP), Schlüssel-Wert-Paars (KVP), Tupels usw. vorliegen, und kann Variablen, Datenstrukturen, Funktionen, Verfahren, Klassen, Datenbankaufzeichnungen, Datenbankfelder, Datenbankentitäten, Assoziationen zwischen Daten und/oder Datenbankentitäten (auch als „Beziehung“ bezeichnet), Blöcke und Links zwischen Blöcken in Blockkettenimplementierungen und/oder dergleichen beinhalten. Der Begriff „Datenelement“ oder „DE“ bezieht sich auf einen Datentyp, der ein einziges Datenelement enthält. Der Begriff „Datenframe“ oder „DF“ bezieht sich auf einen Datentyp, der mehr als ein Datenelement in einer vorgegebenen Reihenfolge enthält.
  • Wie hier verwendet, bezieht sich der Begriff „Zuverlässigkeit“ auf die Fähigkeit einer computerbezogenen Komponente (z.B. Software, Hardware oder Netzwerkelement/-entität), konsistent eine gewünschte Funktion durchzuführen und/oder gemäß einer Spezifikation zu arbeiten. Zuverlässigkeit im Kontext von Netzwerkkommunikationen (z.B. „Netzwerkzuverlässigkeit“) kann sich auf die Fähigkeit eines Netzwerks zum Durchführen von Kommunikation beziehen. Netzwerkzuverlässigkeit kann auch die (oder ein Maß der) Wahrscheinlichkeit sein, dass eine spezifizierte Datenmenge von einer Quelle an ein Ziel (oder eine Senke) übermittelt wird.
  • Der Begriff „Anwendung“ kann sich auf eine vollständige und bereitstellbare Paketumgebung beziehen, um eine gewisse Funktion in einer Betriebsumgebung zu erreichen. Der Begriff „KI/ML-Anwendung“ oder dergleichen kann eine Anwendung sein, die einige KI/ML-Modelle und Beschreibungen auf Anwendungsebene enthält. Der Begriff „maschinelles Lernen“ oder „ML“ bezieht sich auf die Verwendung von Computersystemen, die Algorithmen und/oder statistische Modelle implementieren, um eine oder mehrere spezifische Aufgaben durchzuführen, wobei keine expliziten Anweisungen verwendet werden, sondern stattdessen auf Muster und Inferenzen gebaut wird. ML-Algorithmen erstellen oder schätzen mathematische Modell(e) (als „ML-Modelle“ oder dergleichen bezeichnet) basierend auf Sample-Daten (als „Trainingsdaten“, „Modelltrainingsinformationen“ oder dergleichen bezeichnet), um Vorhersagen oder Entscheidungen zu treffen, ohne zum Durchführen solcher Aufgaben explizit programmiert zu sein. Im Allgemeinen ist ein ML-Algorithmus ein Computerprogramm, das aus Erfahrung in Bezug auf irgendeine Aufgabe und irgendeine Performance-Maßnahme lernt, und ein ML-Modell kann ein beliebiges Objekt oder eine beliebige Datenstruktur sein, die erzeugt wird, nachdem ein ML-Algorithmus mit einem oder mehreren Trainingsdatensätzen trainiert wurde. Nach dem Training kann ein ML-Modell verwendet werden, um Prädiktionen über neue Datensätze zu machen. Obwohl sich der Begriff „ML-Algorithmus“ auf andere Konzepte als den Begriff „ML-Modell“ bezieht, können diese Begriffe, wie hier erörtert, austauschbar für die Zwecke der vorliegenden Offenbarung verwendet werden. Der Begriff „Sitzung“ bezieht sich auf einen temporären und interaktiven Informationsaustausch zwischen zwei oder mehr Kommunikationsvorrichtungen, zwei oder mehr Anwendungsinstanzen, zwischen einem Computer und einem Benutzer oder zwischen beliebigen zwei oder mehr Entitäten oder Elementen.
  • Der in Bezug auf ein Element oder eine Entität verwendete Begriff „Ego“, wie etwa „Ego-ITS-S“ oder dergleichen, bezieht sich auf eine ITS-S, die in Betracht gezogen wird, der Begriff „Ego-Fahrzeug“ bezieht sich auf ein Fahrzeug, das eine in Betracht gezogene ITS-S einbettet, und der Begriff „Nachbarn“ oder „Nähe“, der zum Beschreiben von Elementen oder Entitäten verwendet wird, bezieht sich auf andere ITS-Ss, die sich von der Ego-ITS-S und/oder dem Ego-Fahrzeug unterscheiden.
  • Der Begriff „Geobereich“ bezieht sich auf eine oder mehrere geometrische Formen, wie etwa kreisförmige Bereiche, rechteckige Bereiche und elliptische Bereiche. Ein kreisförmiger Geobereich wird durch eine Kreisform mit einem einzigen Punkt A, der den Mittelpunkt des Kreises repräsentiert, und einem Radius r beschrieben. Der rechteckige Geobereich ist durch eine rechteckige Form mit einem Punkt A, der die Mitte des Rechtecks repräsentiert, und einen Parameter a, der der Abstand zwischen dem Mittelpunkt und der kurzen Seite des Rechtecks (senkrechte Winkelhalbierende der kurzen Seite), einen Parameter b, der der Abstand zwischen dem Mittelpunkt und der langen Seite des Rechtecks (senkrechte Winkelhalbierende der langen Seite) ist, und einen Parameter Θ, der der Azimutwinkel der langen Seite des Rechtecks ist, definiert. Der elliptische Geobereich ist durch eine elliptische Form mit einem Punkt A, der das Zentrum des Rechtecks repräsentiert, und einen Parameter a, der die Länge der langen Halbachse ist, einen Parameter b, der die Länge der kurzen Halbachse ist, und einen Parameter Θ, der der Azimutwinkel der langen Halbachse ist, definiert. Eine ITS-S kann eine Funktion F verwenden, um zu bestimmen, ob sich ein Punkt P(x,y) innerhalb, außerhalb, in der Mitte oder an der Grenze eines geografischen Bereichs befindet. Die Funktion F(x, y) nimmt die kanonische Form der geometrischen Formen an: Das kartesische Koordinatensystem hat seinen Ursprung in der Mitte der Form. Seine Abszisse ist parallel zu der langen Seite der Formen. Der Punkt P ist relativ zu diesem Koordinatensystem definiert. Die verschiedenen Eigenschaften und anderen Funktionsaspekte F(x, y) sind in ETSI EN 302 931 v1.1.1 (2011-07) erörtert.
  • Der Begriff „Interoperabilität“ bezieht sich auf die Fähigkeit von ITS-Ss, die ein Kommunikationssystem oder eine RAT nutzen, mit anderen ITS-Ss unter Nutzung eines anderen Kommunikationssystems oder einer anderen RAT zu kommunizieren. Der Begriff „Koexistenz“ bezieht sich auf das Teilen oder Zuweisen von Hochfrequenzressourcen unter ITS-Ss unter Verwendung entweder eines Kommunikationssystems oder einer RAT.
  • Der Begriff „ITS-Datenlexikon“ bezieht sich auf ein Repository für DEs und DFs, die in den ITS-Anwendungen und der ITS-Facilities-Schicht verwendet werden. Der Begriff „ITS-Nachricht“ bezieht sich auf Nachrichten, die an der ITS-Facilities-Schicht zwischen ITS-Stationen oder Nachrichten ausgetauscht werden, die an der ITS-Anwendungsschicht zwischen ITS-Stationen ausgetauscht werden.
  • Der Begriff „kollektive Wahrnehmung“ oder „CP“ (collective perception) bezieht sich auf das Konzept des Teilens der wahrgenommenen Umgebung einer ITS-S basierend auf Wahrnehmungssensoren, wobei eine ITS-S Informationen über ihre aktuelle (Fahr-) Umgebung sendet. CP ist das Konzept des aktiven Austauschens lokal wahrgenommener Objekte zwischen verschiedenen ITS-Ss mittels einer V2X-RAT. CP verringert die Umgebungsunsicherheit der ITS-Ss, indem sie Informationen zu ihren gegenseitigen FOVs beiträgt. Der Begriff „Kollektivwahrnehmungs-Basisdienst“ (auch als CP-Dienst (CPS) bezeichnet) bezieht sich auf eine Einrichtung auf der ITS-S-Facilities-Schicht zum Empfangen und Verarbeiten von CPMs und Erzeugen und Übertragen von CPMs. Der Begriff „Kollektivwahrnehmungsnachricht“ oder „CPM“ bezieht sich auf eine CP-Basisdienst-PDU. Der Begriff „Kollektivwahrnehmungsdaten“ oder „CPM-Daten“ bezieht sich auf eine teilweise oder vollständige CPM-Nutzlast. Der Begriff „Kollektivwahrnehmungsprotokoll“ oder „CPM-Protokoll“ bezieht sich auf ein ITS-Facilities-Schichtprotokoll für den Betrieb der CPM-Erzeugung, -Übertragung und des -Empfangs. Der Begriff „CP-Objekt“ oder „CPM-Objekt“ bezieht sich auf aggregierte und interpretierte abstrakte Informationen, die durch Wahrnehmungssensoren über andere Verkehrsteilnehmer und Hindernisse gesammelt werden. CP/CPM-Objekte können mathematisch durch einen Satz von Variablen repräsentiert werden, der unter anderem ihren dynamischen Zustand und ihre geometrische Abmessung beschreibt. Die mit einem Objekt assoziierten Zustandsvariablen werden als Beobachtung für einen bestimmten Zeitpunkt interpretiert und werden daher immer von einer Zeitreferenz begleitet. Der Begriff „Umgebungsmodell“ bezieht sich auf eine aktuelle Darstellung der unmittelbaren Umgebung einer ITS-S, einschließlich aller wahrgenommenen Objekte, die entweder von lokalen Wahrnehmungssensoren wahrgenommen oder von V2X empfangen werden. Der Begriff „Objekt“ bezieht sich im Kontext des CP-Basisdienstes auf die Zustandsraumdarstellung eines physisch detektierten Objekts innerhalb des Wahrnehmungsbereichs eines Sensors. Der Begriff „Objektliste“ bezieht sich auf eine Sammlung von Objekten, die zeitlich auf denselben Zeitstempel ausgerichtet sind.
  • Der Begriff „ITS-Zentralsystem“ bezieht sich auf ein ITS-System im Backend, zum Beispiel ein Verkehrssteuerungszentrum, ein Verkehrsverwaltungszentrum oder ein Cloud-System von Verkehrsbehörden, ITS-Anwendungsanbietern oder Automobil-OEMs (vgl. z.B. Klausel 4.5.1.1 von [EN302665]).
  • Der Begriff „persönliche ITS-S“ bezieht sich auf eine ITS-S in einem nomadischen ITS-Subsystem im Kontext einer tragbaren Vorrichtung (z.B. einer mobilen Vorrichtung eines Fußgängers).
  • Der Begriff „Fahrzeug“ kann sich auf ein Straßenfahrzeug beziehen, das dazu ausgelegt ist, Personen oder Ladung auf öffentlichen Straßen und Autobahnen, wie etwa AVs, Busse, Autos, Lastwagen, Kleinbusse, Wohnmobile und Motorräder; zu Wasser, wie etwa Boote, Schiffe usw; oder in der Luft zu transportieren, wie etwa Flugzeuge, Hubschrauber, UAVs, Satelliten usw.
  • Der Begriff „Sensormessung“ bezieht sich auf abstrakte Objektbeschreibungen, die durch einen oder mehrere Merkmalsextraktionsalgorithmen erzeugt oder bereitgestellt werden, die auf dem Messprinzip eines lokalen Wahrnehmungssensors basieren können, der an einer ITS-S montiert ist. Der Merkmalsextraktionsalgorithmus verarbeitet Rohdaten eines Sensors (z.B. Reflexionsbilder, Kamerabilder usw.), um eine Objektbeschreibung zu erzeugen. Der Begriff „Zustandsraumdarstellung“ ist eine mathematische Beschreibung eines erkannten Objekts, das Zustandsvariablen wie etwa Abstand, Geschwindigkeit, Objektabmessungen und dergleichen beinhaltet. Die mit einem Objekt assoziierten Zustandsvariablen werden als eine Beobachtung für einen bestimmten Zeitpunkt interpretiert und werden daher von einer Zeitreferenz begleitet.
  • Der Begriff „Manöver“ bezieht sich auf spezifische und erkannte Bewegungen, die einen Akteur, z.B. einen Fußgänger, ein Fahrzeug oder eine andere Transportform, von einer Position zu einer anderen innerhalb eines bestimmten Impulses (Geschwindigkeitsvektor, Geschwindigkeitsvektorvariationen und Fahrzeugmasse) bringen. Der Begriff „Manöverkoordination“ oder „MC“ bezieht sich auf das Konzept des mittels einer V2X-RAT erfolgenden Teilens einer beabsichtigten Bewegung oder Reihe beabsichtigter Bewegungen einer ITS-S basierend auf Wahrnehmungssensoren, geplanten Trajektorien und dergleichen, wobei eine ITS-S Informationen über ihre aktuellen beabsichtigten Manöver rundsendet. Der Begriff „Manöverkoordinations-Basisdienst“ (auch als Manöverkoordinationsdienst (MCS) bezeichnet) bezieht sich auf eine Einrichtung auf der ITS-S-Facilities-Schicht zum Empfangen und Verarbeiten von MCMs und Erzeugen und Übertragen von MCMs. Der Begriff „Manöverkoordinationsnachricht“ oder „MCM“ bezieht sich auf eine MC-Basisdienst-PDU. Der Begriff „Manöverkoordinationsdaten“ oder „MCM-Daten“ bezieht sich auf eine partielle oder vollständige MCM-Nutzlast. Der Begriff „Manöverkoordinationsprotokoll“ oder „MCM-Protokoll“ bezieht sich auf ein ITS-Facilities-Schichtprotokoll für den Betrieb der MCM-Erzeugung, -Übertragung und des -Empfangs. Der Begriff „MC-Objekt“ oder „MCM-Objekt“ bezieht sich auf aggregierte und interpretierte abstrakte Informationen, die durch Wahrnehmungssensoren über andere Verkehrsteilnehmer und Hindernisse gesammelt werden, sowie Informationen von Anwendungen und/oder Diensten, die durch eine ITS-S betrieben oder beansprucht werden.
  • Obwohl viele der vorstehenden Beispiele unter Verwendung von spezieller Zellular-/Mobilnetzwerkterminologie bereitgestellt sind, einschließlich unter Verwendung von 4G/5G-3GPP-Netzwerkkomponenten (oder erwarteten terahertzbasierten Technologien von 6G/6G+), versteht es sich, dass diese Beispiele auf viele andere Anwendungen von Weitverkehrs- und Lokaldrahtlosnetzwerken sowie die Integration drahtgebundener Netzwerke (einschließlich optischer Netzwerke und assoziierter Fasern, Sendeempfänger usw.) angewandt werden können. Ferner können verschiedene Standards (z. B. 3 GPP, ETSI usw.) verschiedene Nachrichtenformate, PDUs, Container, Rahmen usw. als eine Sequenz von optionalen oder obligatorischen Datenelementen (DEs), Datenrahmen (DFs), Informationselementen (IEs) und/oder dergleichen umfassend definieren. Es versteht sich jedoch, dass die Anforderungen eines beliebigen speziellen Standards die hierin erörterten Ausführungsformen nicht einschränken sollten und daher eine beliebige Kombination von Containern, Frames, DFs, DEs, IEs, Werten, Aktionen und/oder Merkmalen in verschiedenen Ausführungsformen möglich ist, einschließlich einer beliebigen Kombination von Containern, DFs, DEs, Werten, Aktionen und/oder Merkmalen, die strikt befolgt werden müssen, um solchen Standards zu entsprechen, oder einer beliebigen Kombination von Containern, Frames, DFs, DEs, IEs, Werten, Aktionen und/oder Merkmalen, die dringend zu empfehlen sind und mit oder bei Vorhandensein/Nichtvorhandensein von optionalen Elementen verwendet werden.
  • Obwohl diese Implementierungen unter Bezugnahme auf spezielle beispielhafte Aspekte beschrieben wurden, ist es offensichtlich, dass verschiedene Modifikationen und Änderungen an diesen Aspekten vorgenommen werden können, ohne vom breiteren Schutzumfang der vorliegenden Offenbarung abzuweichen. Viele der hier beschriebenen Anordnungen und Prozesse können in Kombination oder in Parallelen Implementierungen verwendet werden, um eine größere Bandbreite/einen größeren Durchsatz bereitzustellen und um Edge-Dienstauswahlen zu unterstützen, die den zu versorgenden Edge-Systemen zur Verfügung gestellt werden können. Dementsprechend sind die Spezifikation und die Zeichnungen eher in einem veranschaulichenden statt in einem einschränkenden Sinne aufzufassen. Die begleitenden Zeichnungen, die einen Teil hiervon bilden, zeigen zur Veranschaulichung und nicht zur Einschränkung spezifische Aspekte, in denen der Gegenstand umgesetzt werden kann. Die veranschaulichten Aspekte sind hinreichend detailliert beschrieben, um einen Fachmann zu befähigen, die vorliegend offenbarten Lehren auszuüben. Andere Aspekte können genutzt und daraus abgeleitet werden, so dass strukturelle und logische Substitutionen und Änderungen vorgenommen werden können, ohne vom Schutzumfang dieser Offenbarung abzuweichen. Diese ausführliche Beschreibung ist daher nicht in einem einschränkenden Sinn aufzufassen, sondern der Schutzumfang verschiedener Aspekte wird allein durch die angehängten Ansprüche zusammen mit dem vollen Umfang von Äquivalenzen definiert, zu denen diese Ansprüche eine Berechtigung erteilen.
  • Auf solche Aspekte des erfindungsgemäßen Gegenstands kann hier einzeln und/oder kollektiv lediglich der Einfachheit halber Bezug genommen werden, und ohne zu beabsichtigen, den Schutzumfang dieser Anmeldung freiwillig auf einen beliebigen einzelnen Aspekt oder einen beliebigen einzelnen Erfindungsgedanken zu beschränken, falls tatsächlich mehr als einer offenbart ist. Obwohl hier spezielle Aspekte veranschaulicht und beschrieben wurden, versteht es sich daher, dass eine beliebige Anordnung, die berechnet wurde, um den gleichen Zweck zu erreichen, die gezeigten speziellen Aspekte ersetzen kann. Diese Offenbarung ist so zu verstehen, dass sie alle Anpassungen oder Variationen der zahlreichen Aspekte samt und sonders abdecken. Kombinationen der vorstehenden Aspekte und anderer hierin nicht speziell beschriebener Aspekte werden für den Fachmann aus der Durchsicht der vorstehenden Beschreibung ersichtlich.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 62994471 [0001]
    • US 63033597 [0001]
    • EP 168/2013 [0004, 0025]
    • US 62962760 [0049]

Claims (39)

  1. Verfahren, das durch eine Ursprungs-ITS-S (Intelligent Transport System Station, Station eines intelligenten Transportsystems) durchzuführen ist, wobei das Verfahren Folgendes umfasst: Sammeln und Verarbeiten von Sensordaten; Erzeugen einer dynamischen kontextbezogenen Straßenbelegungskarte (DCROM) basierend auf den gesammelten und verarbeiteten Sensordaten; Konstruieren einer VAM (Vulnerable Road User Awareness Message, Bewusstmachungsnachricht bezüglich ungeschützter Verkehrsteilnehmer), die ein oder mehrere Datenfelder (DFs) zum Teilen von DCROM-Informationen beinhaltet; und Übertragen oder Rundsenden der VAM an einen Satz von ITS-Ss einschließlich eines oder mehrerer ungeschützter Verkehrsteilnehmer (VRUs).
  2. Verfahren nach Anspruch 1, wobei die DCROM eine Belegungskarte mit einer Vielzahl von Zellen ist, wobei jede Zelle der Vielzahl von Zellen einen Belegungswert beinhaltet und der Belegungswert jeder Zelle eine Wahrscheinlichkeit ist, dass eine entsprechende Zelle von einem Objekt belegt ist.
  3. Verfahren nach Anspruch 2, wobei die DCROM-Informationen eines oder mehrere der Folgenden beinhalten: einen Referenzpunkt, der einen Standort der Ursprungs-ITS-S in einem durch die DCROM abgedeckten Bereich angibt; eine Gittergröße, die Abmessungen des Gitters angibt; eine Zellengröße, die Abmessungen jeder Zelle der Vielzahl von Zellen angibt; und Eine Startposition, die eine Startzelle des Belegungsgitters angibt, wobei andere Zellen der Vielzahl von Zellen basierend auf ihrer Beziehung zur Startzelle zu kennzeichnen sind.
  4. Verfahren nach Anspruch 3, wobei die DCROM-Informationen ferner Folgendes beinhalten: Belegungswerte, die die Belegung jeder Zelle im Gitter darstellen; und Konfidenzwerte, die jeder Zelle in dem Gitter entsprechen.
  5. Verfahren nach Anspruch 4, wobei die DCROM-Informationen ferner eine Bitmap der Belegungswerte beinhalten und die Konfidenzwerte mit der Bitmap assoziiert werden.
  6. Verfahren nach einem der Ansprüche 1-5, wobei die VAM eine erste VAM ist und das Verfahren ferner Folgendes umfasst: Empfangen einer zweiten VAM von zumindest einer ersten ITS-S des Satzes von ITS-Ss, wobei die erste ITS-S eine VRU-ITS-S ist.
  7. Verfahren nach Anspruch 6, ferner umfassend: Empfangen einer dritten VAM oder einer dezentralen Umgebungsbenachrichtigungsnachricht (DENM) von zumindest einer zweiten ITS-S des Satzes von ITS-Ss, wobei die zweite ITS-S eine VRU-ITS-S oder eine Nicht-VRU-ITS-S ist.
  8. Verfahren nach Anspruch 7, wobei: die erste VAM ein Belegungsstatusindikator- (OSI-) Datenfeld (DF) mit einem ersten OSI-Wert und ein Gitterstandortindikator- (GLI-) Feld mit einem ersten GLI-Wert beinhaltet, die zweite VAM ein OSI-Feld mit einem zweiten OSI-Wert und ein GLI-Feld mit einem zweiten GLI-Wert beinhaltet und die dritte VAM oder die DENM ein OSI-Feld mit einem dritten OSI-Wert und ein GLI-Feld mit einem dritten GLI-Wert beinhaltet.
  9. Verfahren nach Anspruch 8, ferner umfassend: Aktualisieren der DCROM basierend auf den zweiten OSI- und GLI-Werten oder den dritten OSI- und GLI-Werten.
  10. Verfahren nach Anspruch 8 oder 9, wobei: der erste GLI-Wert Zellen um eine erste Referenzzelle der Vielzahl von Zellen herum angibt, wobei die erste Referenzzelle eine Zelle in der DCROM ist, die durch die Ursprungs-ITS-S belegt ist, der zweite GLI-Wert relative Zellen um eine zweite Referenzzelle herum angibt, die zweite Referenzzelle eine Zelle in der DCROM ist, die durch die erste ITS-S belegt ist, und der dritte GLI-Wert relative Zellen um eine dritte Referenzzelle herum angibt, wobei die dritte Referenzzelle eine Zelle in der DCROM ist, die durch die zweite ITS-S belegt ist.
  11. Verfahren nach Anspruch 10, wobei: der erste OSI-Wert ein probabilistischer Indikator ist, der eine geschätzte Unsicherheit benachbarter Zellen um die Ursprungs-ITS-S herum anzeigt, der zweite OSI-Wert ein probabilistischer Indikator ist, der eine geschätzte Unsicherheit benachbarter Zellen um die erste ITS-S herum anzeigt, und der dritte OSI-Wert ein probabilistischer Indikator ist, der eine geschätzte Unsicherheit benachbarter Zellen um die zweite ITS-S herum anzeigt.
  12. Verfahren nach den Ansprüchen 1-11, wobei die gesammelten Sensordaten Sensordaten beinhalten, die von Sensoren der Ursprungs-ITS-S gesammelt werden.
  13. Verfahren nach den Ansprüchen 1-12, wobei die Sensordaten eine Ego-VRU-Kennung (ID) und/oder Positionsdaten und/oder Profildaten und/oder Geschwindigkeitsdaten und/oder Richtungsdaten und/oder Orientierungsdaten und/oder Trajektoriedaten und/oder Geschwindigkeitsvektordaten und/oder andere Sensordaten beinhalten.
  14. Verfahren nach einem der Ansprüche 1-13, ferner umfassend: Durchführen einer Kollisionsrisikoanalyse (CRA) basierend auf den Belegungswerten jeweiliger Zellen in der DCROM, wobei die CRA Folgendes beinhaltet: Durchführen von Trajektorienabfangwahrscheinlichkeits- (TIP-) Berechnungen; oder Durchführen einer TCC- (Zeit bis Kollision) Berechnung.
  15. Verfahren nach Anspruch 14, ferner umfassend: Bestimmen einer Kollisionsvermeidungsstrategie basierend auf der CRA; Auslösen einer Kollisionsrisikovermeidung basierend auf der Kollisionsvermeidungsstrategie; und Auslösen eines Manöverkoordinationsdienstes (MCS) zum Ausführen von Kollisionsvermeidungsaktionen der Kollisionsvermeidungsstrategie.
  16. Verfahren nach Anspruch 15, wobei die CRA Durchführen der TIP-Berechnungen beinhaltet und das Verfahren ferner Folgendes umfasst: Erzeugen einer weiteren VAM mit einem Trajektorieabfangindikator (TII) und einer Manöverkennung (MI), wobei der TII widerspiegelt, wie wahrscheinlich eine Trajektorie der Ursprungs-ITS-S von einer oder mehreren benachbarten ITSs abgefangen werden wird, und die MI einen Manövertyp angibt, der von den Kollisionsvermeidungsaktionen erforderlich ist; und Übertragen oder Rundsenden der weiteren VAM
  17. Verfahren nach einem der Ansprüche 3-16, wobei die DCROM eine geschichtete Kostenkarte ist, die eine Master-Kostenkarte und eine Vielzahl von Schichten beinhaltet.
  18. Verfahren nach Anspruch 17, wobei das Erzeugen der DCROM Folgendes umfasst: auf jeder Schicht der Vielzahl von Schichten erfolgendes Verfolgen von Daten bezüglich einer spezifischen Funktionalität oder eines spezifischen Sensortyps; und Akkumulieren der Daten aus jeder Schicht in die Master-Kostenkarte, wobei die Master-Kostenkarte die DCROM ist.
  19. Verfahren nach Anspruch 18, wobei die Vielzahl von Schichten eine statische Kartenschicht beinhaltet, die eine statische Karte eines oder mehrerer statischer Objekte in dem durch die DCROM abgedeckten Bereich beinhaltet.
  20. Verfahren nach Anspruch 19, wobei das Erzeugen der DCROM Folgendes umfasst: Erzeugen der statischen Karte unter Verwendung eines SLAM- (simultane Lokalisierung und Abbildung) Algorithmus; oder Erzeugen der statischen Karte aus einem Architekturdiagramm.
  21. Verfahren nach einem der Ansprüche 18-20, wobei die Vielzahl von Schichten ferner eine Hindernisschicht beinhaltet, die eine Hindernisschicht-Belegungskarte mit Sensordaten in Zellen der Vielzahl von Zellen mit detektierten Objekten gemäß den Sensordaten beinhaltet.
  22. Verfahren nach Anspruch 21, wobei das Erzeugen der DCROM Folgendes umfasst: Erzeugen der Hindernisschicht-Belegungskarte durch Überschreiben der statischen Karte mit den gesammelten Sensordaten.
  23. Verfahren nach einem der Ansprüche 18-22, wobei die Vielzahl von Schichten ferner eine Proxemikschicht beinhaltet, die eine Proxemikschicht-Belegungskarte mit detektierten VRUs und einem die detektierten VRUs umgebenden Raum in Zellen der Vielzahl von Zellen mit detektierten Objekten gemäß den Sensordaten beinhaltet.
  24. Verfahren nach Anspruch 23, wobei die Vielzahl von Schichten ferner eine Aufweitungsschicht beinhaltet, die eine Aufweitungsschicht-Belegungskarte mit jeweiligen Pufferzonen um detektierte Objekte herum beinhaltet, die als fatale Objekte bestimmt werden.
  25. Verfahren nach einem der Ansprüche 7-24, wobei: die Ursprungs-ITS-S eine VRU-ITS-S mit geringer Komplexität (LC) oder eine VRU-ITS-S mit hoher Komplexität (HC) ist, die erste ITS-S eine LC-VRU-ITS-S oder eine HC-VRU-ITS-S ist und die zweite ITS-S eine HC-VRU-ITS-S, eine Fahrzeug-ITS-S oder eine Straßenrand-ITS-S ist.
  26. Ein oder mehrere computerlesbare Medien, die Anweisungen umfassen, wobei die Ausführung der Anweisungen durch eine Prozessorschaltungsanordnung die Prozessorschaltungsanordnung veranlassen soll, das Verfahren nach einem der Ansprüche 1-25 auszuführen.
  27. Computerprogramm, das die Anweisungen nach Anspruch 26 umfasst.
  28. Anwendungsprogrammierschnittstelle, die Funktionen, Verfahren, Variablen, Datenstrukturen und/oder Protokolle für das Computerprogramm nach Anspruch 27 definiert.
  29. Einrichtung, die eine Schaltungsanordnung umfasst, die mit den Anweisungen nach Anspruch 26 geladen ist.
  30. Einrichtung, die eine Schaltungsanordnung umfasst, die betreibbar ist, um die Anweisungen nach Anspruch 26 auszuführen.
  31. Integrierte Schaltung, die die Prozessorschaltungsanordnung nach Anspruch 26 und/oder das eine oder die mehreren computerlesbaren Medien nach Anspruch 26 umfasst.
  32. Rechensystem, das das eine oder die mehreren computerlesbaren Medien und die Prozessorschaltungsanordnung nach Anspruch 26 umfasst.
  33. Einrichtung, die Mittel zum Ausführen der Anweisungen nach Anspruch 26 umfasst.
  34. Signal, das als Ergebnis eines Ausführens der Anweisungen nach Anspruch 26 erzeugt wird.
  35. Dateneinheit, die als Ergebnis eines Ausführens der Anweisungen nach Anspruch 26 erzeugt wird.
  36. Dateneinheit nach Anspruch 33, wobei es sich bei der Dateneinheit um ein Datagramm, ein Netzwerkpaket, einen Datenrahmen, ein Datensegment, eine PDU, eine Dienstdateneinheit, „SDU“, eine Nachricht oder ein Datenbankobjekt handelt.
  37. Signal, das mit der Dateneinheit nach Anspruch 35 oder 36 codiert ist.
  38. Elektromagnetisches Signal, das die Anweisungen nach Anspruch 26 trägt.
  39. Einrichtung, die Mittel zum Durchführen des Verfahrens nach einem der Ansprüche 1-25 umfasst.
DE112020006966.4T 2020-03-25 2020-12-21 Wahrnehmung über dynamische kontextbezogene strassenbelegungskarten für die sicherheit ungeschützter verkehrsteilnehmer in intelligenten transportsystemen Pending DE112020006966T5 (de)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US202062994471P 2020-03-25 2020-03-25
US62/994,471 2020-03-25
US202063033597P 2020-06-02 2020-06-02
US63/033,597 2020-06-02
PCT/US2020/066483 WO2021194590A1 (en) 2020-03-25 2020-12-21 Dynamic contextual road occupancy map perception for vulnerable road user safety in intelligent transportation systems

Publications (1)

Publication Number Publication Date
DE112020006966T5 true DE112020006966T5 (de) 2023-01-26

Family

ID=77892527

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112020006966.4T Pending DE112020006966T5 (de) 2020-03-25 2020-12-21 Wahrnehmung über dynamische kontextbezogene strassenbelegungskarten für die sicherheit ungeschützter verkehrsteilnehmer in intelligenten transportsystemen

Country Status (3)

Country Link
US (1) US20230095384A1 (de)
DE (1) DE112020006966T5 (de)
WO (1) WO2021194590A1 (de)

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021112349A1 (de) * 2020-05-12 2021-11-18 Motional Ad Llc Fahrzeugbetrieb unter verwendung eines dynamischen belegungsrasters
US12002345B2 (en) * 2020-05-22 2024-06-04 Wipro Limited Environment-based-threat alerting to user via mobile phone
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
US20220182853A1 (en) * 2020-12-03 2022-06-09 Faro Technologies, Inc. Automatic handling of network communication failure in two-dimensional and three-dimensional coordinate measurement devices
DE102021203809B4 (de) * 2021-03-16 2023-05-04 Continental Autonomous Mobility Germany GmbH Fahrverlaufsschätzung in einem Umfeldmodel
DE102021202935A1 (de) * 2021-03-25 2022-09-29 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren und Vorrichtung zum Steuern einer Fahrfunktion
US11783708B2 (en) * 2021-05-10 2023-10-10 Ford Global Technologies, Llc User-tailored roadway complexity awareness
US20230017962A1 (en) * 2021-07-15 2023-01-19 Waymo Llc Denial of service response to the detection of illicit signals on the in-vehicle communication network
US20230117467A1 (en) * 2021-10-14 2023-04-20 Lear Corporation Passing assist system
CN114372411B (zh) * 2021-12-30 2024-05-31 同济大学 一种供水管网巡检、查漏和改造三阶段病害诊断方法
US20230254786A1 (en) * 2022-02-09 2023-08-10 Qualcomm Incorporated Method and apparatus for c-v2x synchronization
CN117296423A (zh) * 2022-03-22 2023-12-26 北京小米移动软件有限公司 通感业务的处理方法、装置、通信设备及存储介质
CN115048785B (zh) * 2022-06-09 2024-03-19 重庆交通大学 一种回收沥青混合料分散均匀性的评测方法
DE102022206924A1 (de) 2022-07-06 2024-01-11 Robert Bosch Gesellschaft mit beschränkter Haftung Computerimplementiertes Verfahren und Steuergerät zum Bestimmen eines geforderten Sicherheitsintegritätsniveaus sicherheitsbezogener Fahrzeugfunktionen
CN114999160B (zh) * 2022-07-18 2022-10-21 四川省公路规划勘察设计研究院有限公司 一种基于车路协同道路的车辆安全合流控制方法及系统
CN115235475B (zh) * 2022-09-23 2023-01-03 成都凯天电子股份有限公司 一种基于mcc的ekf-slam后端导航路径优化方法
WO2024073361A1 (en) * 2022-09-28 2024-04-04 Qualcomm Technologies, Inc. Delimiter-based occupancy mapping
US20240157977A1 (en) * 2022-11-16 2024-05-16 Toyota Research Institute, Inc. Systems and methods for modeling and predicting scene occupancy in the environment of a robot

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8538675B2 (en) * 2009-06-01 2013-09-17 Raytheon Company Non-kinematic behavioral mapping
US9223004B2 (en) * 2013-03-22 2015-12-29 Qualcomm Incorporated Controlling position uncertainty in a mobile device
JP6120371B2 (ja) * 2013-10-23 2017-04-26 クラリオン株式会社 自動駐車制御装置および駐車支援装置
KR101881558B1 (ko) * 2015-10-22 2018-07-24 성균관대학교산학협력단 노변기를 이용한 차량과 보행자 간의 충돌을 경고하는 방법
US9630619B1 (en) * 2015-11-04 2017-04-25 Zoox, Inc. Robotic vehicle active safety systems and methods

Also Published As

Publication number Publication date
WO2021194590A1 (en) 2021-09-30
US20230095384A1 (en) 2023-03-30

Similar Documents

Publication Publication Date Title
DE112020006966T5 (de) Wahrnehmung über dynamische kontextbezogene strassenbelegungskarten für die sicherheit ungeschützter verkehrsteilnehmer in intelligenten transportsystemen
US20220388505A1 (en) Vulnerable road user safety technologies based on responsibility sensitive safety
US20220332350A1 (en) Maneuver coordination service in vehicular networks
US20230377460A1 (en) Intelligent transport system service dissemination
US20220383750A1 (en) Intelligent transport system vulnerable road user clustering, user profiles, and maneuver coordination mechanisms
US20230298468A1 (en) Generation and transmission of vulnerable road user awareness messages
WO2020257642A1 (en) For enabling collective perception in vehicular networks
US20220110018A1 (en) Intelligent transport system congestion and multi-channel control
US20220343241A1 (en) Technologies for enabling collective perception in vehicular networks
US20230206755A1 (en) Collective perception service enhancements in intelligent transport systems
US20230300579A1 (en) Edge-centric techniques and technologies for monitoring electric vehicles
US20240214786A1 (en) Vulnerable road user basic service communication protocols framework and dynamic states
US20210101612A1 (en) Edge System for Providing Local Dynamic Map Data
US20230138163A1 (en) Safety metrics based pre-crash warning for decentralized environment notification service
DE102022128028A1 (de) Angaben einer funksignalstärke
EP3987501B1 (de) Zur aktivierung der kollektiven wahrnehmung in fahrzeugnetzwerken
DE102023106287A1 (de) Anwendungsprogrammierschnittstelle zur speicherauswahl
DE102023120911A1 (de) Funksignalinformationsübertragung
DE102023106285A1 (de) Anwendungsprogrammierschnittstelle zur Speicherabwahl
DE102023121596A1 (de) Übertragung von referenzsignalkonfigurationsinformation
DE102023106258A1 (de) Anwendungsprogrammierschnittstelle zur Verhinderung der Abwahl von Speicher

Legal Events

Date Code Title Description
R083 Amendment of/additions to inventor(s)