Импульс к развитию
городов России
городов России
Видеть • Предсказывать • Действовать
IM:PULS(E) - комплексный информационный продукт, который поможет разобраться в вопросе цифровых двойников городов.
IM:PULS(E) - комплексный информационный продукт, который поможет разобраться в вопросе цифровых двойников городов.
От команды разработчиков
IM:PULS(E) — это руководство к действию.
Мы создали IM:PULS(E) как импульс и понятную точку входа в тему цифровых двойников: чтобы объяснить, что такое цифровой двойник, зачем он нужен городу, какие компетенции и каких специалистов требуются для его создания, внедрения и развития. Наша цель — сделать так, чтобы после знакомства с материалом у читателя сложилась ясная картина: от базовых принципов до практических шагов и ролей в команде.
IM:PULS(E) задуман не только как образовательный материал, но и как возможный старт для формирования сообщества и серии мероприятий (встреч, дискуссий, лекций и практических сессий), где будет регулярно и доступно освещаться тема цифровых двойников городов и смежные направления цифрового развития территорий.
IM:PULS(E) задуман не только как образовательный материал, но и как возможный старт для формирования сообщества и серии мероприятий (встреч, дискуссий, лекций и практических сессий), где будет регулярно и доступно освещаться тема цифровых двойников городов и смежные направления цифрового развития территорий.
Определение
Что такое цифровой двойник
Информационная система (или комплекс систем), агрегирующая и связывающая данные о территории/объектах и обеспечивающая управленческие сценарии на основе регламентированной актуализации данных.
- Признаки1. Актуальные данные
Источник, качество, частота обновления и ответственность.
2. Сценарии управления
Контроль, прогнозирование, реагирование и планирование.
3. Правила и роли
Доступы, регламенты, SLA и владелец процесса. - ПринципЦифровой двойник города =
данные + технологии + управленческие решения
Цифровой двойник — это не…
Правильно: 3D‑модель — объемное представление территории, компонент двойника, но не сам двойник.
ЦД = данные + процессы + обновление + доступы.
«3D — оболочка, Цифровой Двойник — живой инструмент управления».
ЦД = данные + процессы + обновление + доступы.
«3D — оболочка, Цифровой Двойник — живой инструмент управления».
Правильно: ГИС — система для хранения и анализа пространственных данных.
ЦД — управленческая система с актуализацией и ответственностью.
«ГИС — карта с данными, Цифровой Двойник — управление на данных».
ЦД — управленческая система с актуализацией и ответственностью.
«ГИС — карта с данными, Цифровой Двойник — управление на данных».
Правильно: Цифровая Модель — для анализа тенденций ("что будет если").
ЦД — про текущее состояние и контроль ("здесь и сейчас").
ЦД — про текущее состояние и контроль ("здесь и сейчас").
Глобальный контекст:
мировой и Российский опыт
Азиатская модель
Централизация "сверху-вниз". Платформа → данные → сценарии. (Китай, Сингапур, ОАЭ)
Инициатива "снизу-вверх". Проблемы → данные → город. (Нидерланды, Финляндия)
Европейская модель
Российская модель
системное внедрение инфраструктуры
и высокие государственные амбиции
и высокие государственные амбиции
масштаб (азиатская модель)
+
фокус на локальных болях, UX и быстрых, осязаемых эффектах.
быстрый эффект (европейская модель)
Гибридная стратегия, объединяя два подхода:
Типовой состав данных (21 компонент)
IM:PULS(E) — это стандартный набор слоев данных, который города могут адаптировать под себя. Невозможно создать один единый стандарт для всех
(у каждого города своя специфика), но можно определить базовый состав, который работает везде.
(у каждого города своя специфика), но можно определить базовый состав, который работает везде.
Стартовый набор
S
MVP для старта: цель — разрешить конкретную "боль".
Развитие города
M
M — масштаб: город активно использует систему, 5–10 процессов.
Полный масштаб
L
L — полный масштаб: аналитическая платформа.
Вывод: S, M, L — это не размер города, а уровень наполнения и зрелость цифрового двойника.
Маленький город может быть на уровне L, если у него есть полные данные и воля главы. Большой город может быть на S, если только начинает.
Уровень зависит не от численности, а от готовности данных, команды и политической воли.
Важно: «21 компонент» — это опорный состав (что обязательно должно быть), а не количество слоёв цифрового двойника: в реальном городе слоёв может быть 9 000+ в зависимости от задач и структуры данных.
Маленький город может быть на уровне L, если у него есть полные данные и воля главы. Большой город может быть на S, если только начинает.
Уровень зависит не от численности, а от готовности данных, команды и политической воли.
Важно: «21 компонент» — это опорный состав (что обязательно должно быть), а не количество слоёв цифрового двойника: в реальном городе слоёв может быть 9 000+ в зависимости от задач и структуры данных.
Для кого нужен цифровой двойник
Администрация
Быстрое принятие решений, управление в реальном времени.
Балансодержатели сетей
Ясность в расположении сетей, координация работ, предотвращение аварий.
Девелоперы
Быстрое согласование проектов, оптимизация стройплощадок, снижение коллизий.
Трафик и транспорт
Оптимизация потоков, перенаправление при авариях, планирование маршрутов.
Архитекторы
Проверка видимости, инсоляции, вписываемости зданий еще на стадии проекта.
Аналитики
Данные для исследований, стратегического планирования и оценки эффективности.
Примеры городов: реальный опыт
Собрано в рамках исследования и интервью с экспертами.
Проблема: мегаполис с предельной инженерной и организационной сложностью, где цена низкой производительности и несогласованных форматов очень высока. В части ЦД болит техническая дисциплина: LOD/mesh/форматы, требования к производительности по сценариям и «тяжёлые» входные документы (PDF).
Решение: задавать требования к LOD и производительности по сценариям, переводить входные документы в структурированные слои с метаданными и правилами обновления в составе MVP.
Результат: модель становится пригодной для регулярного использования, снижается ручной труд и ошибки от «неструктурированных» источников.
Вывод: масштабирование начинается со стандарта на данные/форматы/LOD и привязки требований к сценариям, а не с наращивания детализации.
Решение: задавать требования к LOD и производительности по сценариям, переводить входные документы в структурированные слои с метаданными и правилами обновления в составе MVP.
Результат: модель становится пригодной для регулярного использования, снижается ручной труд и ошибки от «неструктурированных» источников.
Вывод: масштабирование начинается со стандарта на данные/форматы/LOD и привязки требований к сценариям, а не с наращивания детализации.
Проблема: у города сильный стратегический контур развития и масштаб задач (мастер‑планирование и прикладные сценарии одновременно), поэтому нужна единая логика управления территорией. В части ЦД это упирается в режимность и ограничения по данным/источникам и правила доступа.
Решение: собирать MVP через KPI и use cases, а режимность закрывать матрицей по слоям и уровням доступа (публичная/служебная/закрытая витрина) и минимальным контрактом обмена.
Результат: система масштабируется итеративно, а качество и актуальность зависят не от «красоты 3D», а от правил доступа, источников и процессов обновления.
Вывод: кейс про связку «стратегия + прикладные сценарии» и критичность правового режима данных.
Решение: собирать MVP через KPI и use cases, а режимность закрывать матрицей по слоям и уровням доступа (публичная/служебная/закрытая витрина) и минимальным контрактом обмена.
Результат: система масштабируется итеративно, а качество и актуальность зависят не от «красоты 3D», а от правил доступа, источников и процессов обновления.
Вывод: кейс про связку «стратегия + прикладные сценарии» и критичность правового режима данных.
Проблема: приоритет — устойчивое обслуживание и эффективность городских сервисов, где результат должен быть виден в показателях и уровне сервиса. В цифровой части барьеры — организация и качество данных: роли, ответственность, процессы обновления и дисциплина эксплуатации важнее выбора софта.
Решение: фиксировать KPI по классам сценариев, вводить SLA и ролевую модель (владелец процесса/данных, оператор, валидатор), отдельно закрепляя требования к качеству данных.
Результат: система начинает работать как сервис с измеримым уровнем качества и ответственности, а не как набор экранов.
Вывод: успех определяется управляемостью (KPI+SLA) и качеством данных, а не объёмом 3D.
Решение: фиксировать KPI по классам сценариев, вводить SLA и ролевую модель (владелец процесса/данных, оператор, валидатор), отдельно закрепляя требования к качеству данных.
Результат: система начинает работать как сервис с измеримым уровнем качества и ответственности, а не как набор экранов.
Вывод: успех определяется управляемостью (KPI+SLA) и качеством данных, а не объёмом 3D.
Проблема: важно не просто запустить цифровую инициативу, а встроить её в понятную модель владения и эксплуатации, чтобы сервис жил годами. В части ЦД ключевые вопросы — экономика (TCO), shared service (кто владеет/кто обслуживает/как делятся затраты) и управляемое масштабирование.
Решение: начинать с каталога сценариев и владельцев процессов, затем MVP (карточка объекта, метаданные слоя, журнал изменений, базовые проверки качества) и дорожную карту развития.
Результат: появляется управляемая система с понятной экономикой и этапами развития, где эффект измеряется по KPI и сценариям.
Вывод: акцент на проектируемом внедрении — план, экономика и измеримый эффект.
Решение: начинать с каталога сценариев и владельцев процессов, затем MVP (карточка объекта, метаданные слоя, журнал изменений, базовые проверки качества) и дорожную карту развития.
Результат: появляется управляемая система с понятной экономикой и этапами развития, где эффект измеряется по KPI и сценариям.
Вывод: акцент на проектируемом внедрении — план, экономика и измеримый эффект.
Проблема: крупный город с высокой сложностью управления и большим числом участников, где особенно опасны разночтения терминов и целей. В части ЦД главный риск — подмена смысла, когда 3D‑визуализацию называют «двойником» без KPI, сценариев и границ понятия.
Решение: фиксировать термины и рамку на старте, затем собирать каталог сценариев и владельцев процессов, и только после — MVP и требования must have.
Результат: у команды появляется общий язык, критерии успеха и защита от «красивого, но бесполезного» решения.
Вывод: методология задаёт границы понятия «двойник» и удерживает проект в логике управления, а не презентации.
Решение: фиксировать термины и рамку на старте, затем собирать каталог сценариев и владельцев процессов, и только после — MVP и требования must have.
Результат: у команды появляется общий язык, критерии успеха и защита от «красивого, но бесполезного» решения.
Вывод: методология задаёт границы понятия «двойник» и удерживает проект в логике управления, а не презентации.
Проблема: город живёт в условиях сложной климатологии и повышенных природных рисков (землетрясения, паводки), поэтому критичны скорость реакции и точность пространственной картины. В цифровой части данные и контуры разрознены, много артефактов в Excel/PDF, и переход к единой модели данных требует понятной этапности.
Решение: идти от инвентаризации и верификации к MVP, фиксируя минимальный контракт обмена (даже через выгрузки) и дорожную карту внедрения по шагам.
Результат: город получает управляемый контур данных и сценариев, который можно расширять без попытки «сразу всё», снижая риски интеграций и организационных барьеров.
Решение: идти от инвентаризации и верификации к MVP, фиксируя минимальный контракт обмена (даже через выгрузки) и дорожную карту внедрения по шагам.
Результат: город получает управляемый контур данных и сценариев, который можно расширять без попытки «сразу всё», снижая риски интеграций и организационных барьеров.
Проблема: северный регион с высокой стоимостью ошибок в эксплуатации и сильной зависимостью от экономики, поэтому любые решения должны доказывать эффект и окупаемость. В части ЦД главные риски — TCO и организационная готовность контрагентов (межвед, форматы, ресурсоснабжающие).
Решение: описывать «двойник» как управленческий контур «KPI → use cases → MVP → эксплуатация/обновление → экономика», где MVP — это «слои + атрибуты + правила обновления» и минимальный контракт интеграции.
Результат: 3D/LOD становятся вторичными и определяются задачей, а основной эффект достигается через сценарии эксплуатации и управляемые данные.
Вывод: для ЖКХ «двойник» — это эксплуатационные сценарии и регламент обновления; визуализация вторична.
Решение: описывать «двойник» как управленческий контур «KPI → use cases → MVP → эксплуатация/обновление → экономика», где MVP — это «слои + атрибуты + правила обновления» и минимальный контракт интеграции.
Результат: 3D/LOD становятся вторичными и определяются задачей, а основной эффект достигается через сценарии эксплуатации и управляемые данные.
Вывод: для ЖКХ «двойник» — это эксплуатационные сценарии и регламент обновления; визуализация вторична.
Итог
Опыт городов России
Цифровые решения работает там, где есть цель.
Важно иметь реальные задачи, измеримые KPI, понятного "владелеца процесса", регламент по сбору и обработке данных.
Внимание на фундамент: качество данных, экономика владения (TCO) и модель эксплуатации (роли, SLA) важнее красивой картинки. 3D и детализация — это лишь производная от сценариев. Сначала задачи, потом формат. Иначе получается дорогая, но неиспользуемая система.
Важно иметь реальные задачи, измеримые KPI, понятного "владелеца процесса", регламент по сбору и обработке данных.
Внимание на фундамент: качество данных, экономика владения (TCO) и модель эксплуатации (роли, SLA) важнее красивой картинки. 3D и детализация — это лишь производная от сценариев. Сначала задачи, потом формат. Иначе получается дорогая, но неиспользуемая система.
Часто задаваемые вопросы
IM:PULS(E) — это набор рекомендаций по структуре данных (21 компонент), ролевой модели доступа, интеграционной архитектуре и базовым сценариям управления. Это не платформа (выбираете сами), а методология, как строить ЦД.
Стоимость зависит от исходного состояния города: размер, объем уже имеющихся данных, состояние городских систем и инфраструктуры. Масштаб проекта определяется не только числом жителей, но качеством и полнотой уже собранной информации. Система окупается за счет экономии: на авариях сетей, на оптимизации транспорта, на ускорении согласований и управленческих процессов.
Как правило, это GIS-платформы (ArcGIS, QGIS, Panorama) или специализированные Urban Suite / CityWorks. Выбор зависит от типа данных и бюджета. Главное — платформа должна позволять интегрировать данные из разных источников и масштабироваться.
- Базовые геоданные: ортофото, кадастр, ПЗЗ — они есть почти везде.
- Источник боли: если проблема в авариях сетей, то начните с сетей; если в очередях на согласование, начните с разрешений.
- Готовность ресурсников: спросите, кто может поделиться актуальными данными на текущий период и в перспективе может предоставлять актуальные обновляемые данные.
Нет. 3D ускоряет понимание и красит презентации, но это не основное. Главное — данные и процессы. Начните с 2D (карта + слои + карточки объектов), 3D добавляйте, когда есть бюджет и четкий сценарий (АГО, видимость, моделирование).
Несколько путей:
- Закон: обязательный обмен данными (как в ГИСОГД).
- Выгода: показать, что система помогает им координировать работы и предсказывает аварии.
- Льготы: облегчить подключение, помочь с форматом, оплатить интеграцию.
- Доверие: гарантировать конфиденциальность чувствительных данных.
Стандартные требования: разграничение доступа по ролям, шифрование, аудит действий, резервные копии. Часть данных может быть в закрытом контуре (сети, рельеф, критическая инфраструктура). Открытые данные (благоустройство, события) — в публичной части.
Команда разработчиков
- Мутинцев Владимирг. Салехард
Заместитель начальника управления архитектуры и градостроительства, Депстрой ЯНАО - Упаловский Юрийг. Санкт-Петербург
Начальник геодезического отдела управления ведения фонда пространственных данных и инженерных изысканий ЦИОГД Санкт-Петербурга - Зазымкина Иринаг. Воронеж
Архитектор уличных пространств, главный архитектор проектов благоустройства, руководитель проектов, бюро Тепло, ZRM/Зримо - Рябченко Ульянаг. Липецк
Архитектор, бюро IND - Поляков Алексейг. Йошкар-Ола
Заместитель мэра по строительству - Магомедов Эльдарг. Махачкала
Директор МБУ «Геоинформационный центр»