From af0b3e2f3b9f287546c02581a0836088dbce8d72 Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Mon, 4 May 2026 14:11:06 +0200 Subject: [PATCH 1/8] Implement behavior services and attack framework for RSU Introduced behavior services for RSU, including a registry and a dummy service for testing. Enhanced VehicleManager and AIMModelManager to support new services and attack simulation framework. --- changes.rst | 116 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 116 insertions(+) create mode 100644 changes.rst diff --git a/changes.rst b/changes.rst new file mode 100644 index 0000000..aea16c6 --- /dev/null +++ b/changes.rst @@ -0,0 +1,116 @@ +PR Changes +========== + +Оркестрация behavior-сервисов для RSU +----------------------------------------------- + +Введена система behavior-сервисов для дорожных инфраструктурных узлов (RSU). + +Добавлен базовый интерфейс ``BehaviorService`` - протокол, которому должен соответствовать любой сервис, +подключаемый к участнику симуляции. Протокол описывает жизненный цикл сервиса: + +* ``on_attach`` - инициализация при подключении к участнику +* ``process`` - обработка входящих сообщений с возвратом типизированного результата +* ``on_detach`` - освобождение ресурсов + +Для управления сервисами введён ``BehaviorServiceRegistry`` - глобальный реестр, поддерживающий: + +* регистрацию через декоратор ``@BehaviorServiceRegistry.register`` +* поиск класса по имени +* фабричный метод ``create_service`` + +Реестр автоматически обнаруживает и загружает встроенные сервисы из подпакета ``services/``. + +Для тестирования добавлен ``DummyService`` - простая реализация, которая принимает текстовые сообщения +и возвращает их с дополнительным суффиксом, подтверждая корректную работу регистрации и маршрутизации сообщений. + +``RSUManager`` обновлён для поддержки конфигурации и запуска сервисов. +Конфигурирование сервисов вынесено в YAML-файлы сценариев. + +Поддержка behavior-сервисов в VehicleManager +------------------------------------------------------ + +``VehicleManager`` расширен поддержкой тех же behavior-сервисов, что были введены для RSU в PR #98. + +Добавлено: + +* загрузка конфигурации сервисов из YAML +* управление жизненным циклом (attach/detach) +* маршрутизация входящих сообщений по ``service_id`` + +Это унифицировало архитектуру сервисов для транспортных средств и дорожной инфраструктуры. + +Перенос AIMModelManager в слой сервисов +-------------------------------------------------- + +``AIMModelManager`` вынесен из ядра OpenCDA в сервисный слой в соответствии с сервис-ориентированной архитектурой. + +Добавлены три новых сервиса. + +**aim-server** + +Серверная сторона AIM-модели. Принимает батч запросов от транспортных средств, +запускает ML-инференс и возвращает предсказанные траектории. + +**aim-client** + +Клиентская сторона, работает на каждом транспортном средстве. Формирует запрос к серверу +с текущими данными о позиции, скорости, угле поворота и маршруте. +При получении ответа генерирует команду движения для ``movement-controller``. + +**movement-controller** + +Принимает команды с целевой позицией и управляет движением транспортного средства. + +Взаимодействие между сервисами организовано через типизированные сообщения (``TransportMessage``), +что исключило прямые зависимости между компонентами. + +Приоритеты для сервисов +---------------------------------- + +В систему behavior-сервисов добавлена поддержка приоритетов. + +Сервисы теперь инициализируются и обрабатываются в порядке возрастания числового значения поля ``priority`` - +сервис с меньшим числом выполняется первым. Приоритет задаётся в YAML-конфигурации сценария. + +Фреймворк атак *(Draft)* +----------------------------------- + +Введён фреймворк для симуляции атак на участников системы. + +Основные абстракции: + +* ``AttackProtocol`` - интерфейс конкретной атаки, описывает набор стадий (``AttackStageProtocol``) +* ``AttackManager`` - оркестратор атак, управляет реестрами и запускает атаки +* ``AttackRegistry`` - реестр зарегистрированных атак +* ``StageRegistry`` - реестр стадий атак +* ``AttackContext`` - контекст выполнения атаки +* ``AttackResult`` - результат выполнения атаки + +**Capability-система** + +Введён механизм явных привязок (``CapabilityBindings``) между именованными возможностями (``Capability``) +и конкретными методами сервисов. Это позволяет атакам и внешним компонентам обращаться к функциям сервиса +через стабильный интерфейс, не зная его внутренней реализации. + +Поддерживаемые capability: + +* ``request.observe`` - наблюдение за входящими запросами +* ``request.submit`` - отправка запросов +* ``response.observe`` - наблюдение за ответами +* ``response.submit`` - отправка ответов +* ``command.submit`` - отправка команд управления +* ``state.observe`` - наблюдение за состоянием сервиса + +**Расширения BehaviorService** + +Протокол ``BehaviorService`` расширен методом ``get_state()`` - возвращает иммутабельный снимок +текущего состояния сервиса. Реализованы state-объекты для существующих сервисов: + +* ``AIMServerState`` - отслеживаемые и обрабатываемые транспортные средства +* ``AIMClientState`` - статус подключения и следующая целевая позиция + +**Демонстрационная атака** + +Добавлен ``AIMClientResponseSniffer`` со стадией ``Sniffer`` - +перехватывает ответные сообщения AIM-сервера, адресованные клиентам. From 5c72ca33d21c2149a3e5c8feb68b07f98277d409 Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 10:51:05 +0200 Subject: [PATCH 2/8] text translation --- changes.rst | 116 --------------------------------------------------- services.rst | 107 +++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 107 insertions(+), 116 deletions(-) delete mode 100644 changes.rst create mode 100644 services.rst diff --git a/changes.rst b/changes.rst deleted file mode 100644 index aea16c6..0000000 --- a/changes.rst +++ /dev/null @@ -1,116 +0,0 @@ -PR Changes -========== - -Оркестрация behavior-сервисов для RSU ------------------------------------------------ - -Введена система behavior-сервисов для дорожных инфраструктурных узлов (RSU). - -Добавлен базовый интерфейс ``BehaviorService`` - протокол, которому должен соответствовать любой сервис, -подключаемый к участнику симуляции. Протокол описывает жизненный цикл сервиса: - -* ``on_attach`` - инициализация при подключении к участнику -* ``process`` - обработка входящих сообщений с возвратом типизированного результата -* ``on_detach`` - освобождение ресурсов - -Для управления сервисами введён ``BehaviorServiceRegistry`` - глобальный реестр, поддерживающий: - -* регистрацию через декоратор ``@BehaviorServiceRegistry.register`` -* поиск класса по имени -* фабричный метод ``create_service`` - -Реестр автоматически обнаруживает и загружает встроенные сервисы из подпакета ``services/``. - -Для тестирования добавлен ``DummyService`` - простая реализация, которая принимает текстовые сообщения -и возвращает их с дополнительным суффиксом, подтверждая корректную работу регистрации и маршрутизации сообщений. - -``RSUManager`` обновлён для поддержки конфигурации и запуска сервисов. -Конфигурирование сервисов вынесено в YAML-файлы сценариев. - -Поддержка behavior-сервисов в VehicleManager ------------------------------------------------------- - -``VehicleManager`` расширен поддержкой тех же behavior-сервисов, что были введены для RSU в PR #98. - -Добавлено: - -* загрузка конфигурации сервисов из YAML -* управление жизненным циклом (attach/detach) -* маршрутизация входящих сообщений по ``service_id`` - -Это унифицировало архитектуру сервисов для транспортных средств и дорожной инфраструктуры. - -Перенос AIMModelManager в слой сервисов --------------------------------------------------- - -``AIMModelManager`` вынесен из ядра OpenCDA в сервисный слой в соответствии с сервис-ориентированной архитектурой. - -Добавлены три новых сервиса. - -**aim-server** - -Серверная сторона AIM-модели. Принимает батч запросов от транспортных средств, -запускает ML-инференс и возвращает предсказанные траектории. - -**aim-client** - -Клиентская сторона, работает на каждом транспортном средстве. Формирует запрос к серверу -с текущими данными о позиции, скорости, угле поворота и маршруте. -При получении ответа генерирует команду движения для ``movement-controller``. - -**movement-controller** - -Принимает команды с целевой позицией и управляет движением транспортного средства. - -Взаимодействие между сервисами организовано через типизированные сообщения (``TransportMessage``), -что исключило прямые зависимости между компонентами. - -Приоритеты для сервисов ----------------------------------- - -В систему behavior-сервисов добавлена поддержка приоритетов. - -Сервисы теперь инициализируются и обрабатываются в порядке возрастания числового значения поля ``priority`` - -сервис с меньшим числом выполняется первым. Приоритет задаётся в YAML-конфигурации сценария. - -Фреймворк атак *(Draft)* ------------------------------------ - -Введён фреймворк для симуляции атак на участников системы. - -Основные абстракции: - -* ``AttackProtocol`` - интерфейс конкретной атаки, описывает набор стадий (``AttackStageProtocol``) -* ``AttackManager`` - оркестратор атак, управляет реестрами и запускает атаки -* ``AttackRegistry`` - реестр зарегистрированных атак -* ``StageRegistry`` - реестр стадий атак -* ``AttackContext`` - контекст выполнения атаки -* ``AttackResult`` - результат выполнения атаки - -**Capability-система** - -Введён механизм явных привязок (``CapabilityBindings``) между именованными возможностями (``Capability``) -и конкретными методами сервисов. Это позволяет атакам и внешним компонентам обращаться к функциям сервиса -через стабильный интерфейс, не зная его внутренней реализации. - -Поддерживаемые capability: - -* ``request.observe`` - наблюдение за входящими запросами -* ``request.submit`` - отправка запросов -* ``response.observe`` - наблюдение за ответами -* ``response.submit`` - отправка ответов -* ``command.submit`` - отправка команд управления -* ``state.observe`` - наблюдение за состоянием сервиса - -**Расширения BehaviorService** - -Протокол ``BehaviorService`` расширен методом ``get_state()`` - возвращает иммутабельный снимок -текущего состояния сервиса. Реализованы state-объекты для существующих сервисов: - -* ``AIMServerState`` - отслеживаемые и обрабатываемые транспортные средства -* ``AIMClientState`` - статус подключения и следующая целевая позиция - -**Демонстрационная атака** - -Добавлен ``AIMClientResponseSniffer`` со стадией ``Sniffer`` - -перехватывает ответные сообщения AIM-сервера, адресованные клиентам. diff --git a/services.rst b/services.rst new file mode 100644 index 0000000..3bd7f01 --- /dev/null +++ b/services.rst @@ -0,0 +1,107 @@ +Behavior Service Orchestration +------------------------------- + +A behavior service system has been introduced for simulation participants, including +Road-Side Units (RSU) and vehicles. + +The ``BehaviorService`` interface defines the protocol that every service attached to +a participant must implement. It describes the service lifecycle: + +* ``on_attach`` - initialize the service for a particular participant instance +* ``process`` - process incoming messages and return a typed result +* ``on_detach`` - release service resources before the participant is destroyed + +``BehaviorServiceRegistry`` is a global registry that supports: + +* registration via the ``@BehaviorServiceRegistry.register`` decorator +* class lookup by service name +* a ``create_service`` factory method + +The registry automatically discovers and loads built-in services from the ``services/`` +subpackage. + +A ``DummyService`` has been added for testing purposes. It accepts text messages and +returns them with an appended suffix, verifying that registration and message routing +work correctly. + +Both ``RSUManager`` and ``VehicleManager`` have been updated to support service +configuration and lifecycle management - including config loading from YAML, +attach/detach handling, and message routing by ``service_id``. This unified the +service architecture across vehicles and road-side infrastructure. + +AIM Services +------------ + +``AIMModelManager`` has been extracted from the OpenCDA core into the service layer +to align with the service-based architecture. Three new services were introduced. + +**aim-server** + +The server-side AIM service. It receives a batch of requests from vehicles, +runs ML inference, and returns predicted trajectories. + +**aim-client** + +The client-side service, running on each vehicle. It builds a request to the server +with the vehicle's current position, speed, heading, and route. +Upon receiving a response, it generates a movement command for the ``movement-controller``. + +**movement-controller** + +Accepts movement commands with a target position and controls vehicle motion. + +All inter-service communication is routed through typed ``TransportMessage`` objects, +eliminating direct dependencies between components. + +Service Priority +---------------- + +Priority-aware ordering has been added to the behavior service system. Services are +now initialized and processed in ascending order of their numeric ``priority`` field - +a lower value means the service runs first. Priority is configured in the +scenario YAML file. + +Attack Framework *(Draft)* +--------------------------- + +A framework for simulating adversarial attacks on simulation participants has been +introduced. + +Core abstractions: + +* ``AttackProtocol`` - interface for a concrete attack, composed of stages (``AttackStageProtocol``) +* ``AttackManager`` - orchestrates attacks, manages registries, and collects results +* ``AttackRegistry`` - registry of registered attacks +* ``StageRegistry`` - registry of attack stages +* ``AttackContext`` - execution context passed to an attack at runtime +* ``AttackResult`` - result produced by a completed attack + +**Capability System** + +A capability binding mechanism (``CapabilityBindings``) has been introduced, linking +named capabilities (``Capability``) to concrete service methods. This allows attacks +and external components to interact with a service through a stable interface, +without knowledge of its internal implementation. + +Supported capabilities: + +* ``request.observe`` - observe incoming requests +* ``request.submit`` - submit requests +* ``response.observe`` - observe responses +* ``response.submit`` - submit responses +* ``command.submit`` - submit movement commands +* ``state.observe`` - observe service state + +**BehaviorService Extensions** + +The ``BehaviorService`` protocol has been extended with a ``get_state()`` method that +returns an immutable snapshot of the current service state. State objects have been +implemented for the existing services: + +* ``AIMServerState`` - tracked and processed vehicle IDs and counts +* ``AIMClientState`` - attachment status and next target position + +**Example Attack** + +``AIMClientResponseSniffer`` has been added as a demonstration attack. It uses a +``Sniffer`` stage to intercept AIM server response messages addressed to clients. From 1193fc0ca7b7232cf565219388b0fe4faa7fceb7 Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 10:58:55 +0200 Subject: [PATCH 3/8] add heading --- services.rst | 3 +++ 1 file changed, 3 insertions(+) diff --git a/services.rst b/services.rst index 3bd7f01..4186590 100644 --- a/services.rst +++ b/services.rst @@ -1,3 +1,6 @@ +OpenCDA Service Layer +========== + Behavior Service Orchestration ------------------------------- From 564eb9adc29c8fce6c7c4c1660b4ca54eb19a1d6 Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 11:14:10 +0200 Subject: [PATCH 4/8] changed the file path --- services.rst => source/wiki/services.rst | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename services.rst => source/wiki/services.rst (100%) diff --git a/services.rst b/source/wiki/services.rst similarity index 100% rename from services.rst rename to source/wiki/services.rst From c334fca73655ae97de0cc5508a91b73b80ad50a1 Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 11:24:51 +0200 Subject: [PATCH 5/8] Add OpenCDA Service Layer link to navigation --- source/_nav.rstinc | 1 + 1 file changed, 1 insertion(+) diff --git a/source/_nav.rstinc b/source/_nav.rstinc index 6263690..a14de0b 100644 --- a/source/_nav.rstinc +++ b/source/_nav.rstinc @@ -7,6 +7,7 @@ Install and Launch Problems and Solutions Additional Scripts + OpenCDA Service Layer .. toctree:: :hidden: From ebe2b0621cc7e733b75b6158dfaceaf67cd2ac02 Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 22:16:07 +0200 Subject: [PATCH 6/8] Add analysis of neural network architectures for trajectory prediction This document provides a comprehensive analysis of two neural network architectures designed for multi-task trajectory prediction in autonomous driving systems, detailing their structures, algorithms, and applications in intersection management. --- source/wiki/nn-trajectory-prediction.rst | 174 +++++++++++++++++++++++ 1 file changed, 174 insertions(+) create mode 100644 source/wiki/nn-trajectory-prediction.rst diff --git a/source/wiki/nn-trajectory-prediction.rst b/source/wiki/nn-trajectory-prediction.rst new file mode 100644 index 0000000..43a47cb --- /dev/null +++ b/source/wiki/nn-trajectory-prediction.rst @@ -0,0 +1,174 @@ +Analysis of Neural Network Architectures for Multi-Task Trajectory Prediction in Autonomous Driving Systems +========================================================================================================== + +Introduction +------------ + +The presented models GNN_mtl_gnn and GNN_mtl_mlp are implementations of deep neural +networks for the Multi-Task Learning (MTL) problem in the context of trajectory control +for autonomous vehicles at intersections. + +Architectural Overview +---------------------- + +General Concept +~~~~~~~~~~~~~~~ + +Both models follow a unified multi-task learning paradigm, where a single network +simultaneously solves several related prediction tasks. The key difference between +the architectures lies in how they handle spatial dependencies between traffic participants. + +Input and Output Parameters +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +**Input data:** + +* Input vector dimensionality: 5 features per object +* Includes: coordinates (x, y), speed, heading, vehicle class + +**Output data:** + +* Output dimensionality: 60 values (30 × 2) +* Interpretation: trajectory prediction over 30 time steps, where 2 coordinates (x, y) + are predicted for each step + +GNN_mtl_gnn Model: Graph Neural Network Approach +------------------------------------------------- + +Architectural Composition +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The model consists of several sequential processing blocks. + +**1. Feature Encoding Block** + +linear1: 5 → 64 + ReLU + +linear2: 64 → hidden_channels + ReLU + +This block performs the initial transformation of raw features into a high-dimensional +hidden representation space. + +**2. Residual Learning Block** + +linear3: hidden_channels → hidden_channels + ReLU + skip connection + +linear4: hidden_channels → hidden_channels + ReLU + skip connection + +The use of residual connections allows the network to train effectively on deep +architectures by preventing the vanishing gradient problem. Each layer learns to +predict the residual function relative to its input. + +**3. Graph Convolution Block** + +conv1: GraphConv(hidden_channels → hidden_channels) + ReLU + +conv2: GraphConv(hidden_channels → hidden_channels) + ReLU + +This is a critically important architectural component. Graph convolutional layers +aggregate information from neighboring nodes in the graph via the ``edge_index`` +structure. The model captures interactions between vehicles. + +**4. Trajectory Prediction Head** + +linear5: hidden_channels → 60 + +The final fully connected layer projects the hidden representation into the space +of predicted trajectories. + +Algorithm +~~~~~~~~~ + +1. **Initialization:** Each vehicle is represented as a graph node with a 5-dimensional + feature vector +2. **Feature encoding:** Input data is sequentially transformed through two linear layers, + increasing representational capacity +3. **Representation enrichment:** Two residual blocks deepen the feature space while + preserving gradient flow +4. **Graph aggregation:** Convolutional operations propagate information across the graph, + where each node updates its representation based on the states of its neighbors, + weighted by graph topology +5. **Trajectory decoding:** The final linear projection generates coordinates of future positions + +Advantages of the Approach +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +* **Explicit interaction modeling:** The graph structure naturally encodes spatial + relationships between agents +* **Permutation invariance:** The ordering of vehicles does not affect the result +* **Scalability:** The architecture efficiently handles a variable number of traffic participants + +GNN_mtl_mlp Model: Multi-Layer Perceptron Approach +--------------------------------------------------- + +Architectural Differences +~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The GNN_mtl_mlp model is identical to GNN_mtl_gnn in all aspects except one critical change: + +conv1: Linear(hidden_channels → hidden_channels) + ReLU + +conv2: Linear(hidden_channels → hidden_channels) + ReLU + +The graph convolutional layers are replaced with standard fully connected (Linear) layers. +This means that the ``edge_index`` parameter is ignored, and each vehicle is processed +independently. + +Algorithm +~~~~~~~~~ + +The algorithm is analogous to the GNN version, with one key difference at step 4: + +1. **Independent processing:** Instead of graph aggregation, standard matrix transformations + are applied without considering the interaction structure + +Role in the Experiment +~~~~~~~~~~~~~~~~~~~~~~ + +This model serves as a baseline for evaluating the importance of graph structure. +Comparing the performance of the two models allows quantifying the contribution of +relational information to prediction accuracy. + +Technical Implementation Details +--------------------------------- + +Reproducibility +~~~~~~~~~~~~~~~ + +Setting ``torch.manual_seed(21)`` ensures deterministic weight initialization, which +is critical for a valid comparison between models. + +Nonlinearities +~~~~~~~~~~~~~~ + +The use of ReLU activations after each transformation layer introduces the nonlinearity +necessary for modeling complex dependencies in the data. + +Residual Connections +~~~~~~~~~~~~~~~~~~~~ + +The ``+ x`` operations implement skip connections, allowing gradients to pass directly +through blocks, which stabilizes training of deep networks. + +Application in AIM Systems +-------------------------- + +In the context of Autonomous Intersection Management, these models address the problem +of predicting future vehicle trajectories based on their current state and relative positions. + +**Typical usage scenario:** + +1. The central intersection management system receives data about all approaching vehicles +2. A graph is formed where edges connect potentially interacting agents +3. The model generates trajectory predictions over a horizon of ~3–5 seconds +4. The planning system uses the predictions to optimize intersection traversal and + prevent collisions + +Conclusion +---------- + +The presented architectures demonstrate two approaches to the trajectory prediction +problem: one with explicit interaction modeling through graph neural networks, and one +without it through classical multi-layer perceptrons. Both models employ modern deep +learning techniques (residual connections, multi-task learning) and are specialized +for real-time operation in safety-critical autonomous vehicle control systems. From f0e3705ae56ce73e68edd90283fea9dd01e1b3ea Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 22:22:45 +0200 Subject: [PATCH 7/8] Add article on trajectory planning for autonomous vehicles This article discusses a method for managing autonomous vehicle movement at intersections without traffic lights, emphasizing the need for coordinated trajectories to prevent collisions and minimize delays. It also highlights limitations regarding scalability, robustness, and mixed traffic conditions. --- source/wiki/aim-trajectory-planning.rst | 38 +++++++++++++++++++++++++ 1 file changed, 38 insertions(+) create mode 100644 source/wiki/aim-trajectory-planning.rst diff --git a/source/wiki/aim-trajectory-planning.rst b/source/wiki/aim-trajectory-planning.rst new file mode 100644 index 0000000..92898bc --- /dev/null +++ b/source/wiki/aim-trajectory-planning.rst @@ -0,0 +1,38 @@ +Trajectory Planning for Autonomous Intersection Management +========================================================== + +The article `"Trajectory planning for autonomous intersection management" `_ +describes the development of a method for managing the movement of autonomous vehicles +at intersections without the use of traditional traffic lights. The authors argue that +as the number of autonomous vehicles on the road increases, classical traffic control +schemes become inefficient because they do not account for the individual trajectory +of each vehicle. This leads to increased emissions and a high risk of accidents, +highlighting the need for a system that would transform the intersection into a hub +of collective intelligence and increase its throughput. + +The proposed approach is based on generating coordinated trajectories for autonomous +vehicles taking into account their current state and potential conflict zones. The +algorithm prevents collisions and minimizes delays, providing smoother intersection +traversal compared to phase-based control. From a methodological standpoint, this +approach is well suited to the task, as it works directly with the spatiotemporal +movement of vehicles. However, the system relies on an idealized motion model: exact +knowledge of vehicle states, reliable inter-vehicle communication, and the absence of +human drivers, which limits the practical applicability of the results. + +The article gives insufficient attention to the scalability of the algorithm under +high traffic density, robustness to sensor errors and V2X communication delays, and +the impact of mixed traffic. These factors significantly affect the performance of +AIM in real-world conditions, but they remain outside the scope of the analysis. + +The research results are based on simulations that demonstrate reduced waiting times +and increased throughput compared to traditional control methods. The authors interpret +the obtained data correctly; however, the conclusions should be viewed as a demonstration +of potential benefits rather than proof of the method's readiness for practical +deployment, since the experiments were conducted in a simplified environment. + +The trajectory planning algorithm proposed in the article can serve as a baseline +approach for implementing and testing autonomous intersection management within the +CAVISE project. The project architecture allows for the integration of such cooperative +driving methods and enables studying their behavior under real-world conditions, +including the effects of background traffic, sensor perception errors, and V2X +communication delays. From 1a4c5055f82d896f804e7fdc276442b454bf3b5a Mon Sep 17 00:00:00 2001 From: Victoria Chelnokova <148325729+tori-da-vi@users.noreply.github.com> Date: Tue, 5 May 2026 22:30:36 +0200 Subject: [PATCH 8/8] Add links for Neural Network and AIM Trajectory Planning --- source/_nav.rstinc | 2 ++ 1 file changed, 2 insertions(+) diff --git a/source/_nav.rstinc b/source/_nav.rstinc index a14de0b..353db44 100644 --- a/source/_nav.rstinc +++ b/source/_nav.rstinc @@ -8,6 +8,8 @@ Problems and Solutions Additional Scripts OpenCDA Service Layer + Neural Network Trajectory Prediction + AIM Trajectory Planning .. toctree:: :hidden: