1.   Назначение системы
АИСТ — автоматизированная система мониторинга и управления транспортной инфраструктурой автодорог России. Система обеспечивает:
·         визуализацию на интерактивной карте устройств дорожной инфраструктуры: видеокамер, автоматических станций метеонаблюдений (АСМО), табло переменной информации (ТПИ), пунктов учёта интенсивности движения (ПУИД);
·         мониторинг состояния устройств в режиме реального времени;
·         управление ТПИ (загрузка изображений, формирование и применение сценариев);
·         регистрацию и сопровождение заявок на устранение нарушений дорожных условий;
·         работу с договорами на обслуживание участков дорог;
·         учёт ДТП и дорожных инцидентов;
·         формирование экспортных отчётов (Excel, PDF).
Система эксплуатируется диспетчерским персоналом, инженерно-техническими работниками и должностными лицами дорожной службы.
2.   Архитектурный стиль
Система построена по трёхуровневой клиент-серверной архитектуре с разделением на:

Клиентская часть реализована по архитектурному паттерну Single Page Application (SPA) с компонентным подходом. Все переходы между представлениями осуществляются без перезагрузки страницы. Взаимодействие с сервером — исключительно через REST API посредством Fetch API.
Серверная часть состоит из двух независимых FastAPI-сервисов, выполняющих разные функциональные роли (см. раздел 3). Оба сервиса следуют принципам REST: ресурсно-ориентированные URL, стандартные HTTP-методы (GET, POST, PUT, DELETE), JSON как формат обмена данными.
Точкой входа для клиентского трафика служит веб-сервер Nginx, выполняющий функции обратного прокси (reverse proxy): раздаёт статические файлы SPA и проксирует API-запросы к соответствующим бэкенд-сервисам.
Архитектурный стиль можно охарактеризовать как Layered + REST + Component-Based, где: - разграничение ответственности между слоями обеспечивает независимость

развёртывания и масштабирования; - компонентный подход на фронтенде обеспечивает переиспользуемость UI-элементов; - REST-интерфейсы обеспечивают слабое связывание между клиентом и сервером.
3.   Структурные элементы системы и их интерфейсы3.1   Клиентское приложение (React SPA)
Роль: единственная точка взаимодействия пользователя с системой. Запускается в браузере пользователя, не требует установки.
Технологический стек:
 
Структура приложения (~55 компонентов, сгруппированных по функциональным модулям):
src/
├── App.jsx— корневой компонент, глобальное состояние, переключение представлений
├── api.js— API-слой (~2700 строк): все HTTP-запросы к бэкендам
├── deviceManager.js         — нормализация и обогащение данных устройств
├── kilometerPostsManager.js — обогащение данных о километровых столбах
├── xmlParser.js             — разбор XML-отчётов метеостанций
├── components/— 36 компонентов верхнего уровня
│  └── modals/              — 19 модальных окон
├── contexts/
│  └── AuthContext.jsx      — JWT-аутентификация через React Context
├── data/                    — статические и mock-данные (камеры, дороги, КП, ТПИ)
├── services/— сервисы кэширования и автообновления
└── utils/                   — утилиты (константы, даты, геометрия, localStorage, дороги)
Функциональные модули клиентского приложения:
 

Управление состоянием: - Локальное состояние компонентов — React hooks (useState, useEffect). - Аутентификация — AuthContext (React Context + useReducer); токен хранится в localStorage (ключ asudd_token). - Настройки, фильтры, положение карты — 19 ключей в localStorage с префиксом asudd_. - Периодическое обновление данных — сервисы с таймерами и паттерном pub/sub: - weatherDataService — обновление данных АСМО каждые 10 минут; - weatherAnalyticsService — обновление оповещений каждые 60 секунд;
- tpiImageCache — кэш изображений ТПИ, TTL 15 минут, пакетная загрузка по 3.
Интерфейс клиентского приложения с внешними системами: HTTP/HTTPS REST API. В production-режиме запросы направляются через Nginx-прокси; в dev-режиме — через встроенный прокси Vite.
3.2   Бэкенд-сервис «bob_front»
Адрес: http://5.23.53.10:8901 Реализация: Python / FastAPI OpenAPI title: bob_front v0.1.0 Аутентификация: HTTP Basic Auth Назначение: источник исходных данных об устройствах дорожной инфраструктуры. Исключительно операции чтения.
Предоставляемые ресурсы:
 

Ключевые схемы данных:
·         CameraSchema — id, host, port, route, address, latitude, longitude, last_report, region, active
·         StationSchema — id, sid, active, stype, route, address, latitude, longitude, region
·         TpiDeviceSchema — id, tid, active, ttype, route, address, latitude, longitude, cameraid, region
·         PuidSchema — id, pid, active, pmode, f_lanes, b_lanes, route, address, last_file, region
·         PuidDataSchema — puid, ts_puid, f_lanes, b_lanes, period, val (массив значений по полосам)
3.3   Бэкенд-сервис «aist_front» (Основной API)
Адрес: https://aist.ddsural.ru (production) / http://localhost:8902 (internal) Реализация: Python
/ FastAPI OpenAPI title: aist_front v0.1.0 Аутентификация: OAuth2 Password Flow (JWT Bearer token), эндпоинт /api/token Назначение: основной бизнес-сервис, обеспечивающий полный жизненный цикл всех сущностей системы. CRUD-операции, управление пользователями, работа с файлами.
Иерархия данных сервиса:
Site (площадка/организация)
Site (площадка/организация)
 └── Region (регион/участок)
     └── Устройства ТПИ (tpi_device)
 └── Пользователи (users)
 └── Заявки (issues)
 └── Договоры (contracts)
 └── Инциденты/ДТП (accidents)
 └── Документы ПОДД (podd_file)
 └── ТПИ-ресурсы (изображения, сценарии, правила метео-оповещений)
Модули сервиса:
 

Ролевая модель пользователей (из UserInfoSchema): - login, site_id — принадлежность к площадке - role — числовой идентификатор роли - perm — объект с детализацией прав доступа - regions — доступные регионы - is_officer — признак должностного лица - official_id, contractor_id, curator_id — связи с организационными сущностями


3.4   СУБД PostgreSQL
Роль: постоянное хранилище данных системы. Каждый бэкенд-сервис использует отдельную базу данных в рамках одного PostgreSQL-инстанса.
БД сервиса bob_front
Содержит данные, поступающие непосредственно с полевого оборудования:

БД сервиса aist_front
Содержит бизнес-данные системы управления:

Бинарные данные (изображения, файлы вложений) хранятся непосредственно в СУБД в полях типа bytea (поле obj в схемах TpiPictSchema, IssueFileSchema, PoddFileSchema).
Связь между базами данных на уровне идентификаторов: сервис aist_front ссылается на устройства по тем же идентификаторам (tid, camera_id), что и bob_front, однако прямых внешних ключей между БД нет — согласованность обеспечивается на уровне приложения.
3.5   Веб-сервер Nginx
Роль: единая точка входа в систему, обратный прокси, раздача статических файлов.
Функции: - Раздача статических файлов скомпилированного React SPA (HTML, JS, CSS, assets). - Проксирование API-запросов: - /bob_api/* → http://5.23.53.10:8901/* (bob_front) -
/api/v2/* → https://aist.ddsural.ru/api/* (aist_front) - /images/* → https://download-demo.softlogic.ai/* (внешнее хранилище изображений) - Терминирование HTTPS (TLS-сертификаты).
3.6   Внешние интеграции


Интеграция с Яндекс.Картами реализована на уровне тайловых слоёв OpenLayers: базовая карта (l=map), пробки (l=trf), дорожные события (l=trje, l=trfe). Запросы уходят напрямую из браузера к серверам Яндекса в проекции EPSG:3395 (Меркатор).
Погодные слои (температура, осадки, ветер и др.) отображаются через промежуточный прокси-сервис, который предоставляет тайлы в формате XYZ с данными OpenWeatherMap. Прямого обращения к API OpenWeatherMap из клиентского приложения нет.
Интеграция с demo.softlogic.ai обеспечивает получение заявок, автоматически созданных системой видеоаналитики, и их синхронизацию с АИСТ (поле softlogic_id в IssueSchema).
4.   Соединение структурных элементов
4.1   Общая схема взаимодействия

4.2   Протоколы и форматы обмена данными

Все API-ответы возвращаются в формате JSON. Бинарные данные (изображения, файлы) передаются либо как multipart/form-data при загрузке, либо как бинарный поток при скачивании.
Данные метеостанций АСМО хранятся в виде XML-документов в поле file_content (StationArchiveSchema), разбор XML выполняется на стороне клиента (xmlParser.js).
Данные ПУИД хранятся в XML/JSON-отчётах, разбор которых выполняется на клиенте (puidReportParser.js).
4.3   Аутентификация и авторизация
bob_front: HTTP Basic Authentication. Клиент передаёт логин и пароль в каждом запросе в заголовке Authorization: Basic <base64>. Учётные данные фиксированы на уровне API-слоя клиентского приложения.
aist_front: OAuth2 Password Flow. 1. Клиент отправляет POST /api/token с логином и паролем (application/x-www-form-urlencoded, grant_type=password). 2. Сервер возвращает JWT Bearer token. 3. Токен сохраняется в localStorage (ключ asudd_token) и передаётся во всех последующих запросах в заголовке Authorization: Bearer <token>. 4. Управление контекстом аутентификации — AuthContext.jsx (React Context + useReducer).
Авторизация на уровне данных: сервис aist_front реализует многоуровневую модель доступа: - Принадлежность к site_id ограничивает видимость данных площадкой. - Поле regions ограничивает доступ к конкретным регионам. - Поле perm содержит детализированные права на конкретные операции. - Флаг is_officer и поля official_id, contractor_id, curator_id связывают пользователя с организационными ролями в бизнес-процессах.

4.4   Сопряжение двух бэкенд-сервисов на клиенте
Клиентское приложение работает одновременно с обоими сервисами. Логика распределения запросов сосредоточена в api.js: - Данные о наличии и базовых параметрах устройств — из bob_front. - Расширенные данные, управляющие операции, бизнес-объекты — из aist_front. - Обогащение данных (нормализация, расчёт статусов, геокодирование адресов) — в deviceManager.js на стороне клиента.
Пример: устройство ТПИ получает базовые атрибуты (координаты, тип, статус активности) из bob_front, а управление его сценариями и изображениями выполняется через aist_front.


5.   Архитектурные решения клиентского приложения5.1   Модульность и разделение ответственности
Слой             Модуль                  Ответственность
────────────────────────────────────────────────────────────
—
UI-компоненты     components/, modals/ Отображение, пользовательский ввод Логика приложения App.jsx                             Глобальное состояние, маршрутизация вьюх
Нормализация      deviceManager.js         Преобразование сырых данных API → внутренняя модель API-слой                         api.js                  Все HTTP-запросы, обработка ошибок, Auth
Сервисы           services/               Кэширование, автообновление, pub/sub
Утилиты           utils/                  Константы, работа с датами, геометрия, localStorage Статические данные data/                               Геоданные дорог, координаты КП, mock-данные
5.2   Типы устройств и расчёт статусов

5.3   Геопространственная функциональность
Карта реализована на базе библиотеки OpenLayers. Ключевые решения: - Кластеризация маркеров устройств с агрегацией статусов. - Фильтрация устройств по типу, маршруту, региону. - Оверлеи метеоданных: температура, осадки, ветер, видимость. - Окраска дорог по данным интенсивности движения (сегментный подход, roadColorSegments.js). - Километровые столбы — фильтрация по уровню масштабирования для оптимизации производительности. - Система координат: данные хранятся в WGS84 (EPSG:4326), OpenLayers работает в Web Mercator (EPSG:3857); перепроецирование через proj4 и встроенные механизмы OpenLayers.

5.4   Производительность и кэширование на клиенте


6.   Развёртывание системы
6.1   Топология развёртывания

6.2   Режимы работы
Dev-режим (разработка): - Запуск: npm run dev (Vite dev server) - Прокси Vite подставляет заголовки Basic Auth и проксирует запросы напрямую к сервисам - Поддерживается переключение на mock-данные (userSettings.mockDevices = true)
Production-режим: - Сборка: npm run build (создаёт статические файлы в dist/) - Статика раздаётся Nginx - API-запросы: /api/v2 переключается на прямой URL https://aist.ddsural.ru
7.   Сводная таблица технологий