Для городской системы сначала рисуем архитектуру, потом говорим об оборудовании.
Результат этого плана — городская интеллектуальная система, которую можно строить по этапам, менять поставщика и эксплуатировать долгосрочно: интеллектуальный операционный центр видит обстановку всего города, платформенный слой управляет данными и интерфейсами, а транспорт, общественная безопасность, аварийные и муниципальные услуги запускаются по одному проекту.
Четыре частые ловушки городских проектов
Большинство проблем — не в технологии, а в структуре закупки.
Каждое подразделение покупает своё
Транспорт, аварийные и муниципальные службы строят каждая свою платформу, данные не сообщаются, и у командного центра в итоге остаётся только большой экран.
Привязка к одному вендору
Интерфейсы не открыты, данные не экспортируются; сменить поставщика на втором этапе — значит снести всё и начать заново.
Список оборудования никто не проверяет
Источники камер и сетевого оборудования сложны; проблемы соответствия цепочки поставок обнаруживаются только после тендера.
Построили — эксплуатировать некому
Приёмка — это пик; на дежурство, повторные проверки и обновления нет бюджетной строки, и система устаревает за два года.
Состав архитектуры
Один центр, одна платформа, N приложений. Каждый уровень принимается отдельно.
Интеллектуальный операционный центр (IOC)
На ядре обстановки делает обстановку всего города, распределение событий и аварийное командование. Дежурный видит события, ожидающие реагирования, и доказательства, а не собранный из кусков большой экран.
- Сведение и распределение событий всего города
- Карта обстановки и доказательства на одном экране
- Процесс аварийного командования и диспетчеризации
- Дежурство и передача смены оставляют след на всём протяжении
Городской платформенный слой
Единая идентификация, каталог данных, стандарты API и шина сообщений; системы подразделений подключаются по стандарту, новые приложения больше не строят основу заново.
- Единая идентификация и права должностей
- Каталог данных и критерии статистики
- Стандарты API и шина сообщений
- Нормы подключения подразделений и критерии приёмки
Модуль цифрового двойника
Отображает объекты, дорожную сеть и события в городскую модель, которую можно запрашивать; сначала служит диспетчеризации и учениям, затем расширяется на планирование.
- Моделирование объектов и дорожной сети
- Отображение событий и запросы
- Сначала диспетчеризация и учения
- Приложения планирования расширяются следом
Группа сценарных приложений
Транспортные сигналы и события, восприятие общественной безопасности, диспетчеризация аварийных ресурсов и заявки муниципальных услуг запускаются по одному проекту; у каждого — свои критерии приёмки.
- Транспортные сигналы и реагирование на события
- Восприятие общественной безопасности
- Диспетчеризация аварийных ресурсов
- Заявки муниципальных услуг
Список модулей, заказываемых по отдельности
Целое — это архитектура, заказ — по модулям: каждый можно подписать и принять отдельно, купленные позже подключаются по тому же платформенному слою.
| Модуль | Что включает | Результат отдельной приёмки |
|---|---|---|
| Интеллектуальный операционный центр (IOC) | Сведение и распределение событий, карта обстановки и доказательства на одном экране, процесс командования и диспетчеризации, след дежурства и передачи смены | Акт приёмки запуска IOC и регламент дежурства |
| Городской платформенный слой | Единая идентификация и права должностей, каталог данных, стандарты API и шина сообщений, нормы подключения подразделений | Документ стандартов интерфейсов и записи приёмки подключения |
| Модуль цифрового двойника | Моделирование объектов и дорожной сети, отображение событий и запросы; сначала служит диспетчеризации и учениям | Список моделей и записи приёмки запросов |
| Пакет транспортного сценария | Координация транспортных сигналов и процесс реагирования на транспортные события | Акт приёмки сценария и образцы записей реагирования |
| Пакет диспетчеризации аварийных ресурсов | Реестр аварийных ресурсов, процесс диспетчеризации и поддержка учений | Регламент диспетчеризации и записи учений |
| Пакет заявок муниципальных услуг | Процесс приёма, назначения, завершения и обратного визита по муниципальным заявкам | Акт приёмки процесса заявок |
| Пакет управления данными и экспорта | Словарь данных, критерии статистики и проверка экспорта — гарантия, что при смене поставщика всё можно забрать | Словарь данных и записи проверки экспорта |
Как подключается платформа
Городские проекты повторно используют основы всей линейки, не начиная с нуля.
Ядро обстановки
События, сущности и временные линии IOC берутся из единого ядра; продукты разведки и оповещения могут поставлять данные напрямую.
KINGAI ID, организационная версия
Права подразделений, должностей и операторов разделены; вход городских услуг и внутренний рабочий стол разделены.
Операционная платформа ONE
Мониторинг, реагирование и повторные проверки после запуска ведутся со следом; муниципальные клиенты ежемесячно получают эксплуатационные записи.
Путь поставки
Плата за проектирование может быть отдельным заказом или засчитываться в последующее внедрение. Каждый шаг оставляет результат, который можно принять.
Обследование текущего состояния
Инвентаризируем существующие системы, данные и список оборудования; проверка соответствия идёт синхронно.
Результат: отчёт инвентаризации текущего состояния (списки систем, данных и оборудования, выводы проверки соответствия).
Общее проектирование
Архитектура, стандарты интерфейсов, управление данными, список этапов и критерии эксплуатации фиксируются разом.
Результат: документ общего проектирования (архитектура, стандарты интерфейсов, управление данными, список этапов, критерии эксплуатации).
Поэтапное внедрение
Строим и принимаем по приложениям; каждый этап поставляет словарь данных и проверку экспорта.
Результат: каждый этап поставляет само приложение, словарь данных, записи проверки экспорта и акт приёмки.
Сопровождение эксплуатации
Процесс дежурства IOC, повторные проверки и обновления входят в долгосрочную эксплуатацию; точки заменяемости поставщика пересматриваются ежегодно.
Результат: ежемесячный отчёт эксплуатации, записи повторных проверок, ежегодная таблица пересмотра точек заменяемости поставщика.
- Проектное решение можно купить отдельно, без привязки к внедрению; внедрение подписывается по этапам, эксплуатация — по годам.
- Решение поставляется с тройкой локализации: локальный партнёр, локальное развёртывание, локальные источники контента.
- Зарубежные городские проекты входят через генерального интегратора или цепочку поставок локального партнёра и по каждой сделке проходят оценку экспорта и местного права.
Позиция по открытости и соответствию
Городская система работает десять лет; договор должен думать о десятом годе.
Условия против привязки
Открытые API, экспорт данных и содействие при выходе прописаны в договоре; тендер второго этапа не заложник первого.
Оборудование проходит отбор
Оборудование и компоненты проходят проверку Section 889 по пунктам с записями; проверка собственности на просвет покрывает чувствительных поставщиков.
Резидентность данных
Городские данные резидентны по юрисдикции; развёртывание — на выбор локально или в выделенной сети, схема ключей фиксируется на этапе проектирования.
Ограничение использования — в договоре
Дизайн приложений общественной безопасности не включает генерацию шаблонов распознавания лиц и функции масштабного персонального мониторинга; ограничение использования прописано в договоре.
Частые вопросы
Как подключить существующие системы подразделений?
Подключаем по стандартам платформенного слоя, без сноса и начала заново. Платформенный слой сначала определяет единую идентификацию, каталог данных и стандарты API; системы подразделений стыкуются по одной, новые приложения строятся напрямую на стандартах и больше не строят каждая свою основу.
Как резать этапы, чтобы не тратить впустую?
Сначала платформенный слой и IOC, затем сценарные приложения запускаются по одному проекту. Каждый этап принимается отдельно, с поставкой словаря данных и проверки экспорта; результаты предыдущего этапа не отменяются следующим, а список этапов фиксируется разом на этапе общего проектирования.
Кто выдаёт отчёт по проверке оборудования?
Выводы проверки вносятся в отчёт инвентаризации текущего состояния. Оборудование и компоненты проверяются по пунктам по Section 889 с записями; по чувствительным поставщикам дополнительно проводится проверка собственности на просвет, выводы поставляются вместе с отчётом инвентаризации.
Чьи люди дежурят в IOC?
Возможны оба варианта; фиксируется в критериях эксплуатации. Дежурить может команда города, наше сопровождение или смешанное расписание; кто бы ни дежурил, реагирование и передача смены оставляют след на всём протяжении, эксплуатационные записи подаются ежемесячно.
Кому в итоге принадлежат данные?
Городские данные принадлежат городу и резидентны по юрисдикции. Развёртывание — на выбор локально или в выделенной сети; схема ключей фиксируется на этапе проектирования, экспорт данных и содействие при выходе прописаны в договоре.
Можно купить только проектирование?
Можно: проектирование может быть отдельным заказом, без привязки к внедрению. Внедрение подписывается по этапам, эксплуатация — по годам; порядок зачёта платы за проектирование в последующее внедрение прописан в договоре проектирования.
Что смотреть дальше
Доверие и соответствие
Формы развёртывания, суверенитет данных, безопасность эксплуатации, проверка цепочек поставок и границы использования — собрано в одном месте.
Ядро разведки и обстановки
Обстановка IOC берётся из сети разведки из открытых источников; сначала посмотрите, как организуются данные.
Оповещение о бедствиях и общественной безопасности
Аварийность — первый высокочастотный сценарий IOC; сначала подключаемся от оповещения.
Начните с одной инвентаризации текущего состояния
Укажите масштаб города, список существующих систем и два сценария, которые хотите решить первыми: сначала ответим черновиком архитектуры и критериями этапов.
