Задача
Данные об автопарке хранились в системе мониторинга и отдельных Excel-выгрузках. Чтобы увидеть положение машин и связанные с ними события, диспетчер сопоставлял несколько источников. Заказчику нужен был один интерфейс с картой, сведениями по каждому автомобилю и событиями по заданным правилам. В нём также предстояло использовать доступные показания датчиков и анализировать аномалии. Решения оставались за диспетчером.
Что разработали
Мы разработали Fleet Monitor — диспетчерский интерфейс с картой, панелью машин и лентой событий. Серверная часть написана на Python и FastAPI, пользовательская — на Next.js, React и TypeScript. Данные хранятся в PostgreSQL, PostGIS и TimescaleDB. Для работы с базой используются SQLAlchemy и asyncpg, в серверной части также работает Redis.
Карта построена на react-leaflet и OpenStreetMap, компоненты интерфейса — на TailwindCSS и shadcn/ui. Правила обработки событий дополнены ML-классификацией аномалий и модулем прогноза простоев. Обработка, хранение и показ данных разделены. Какие именно показатели видит диспетчер, зависит от сведений в системе мониторинга.
Как работает
Координаты, показания датчиков и другие доступные сведения поступают в серверную часть и связываются с машинами. Fleet Monitor показывает их на карте и в карточках автомобилей. Когда срабатывает настроенное правило, в ленте появляется событие — например, по топливу, геозоне или простою. Модель дополнительно классифицирует аномалии, а отдельный модуль прогнозирует простои. Диспетчер просматривает всё в одном интерфейсе и решает, что делать дальше.
Результат
Карта, карточки машин и события теперь собраны на одном рабочем экране. Диспетчеру не приходится постоянно переключаться между интерфейсом ГЛОНАСС и Excel-выгрузками. Заданные правила формируют события, а инструменты машинного обучения помогают классифицировать аномалии и прогнозировать простои.
Ограничения и зависимости
Качество координат, показаний топлива и других данных зависит от трекеров, датчиков, связи и провайдера мониторинга. Правила событий нужно настраивать под процесс заказчика. Классификация аномалий и прогноз простоев могут ошибаться, поэтому их оценивает диспетчер. Если исходные данные неполны или неверны, интерфейс не восстановит недостающие показания.