Цифровой двойник города: эволюция платформ и архитектура данных
Цифровой двойник города начинается с неприятного вопроса на перекрёстке: почему транспортный алгоритм видит плотный поток машин, а система безопасности пешеходов — нет?

На бумаге у квартала есть подробная 3D-модель, у перекрёстка — десятки датчиков, но два слоя данных живут по разным часам. Светофор, камера, счетчик транспорта и датчик воздуха знают о городе разные вещи.
Современный цифровой двойник города ценен прежде всего синхронизацией таких слоев. Он получает телеметрию, связывает модели разных ведомств, моделирует последствия и возвращает управляющее воздействие в инфраструктуру. Статичная 3D-копия квартала сама по себе эту задачу не решает: между изображением и городом нужна постоянная связь с реальным объектом.
От 3D-копии к системе, которая чувствует город
Раньше цифровое моделирование мегаполиса часто означало красивый цифровой макет: здания, дороги, зеленые зоны, иногда работающие слои транспорта. Для презентации этого достаточно. Для управления городом требуется принципиально иной уровень сложности.
Ключевой сдвиг произошел во времени. Модель, обновленная раз в сутки, хранит исторический срез. Цифровой двойник получает события с датчиков, учитывает их последовательность, связывает показания с конкретными объектами и пересчитывает состояние системы. Скорость обновления зависит от задачи: состояние дороги можно обновлять поминутно, а конфликт на пересечении требует событийного режима.
Появились и новые требования к платформе. Она принимает поток телеметрии, хранит пространственные и временные связи, поддерживает сценарии, предоставляет отраслевым системам API и отслеживает качество данных. Здесь нужны журналирование, обработка ошибок, разграничение доступа и понятная трассировка решения: почему алгоритм изменил фазу светофора или выбрал другой маршрут для экстренной службы.
| Тип системы | Что она хранит | Связь с реальным городом | Основная роль |
|---|---|---|---|
| Статичная 3D- или BIM-модель | Геометрию зданий, сетей, инфраструктуры | Нет постоянной синхронизации | Проектирование, навигация, визуализация |
| Доменный цифровой двойник | Состояние объектов одной отрасли, прогнозы, сценарии | Потоковая телеметрия и обратная связь | Управление транспортом, энергетикой, зданиями |
| Федеративный цифровой двойник города | Связанные модели разных доменов и их общий контекст | Непрерывный обмен данными между независимыми системами | Координация решений на уровне города |
Главное отличие федеративной модели — ее способность учитывать соседние системы. Перекрёсток находится одновременно в зоне ответственности транспорта, электроснабжения, связи, благоустройства и безопасности. Когда эти участки соединены, инженер видит не набор несвязанных картинок, а единый объект с текущим состоянием.
Цифровой двойник оправдывает название только тогда, когда городские данные возвращаются в город решением, командой или изменившимся режимом работы.
При этом обратная связь не обязана означать прямое управление каждым устройством. Схема может подготовить рекомендацию, передать ее оператору или автоматически изменить сценарий. Важна замыкатость контура: модель отражает изменение, инфраструктура его выполняет, телеметрия подтверждает результат.
Стандарты ISO/IEC и ITU-T задают язык федерации
Архитектура данных цифрового двойника города собирается из нескольких стандартных контуров. Ни один из них не превращает город в единую машину. Их задача — согласовать понятия, модели и способ обмена информацией.
В ноябре 2023 года был опубликован ISO/IEC 30173:2023 «Цифровой двойник — Понятия и терминология». Стандарт разработан подкомитетом ISO/IEC JTC 1/SC 41, который занимается интернетом вещей и взаимосвязанными технологиями. Он задает единый понятийный аппарат и системный контекст, позволяя разным разработчикам одинаково описывать цифровой двойник, его связи с физическим объектом и обмен данными.
Семейство ISO/IEC 30145 развивает рамку для информационно-коммуникационных технологий умного города. Первая часть, ISO/IEC 30145-1:2021, появилась раньше остальных и сформировала исходный reference framework. Сегодня линия включает несколько частей, уточняющих архитектурные связи между городскими сервисами.
На уровне общей структуры работают:
- ISO/IEC 30182 — концептуальная модель данных умного города;
- серия ISO/IEC 5087 — городские онтологии, помогающие связывать понятия из разных предметных областей;
- ISO/IEC 30173:2023 — терминология и системный контекст цифровых двойников.
Телекоммуникационный контур задает ITU-T Y.4224. Эта рекомендация была утверждена 29 ноября 2023 года и определяет требования к объединению независимых цифровых двойников в федеративную систему умного города. В сферу ее действия попадают транспорт, энергетика, безопасность и другие домены.
Здесь проходит важная граница. Единого глобального стандарта всеобъемлющей архитектуры UDT пока нет. Международная нормативная база остается фрагментированной: геопространственные решения развиваются в OGC, общетехнические — в ISO/IEC, требования объединения систем — в ITU-T. Для города это означает необходимость явно выбирать профили совместимости и договариваться об идентификаторах, единицах измерения и временных метках.
Федерация цифровых двойников — это согласованный обмен контекстом между специализированными системами.
Практическая архитектура обычно включает несколько слоев:
1. Сбор данных. Коннекторы принимают события от датчиков, транспортных контроллеров, систем зданий и внешних источников.
2. Нормализация. События получают понятные идентификаторы, типы, единицы, время и сведения о происхождении.
3. Доменные модели. Транспорт, энергетика и другие отрасли строят собственные двойники и сохраняют управление собственными данными.
4. Федеративный слой. Он предоставляет соседним доменам необходимый контекст через API и согласованные модели.
5. Сценарии и управление. Платформа рассчитывает варианты, передает их в системы исполнения и сверяет результат с новой телеметрией.
Стандарты задают словарь и правила совместимости. Их внедрение требует еще городской дисциплины: владельца данных, порядка изменения схем, политики доступа, журнала решений. Без этого федерация превращается в красивый каталог дорогих дашбордов.
OGC: когда должен понимать место
Цифровая модель становится городской только после того, как в ней понятны дороги, здания, помещения, транспортные средства и точки установки датчиков. Геометрия показывает, где находится объект. Семантика объясняет, чем он является и как связан с соседями.
Open Geospatial Consortium развивает набор спецификаций, закрывающих разные части этой задачи.
| Спецификация OGC | Практическая роль в цифровом двойнике |
|---|---|
| CityGML 2.0 / 3.0 | Семантическое описание городских объектов и их пространственных отношений |
| IndoorGML | Моделирование внутренних пространств зданий и навигационных связей |
| SensorThings API | Связь описаний датчиков, их местоположения, наблюдений и метаданных |
| 3D Tiles | Потоковая доставка и отображение больших объемов трехмерных геоданных |
Каждая спецификация решает собственную задачу. CityGML связывает геометрию с городской семантикой. IndoorGML помогает ориентироваться внутри сложного здания, где обычная карта улиц внезапно заканчивается. SensorThings API описывает цепочку «датчик — местоположение — наблюдение — метаданные». 3D Tiles отвечает за эффективную передачу объемной геометрии в средства просмотра.
Представьте перекресток. Контроллер светофора сообщает о смене фаз, пешеходный счетчик — о числе пересекающих проход, а геоинформационная система — о границах участка. В сырых логах это три несвязанных сообщения. Федеративная модель связывает их через идентификатор объекта, единую временную шкалу и правила предметной области.
Именно здесь возникают городские слепые зоны. Один двойник называет перекресток транспортным узлом, другой использует кадастровый номер, третий хранит внутренний идентификатор объекта. Формально все системы описывают одно место, но не способны сопоставить свои события. Человек в интерфейсе видит несколько расходящихся счетчиков, а автоматика принимает решения по неполной картине.
Семантический слой помогает отделить «сырые показания» от «состояния города». Датчик может передавать только число, частоту измерения и время. Онтология связывает это с фазой светофора, направлением движения, типом перехода, погодными условиями и зоной ответственности. Благодаря этому транспортный двойник использует сведения о потоке машин, а модель безопасности — время ожидания и занятость пешеходного перехода.
Временная синхронизация здесь так же важна, как пространственная. Показание счетчика, снятое на несколько секунд позже, уже описывает иной этап цикла. Для управляющих сценариев нужны метки времени события, времени обработки и времени применения решения. Иначе цифровой двойник воспроизводит прошлое с высокой геометрической точностью.
Мюнхен, Гамбург и Лейпциг: город как набор модулей
Европейский проект Connected Urban Twins (CUT) объединил Мюнхен, Гамбург и Лейпциг вокруг общей задачи: сделать городские цифровые двойники совместимыми. В рамках проекта началась разработка DIN SPEC 91607 «Urban Digital Twin». Спецификация задает модель зрелости и типовую модульную архитектуру цифрового двойника города.
Модульность здесь выглядит практично. У транспорта, энергетики, зданий и безопасности остаются собственные модели, правила работы и темпы обновления. На уровне города работает слой, который помогает им находить друг друга, запрашивать данные и согласовывать решения.
Такая конструкция подходит мегаполису, где один отраслевой оператор физически не может обслуживать всю инфраструктуру. Муниципальная система может объединить городской транспорт, несколько управляющих компаний зданий, энергетиков и операторов связи. Каждый участник сохраняет ответственность за свой участок, а цифровой двойник обеспечивает общий контекст.
DIN SPEC 91607 следует рассматривать как архитектурный ориентир. Стандарт не сертифицирует готовность конкретного города и не гарантирует бесперебойную работу внедренной системы. Он показывает, как связывать разрозненные двойники без попытки собрать все данные в одной гигантской таблице.
Транспортный сценарий в такой архитектуре выглядит связно. Доменная модель получает состояние дороги, прогнозирует очередь и проверяет варианты управления. Подходящее решение поступает в систему контроля, затем цифровой двойник сверяет фактическую фазу, плотность и время проезда. Энергетическая или архитектурная модель может подключиться к тому же сценарию через согласованный контекст: например, получить внешний запрос мощности или ограничение режима работы объекта.
Ключевой механизм — общий каталог и правила обмена. Простое перечисление источников не создает федерацию. Каждый домен должен знать, какие данные предоставляет, какого качества они, с какой задержкой обновляются и кто отвечает за их корректность. Тогда сценарий можно воспроизвести, объяснить и улучшить.
Для платформы цифрового двойника модульный подход снижает зависимость от одного поставщика. Домены могут развиваться разными темпами, а городская федерация остается управляемой. Это ближе к реальному управлению инфраструктурой, где участники отвечают за разное, но обязаны договариваться о состоянии перекрестка, квартала или сети.
От умного дома к городскому контуру: роль ГОСТ Р
Локальный уровень цифрового города в России задает ГОСТ Р 71865-2024 «Системы киберфизические. Умный дом. Архитектура». Приказом Росстандарта от 26 декабря 2024 года стандарт был утвержден, а с 1 февраля 2025 года вступил в силу. Его разработкой занимался технический комитет ТК 194 «Киберфизические системы».
Стандарт посвящен интеграции локальных решений умных зданий в единые городские сервисы и платформы. Это важный участок общей архитектуры. Здание уже содержит датчики, контроллеры, инженерные системы и локальные сценарии. Городскому двойнику нужны их агрегированные состояние и управляемые воздействия.
Путь данных можно представить без чертежей. Датчик сообщает показание локальному контроллеру. Здание обрабатывает его и формирует состояние своих систем. Районный или городской сервис получает обобщенные данные, сопоставляет их с другими доменами и запускает сценарий. Команда возвращается через управляющий контур, а новые показания подтверждают результат.
На каждом переходе возникают технические требования. Идентификатор здания должен сохраняться при переносе между платформами. Время события следует отделять от времени его обработки. Единицы измерения должны быть явными. Права доступа лучше задавать на уровне сервиса и поля данных, а доступ к чувствительным сведениям — ограничивать по роли.
Киберфизическая архитектура требует также запасного поведения. При потере связи здание должно сохранять возможность выполнять критичные локальные функции: отключать перегруженное оборудование, поддерживать освещение, сигнализацию или безопасный режим инженерных систем. Когда канал восстанавливается, накопленные события передаются в городскую модель. Здесь проходит граница между отказоустойчивостью конкретного здания и согласованным управлением городским контуром.
Интеграция данных умного города становится реальной, когда локальные системы сохраняют автономность, а платформа предоставляет им единые контракты. Сементика, права и временная шкала здесь значат не меньше, чем количество подключенных устройств.
Что я ищу в цифровом двойнике с тротуара
Я смотрю на цифровой двойник как городской тестировщик: сначала спрашиваю, что человек почувствует на маршруте, и только потом смотрю на красивую трехмерную карту. Юзабилити такой системы проявляется в согласованности решений и предсказуемости их последствий.
Мне достаточно пяти вопросов к платформе:
1. Обновляется ли состояние без ручной правки модели? Событие от датчика должно проходить путь от источника до цифрового двойника и отражаться в его состоянии. Устаревшая витрина с привлекательной геометрией мало помогает оператору.
2. Можно ли объяснить решение? Платформа должна показать источники данных, их качество, временные метки и причину выбранного сценария. Объяснимость здесь часть рабочей юзабилити.
3. Замыкается ли контур? Изменение фазы или режима должно возвращаться в систему управления и отражаться в новой телеметрии.
4. Что происходит при сбое связи? Локальные операции, безопасность и критичная инфраструктура должны сохранять работоспособность.
5. Учитывается ли городской контекст? Сценарий на перекрестке обязан связывать транспорт, пешеходные потоки, погоду, состояние зданий и доступность экстренных маршрутов в пределах доступных данных.
Последний вопрос особенно важен. Цифровое моделирование мегаполиса часто начинается с транспорта, потому что там легко посчитать машины и очереди. Пешеход в этой системе часто остается вторичной фигурой. Его путь начинается на тротуаре и пересекает несколько зон ответственности, поэтому городскому двойнику нужны время ожидания, конфликтные интервалы, состояние перехода и данные о доступной среде.
Главный показатель зрелости платформы — качество совместного решения. Можно подключить сотни датчиков, построить детальную 3D-модель и собрать красивый мастер-план города. Пользователь оценит результат по простым вещам: сигнал меняется вовремя, аварийный маршрут остается свободным, ожидание на переходе сокращается, сбой не превращается в городскую слепую зону.
Цифровой двойник города прошел путь от статичной цифровой копии к федеративной системе с потоковой телеметрией, общей семантикой и управляющими контурами. ISO/IEC, OGC, ITU-T, DIN и ГОСТ Р формируют необходимую техническую грамматику. Город остается сообществом людей и организаций, которое должно пользоваться этой грамматикой без бюрократического пафоса.
Настоящий результат появляется, когда цифровая модель помогает горожанину пройти перекресток спокойно и предсказуемо. Тогда это инфраструктура. До этого — дорогой и эффектный экран.