Цифровой двойник локомотива
Телеметрия паркаапрель 2026
Видеть износ узлов до поломки
КТЖ предложила сделать цифровой двойник для электровоза KZ8A и тепловоза TE33A. Двойник должен непрерывно получать телеметрию, оценивать накопленный износ узлов и заранее предупреждать диспетчера о перегреве, просадке напряжения контактной сети или отказе турбонагнетателя.
Борт, брокер и диспетчерская
Каждый локомотив работает в своём контейнере: FastAPI-сервис симулирует датчики, считает риск по каждому узлу и публикует пакеты в MQTT. Сервер диспетчерской подписан на брокер EMQX, раз в минуту агрегирует данные в PostgreSQL и отдаёт REST и WebSocket для дашборда.
- Python
- FastAPI
- MQTT (EMQX)
- WebSocket
- PostgreSQL
- Docker
if risk_type == "linear_hi":
warn: float = comp_cfg["warn"]
crit: float = comp_cfg["crit"]
if value <= warn:
return 0.0
if value >= crit:
return 1.0
return _curve((value - warn) / (crit - warn), exponent)- 01 / 03
MQTT между бортом и диспетчерской
Локомотив публикует телеметрию в топик loco/{id}/telemetry и не знает, кто её читает. Новый потребитель подключается к брокеру без изменений на борту.
- 02 / 03
Пороги узлов в конфиге
Пороги и тип риска для каждого узла лежат в YAML: рост выше нормы, падение ниже нормы или выход из коридора. Показатель степени задаёт форму кривой, так что слабые отклонения почти не влияют на износ.
- 03 / 03
Агрегация вместо сырого потока
Дашборд получает живой поток по WebSocket, а в базу раз в 60 секунд пишется агрегат. История остаётся компактной.
Урок
Что бы сделал иначе
Я не нашёл техническую документацию локомотивов, хотя она лежала в открытом доступе, и задал пороги без опоры на неё. Команды-конкуренты глубже разобрались в устройстве локомотивов и сделали более сильный визуал. В следующий раз начну с документации предметной области и только потом сяду за код.