Разрозненные источники
ГЛОНАСС и скорость — отдельно, бортовые камеры — отдельно, выявление сонливости — отдельно. Диспетчер получает набор несвязанных сигналов.
Концептуальный проект • Версия 1.0 • 16 октября 2026 года
SafeDrive — превентивная безопасность пассажирских перевозок
Единая система оценки риска, которая объединяет признаки внимания водителя, доступные физиологические показатели, движение транспорта и дорожный контекст. Цель — выявлять опасные сочетания до критического инцидента и давать водителю и диспетчеру объяснимый сигнал.
Система не ставит медицинский диагноз, не заменяет обязательные осмотры и не является самостоятельной системой управления транспортным средством.
Три уровня реакции
Конкретные пороги и критерии определяются после исследований и согласования регламентов.
Норма
Фоновое наблюдение и история событий без избыточных уведомлений.
Предупреждение
Локальный сигнал водителю, при необходимости — уведомление диспетчера и рекомендация проверки.
Критический инцидент
Приоритетная тревога и протокол диспетчерского реагирования. Автоматическое управление транспортом не предусмотрено в MVP.
Проблема
Сигналы есть, общей картины нет
Перевозка пассажиров связана с высокой ответственностью водителя. Утомление, снижение концентрации, внезапное ухудшение самочувствия и отвлечение могут влиять на безопасность наряду с дорожными условиями. Отдельные средства контроля обнаруживают лишь часть этих факторов.
Изолированный сигнал не равен опасности
Повышенный пульс не означает потерю работоспособности, закрытые глаза на одном кадре не доказывают засыпание, а допустимая скорость не гарантирует безопасность перед перекрёстком.
Нужен дорожный контекст
Опасность зависит от сочетания состояния человека, поведения транспорта и обстановки: приближение к перекрёстку, ограничения, свежесть дорожных данных.
Решение
Единая оценка риска, а не набор тревог
SafeDrive — не «умный браслет», не отдельная видеокамера и не навигатор. Это система, в которой каждый источник данных дополняет другие, а риск рассчитывает собственный объяснимый Risk Engine.
Состояние и внимание водителя
Признаки закрытия глаз, длительности моргания, нетипичного положения головы и сниженного внимания. Доступные показатели носимых устройств: пульс и температура кожи. Измерение давления — только совместимым валидированным устройством.
Движение транспортного средства
Фактическая скорость, положение на маршруте, направление движения, резкие ускорения и торможения, своевременность реакции на дорожные условия в пределах измеримых показателей.
Дорожный контекст
Разрешённая скорость при наличии лицензированного источника, приближение к перекрёсткам и потенциально опасным участкам. Фазы светофоров — только там, где существуют законные и достоверные источники данных.
GigaChat может разъяснять события и готовить отчёты, но не принимает единоличные решения о пригодности водителя к работе или командах управления транспортом.
Принцип работы
От датчика до диспетчера — с локальной автономностью
Критическая обработка выполняется на борту. Облако не участвует в цикле локального предупреждения, поэтому потеря связи не отключает основные функции безопасности.
Бортовой модуль
Камера в кабине, носимые датчики, GNSS и разрешённый телеметрический шлюз. Локальные правила формируют предупреждение водителю без ожидания ответа облака, картографии или GigaChat.
Защищённый канал передачи
Телеметрия, тревоги, статусы и выборочные видеофрагменты. Видеофрагменты передаются по отдельной политике, а не потоком по умолчанию; предусмотрены контроль целостности и повторная отправка.
Cloud.ru — центральная платформа
Приём и нормализация данных, привязка к рейсу и водителю, Risk Engine, дорожный контекст, журнал событий и API для диспетчерского интерфейса.
Диспетчерский центр
Карта транспорта, карточка события с факторами риска и качеством источников, приоритетная лента инцидентов, квитирование и журнал действий.
При потере связи локальные предупреждения продолжают работать, а данные ставятся в очередь для последующей отправки, если это допустимо. Отказ датчика маркируется как техническая неопределённость, а не как подтверждённое ухудшение здоровья.
Архитектура
Компоненты и границы системы
Архитектура разделяет бортовой контур, облачную платформу, внешние сервисы и диспетчерское рабочее место. Каждый внешний сервис подключается через адаптер и может быть заменён.
Бортовой контур
Работает независимо от облака. Критическая тревога формируется локально.
Камера в кабине
Бортовой модуль
Носимые датчики
GNSS
Телеметрия
Локальное предупреждение
Cloud.ru — предлагаемая центральная платформа
Приём, корреляция, риск-мониторинг, хранение событий и API. Конкретные облачные сервисы и тарифы требуют проверки.
Device Registry
Ingestion API
Risk Engine
Road Context
Notification Service
Audit & Reports
Внешние сервисы — предлагаемый стек
Не официальные партнёры проекта; коммерческие условия и доступность API не согласованы.
GigaChat — объяснения
Яндекс MapKit/NaviKit — карты и дорожный контекст
Городская АСУДД — фазы светофоров при наличии интерфейса
Диспетчерский центр
Приоритетные события, карточка риска и прослеживаемый журнал действий.
Карта транспорта
Статус мониторинга
Факторы тревоги
Квитирование
История и отчёты
Камера и уведомления не должны создавать избыточное отвлечение водителя. Передача данных во внешние сервисы выполняется через отдельный адаптер с минимизацией идентификаторов.
Бизнес-модель
B2B/B2G: оснащение и подписка
SafeDrive предлагается как сервис для операторов пассажирского транспорта: бортовой мониторинг и облачная диспетчерско-аналитическая платформа. Пассажиры не являются плательщиками.
Кому предназначена система
- Муниципальные автобусные парки и городские заказчики.
- Частные городские перевозчики и региональные операторы.
- Трамвайные и троллейбусные депо — после адаптации оборудования.
- Метрополитен и ЖД городской транспорт — отдельный продуктовый контур.
Коммерческая логика
Разовое оснащение и внедрение плюс подписка за активное транспортное средство. Покупатель — транспортное предприятие или уполномоченный городской заказчик. На первом этапе предусмотрен ограниченный пилот с измеримыми показателями, затем решение о закупке и расширении.
Что проверяется на пилоте
- Время доставки тревожного события диспетчеру.
- Ложные и пропущенные срабатывания.
- Полнота факторов в карточке инцидента.
- Работа локальных предупреждений при потере связи.
- Стоимость облака, связи и поддержки на одну машину.
Границы экономической модели
Финансовые значения в концепции — модельные допущения, а не подтверждённые тарифы поставщиков. Точка безубыточности, LTV и CAC требуют реальных данных о привлечении, удержании и длительности контрактов.
Ограничения и этика
Безопасность начинается с границ
Система проектируется как информационный и диспетчерский инструмент. Она не подменяет ответственных специалистов и не принимает решения о допуске водителя к работе.
Система не проводит медицинское освидетельствование, не заменяет обязательные осмотры и не устанавливает диагнозы.
Автоматическое торможение или блокировка движения не входят в MVP; в перспективе возможны только через проверенные и разрешённые средства производителя транспорта.
Физиологические сведения относятся к чувствительной информации. Необходимы законные основания обработки, ограничения доступа, сроки хранения и защита персональных данных.
Не допускается автоматическое наказание или дискриминация водителей на основании непрозрачной оценки модели.
Актуальность дорожных данных и задержки связи учитываются явно. Отсутствие данных не должно создавать ложной уверенности.
Отказ или отсутствие показаний датчика маркируется как техническая неопределённость, а не как подтверждённое ухудшение здоровья.
Следующий шаг
Ограниченный пилот без вмешательства в управление
После демонстрации концепции предусмотрены испытания на симуляторе, проверка точности датчиков и моделей, ограниченный пилот в транспортной организации и проверка правовых оснований обработки данных. Только затем — проработка промышленного применения.
Потенциальный социальный эффект — сокращение времени обнаружения опасных состояний, повышение информированности диспетчера и развитие профилактической работы. Масштаб эффекта нельзя оценить без реальных пилотных испытаний и статистики.
Изучить архитектуру- Стендовые тесты потери канала.
- Сравнение с утверждёнными тестовыми кейсами.
- Замер задержки события до диспетчера.
- Оценка полноты факторов инцидента.