Реализация «зонтичной» концепции умного города в большинстве случаев проходит через ряд этапов. Сначала городскими или региональными властями ставится задача, затем она отображается в наборе формальных методик, правил и стандартов, согласно которым будет строиться поддерживающее ее информационное решение. Далее мы говорим об ИТ-архитектуре и соответственно о выборе инфраструктурных компонентов и прикладного программного обеспечения. И наконец приступаем к работе.

Большой и очень важной подгруппой задач, которые на сегодня, пожалуй, наиболее тесно ассоциируются со строительством умных городов, является обработка данных фотовидеофиксации. Первоначально этот процесс в большинстве случаев ассоциировался с отдельными вопросами обеспечения безопасности. Сегодня же со стороны ряда региональных властей явно ощущается желание подходить к проблеме комплексно, сводя решение различных задач фотовидеофиксации в единую систему обработки данных наблюдения, что имеет прямое отношение к развитию системы управления городской средой в целом.

При этом весьма существенно трансформируются требования и к инфраструктуре, и к прикладному ПО, и к методологиям ведения проектов.

Ситуация сегодня

Неким прообразом рассматриваемых нами решений, как известно, являлись радарные комплексы контроля транспортных потоков, а также датчики движения, используемые в системах безопасности. В обоих случаях мы имели фиксацию неких пространственных изменений в реальном времени, но еще не получали изображение как таковое. В дальнейшем стали создаваться специализированные комплексы, в которых изображение обрабатывалось встроенным системным ПО и в результате конвертировалось в некоторые события (на практике очень часто связанные с нарушением правил дорожного движения), впоследствии поступающие на рассмотрение компетентных органов.

Сначала подобные комплексы передавались в регионы бесплатно по федеральной программе и эксплуатировались органами ГИБДД. В этом собственно и заключался механизм их массового внедрения в практику.

Со временем ситуация изменилась. На рынке появилось довольно много комплексов фотовидеофиксации, решающих схожие задачи, но различающихся по стоимости, архитектуре построения, а также по семантике и формату выдачи данных потребителю. Параллельно с этим ширился спектр задач, которые региональные власти стремились (и получали возможность) решать с помощью систем видеонаблюдения. Возникла потребность в наблюдении не только за движением транспорта на перекрестках, но и за пешеходными переходами, парковками, а вслед за этим и за другими объектами, уже совсем не относящимися к организации дорожного движения. Так, в опубликованных в нашем издании материалах упоминалось, например, наблюдение за функционированием городских строительных площадок, придомовых территорий, организация контроля за вывозом мусора в городе и некоторые другие. И любой из подобных сценариев точно так же предполагает предварительную обработку получаемых с камер изображений, выделение интересующих заказчика событий, долговременное хранение фотовидеоматериалов, а наряду с этим автоматизацию бизнес-процессов, запускаемых в связи с наступлением событий, фиксируемых техникой.

В какой-то момент ответственность за практическое освоение поставляемых в регионы видеокомплексов от ГИБДД перешла к местным властям. Как следствие они получили возможность комплексно заниматься вопросами фотовидеофиксации, применяя их для решения самых разных задач городского масштаба, связывающих воедино множество независимых комплексов видеонаблюдения. А вместе с тем обозначились и проблемы.

Во-первых, они возникли в сфере архитектуры ИТ-решений: отдельные фотовидеокомлексы, вполне самодостаточные для фиксации тех или иных событий, необходимо было увязать в единый надежно функционирующий «организм».

Во-вторых, появилась необходимость не ограничивать информационную поддержку решений фиксацией событий, а максимально глубоко покрывать ею все этапы бюрократии, связанной с их последующей обработкой.

Архитектурные аналогии

Хорошим примером представленных тенденций служит эволюция применения программно-аппаратных фотовидеокомплексов для контроля за транспортной ситуацией в городах.

Количество данных решений, с точки зрения ИТ-архи­тектуры составляющих своего рода первичный слой ИТ-поддержки, сегодня уже достигло определённой критической массы, достаточной для их классификации по типам. Некоторые из них фактически являются прямым аналогом известных из «классической» ИТ-архитектуры тонких клиентов. Они осуществляют съемку объектов и передают «сырые» данные в ЦОД, во всем остальном уже полагаясь на его мощности.

Существуют более сложные решения, способные связать данные от нескольких камер, фиксирующих один сценарий (скажем, полный маневр автомобиля на перекрестке) с разных точек наблюдения. Такие комплексы должны иметь «собственный» вычислительный ресурс как минимум для стыковки показаний. А кроме этого, задействуя его, можно решать задачу автоматического распознавания номера автомобиля, выделять на фотографии стандартные объекты, сжимать исходные изображения в более компактные форматы для их передачи по сети и т. д. В результате в составе некоторых комплексов явно обозначается некий промежуточный слой, в традиционной терминологии ИТ-архитекторов обычно называемый middleware.

Формат представления данных разных комплексов тоже неодинаков. Они могут выдавать потребителю видеоданные в разных графических форматах, могут, скажем, поддерживать или не поддерживать технологию Web-сервисов, ориентироваться на различные XML-схемы и т. д. В итоге уже на базовом слое архитектуры решение может представлять собой некий симбиоз, который на жаргоне ИТ-архитекторов часто определяется как «лоскутное одеяло» или «зоопарк».

Верхним архитектурным слоем системы обработки данных фотовидеофиксации на муниципальном уровне является ЦОД с развернутым на его мощностях прикладным программным обеспечением. Тут понятием­-аналогом из области классической ИТ-архитектуры является, пожалуй, сервер приложений. Иными словами — сервер, который «оркеструет» сообщения от клиентов (реальных пользователей или же автоматики) в рамках функционала с единой прикладной логикой.

От события к процессу

Отдельный вопрос построения на основе фотовидеокомплесов интегрированных систем, решающих конкретные задачи городского управления, состоит в расширении информационной поддержки с первичной обработки событий до полной автоматизации соответствующих бизнес-процессов. Хорошим примером снова является развитие систем автоматизированного контроля ситуации на дорогах. В рассматриваемом нами случае информация о нарушениях правил дорожного движения должна порождать процессы взыскания штрафов, которые порой оказываются непростыми и длительными. Сюда также может вовлекаться большое число независимых исполнителей (ГИБДД, «Почта России», Служба судебных приставов и т. д.), деятельность которых должна быть максимально синхронизирована. И надо сказать, что такие задачи вплоть до последнего времени оставались практически неавтоматизируемыми.

«Идеальная» система

К определенному моменту в построении решений уровня городского управления с использованием комплексов фотовидеофиксации сложилась своего рода переломная ситуация. Дело в том, что раньше как созданием, так и эксплуатацией подобных решений в основном занимались специалисты по безопасности. В этой области и заказчики, и исполнители редко уделяли серьезное внимание таким вещам, как архитектура решений, методология управления проектами или описание бизнес-процессов. И тем и другим всё это в большинстве случаев было не слишком необходимо.

Теперь же, по мере существенного расширения сферы применения фотовидеокомплексов за пределы вопросов безопасности, для муниципальных заказчиков понятия ИТ-архитектуры и сквозного бизнес-процесса становятся все более осязаемыми. Инициатива в проведении таких проектов и их исполнение переходят под эгиду компаний, «выросших» на решении задач автоматизации корпоративного уровня. В этой среде с данными понятиями были знакомы давно, и опираясь на этот факт постараемся представить некое видение идеального с нашей точки зрения ИТ-решения и «правильного» проекта.

Что касается решений, то существование нижнего слоя инфраструктуры, состоящего из разнородных комплексов фотовидеофиксации, которые сделаны разными производителями в соответствии с различными техническими подходами, примем за аксиому. Далее очень важно сделать следующие акценты.

Базовая инфраструктура проекта на всех уровнях должна быть масштабируемой. Количество поступающих на вооружение городов видеокомплексов быстро растет, но это только часть проблемы. Новые разработки для контроля дорожной ситуации, как правило, рассчитаны на то, чтобы фиксировать все случаи проезда транспортных средств через тот или иной рубеж, а не только факты нарушений. Это сразу расширяет необходимый функционал прикладного ПО и увеличивает требования к ресурсам централизованного хранения информации в десятки, если не в сотни раз. В крупном региональном центре за сутки число событий, о которых мы говорим, легко может перевалить за миллион, и это не говоря о развитии других ветвей возможного использования видеокомплексов при автоматизации городского управления. Поэтому при любых попытках формирования прикладной системы муниципального масштаба очень важно не отделять вопрос создания программной поддержки от планов по развитию цент­рализованной ИТ-инфраструктуры, или, иными словами, от технологии ЦОДов, мощностями которых город может распоряжаться.

Что касается программных решений, то здесь основными на сегодня тенденциями являются следующие.

  • Создание в рамках прикладной системы промежуточного архитектурного слоя, позволяющего подключать комплексы любого производителя. Ситуация со стандартизацией была и пока, к сожалению, остается весьма проблемной. А при сегодняшней востребованности комплексных решений муниципального уровня ИТ-архитектура, в которой несовместимость стандартов на уровне работы с аппаратурой распространяется на все вышележащие слои, оказывается просто тупиковой.
  • Максимальное насыщение прикладного уровня возможностями для формирования отчетности.

На уровне организации работы комплексов фотовидеофиксации такая отчетность позволяет определять (в некоторых случаях даже в проактивном режиме) связь надежности и качества сбора первичной информации с качеством решения конкретных прикладных задач.

На прикладном уровне отчетность помогает оперативно выявлять узкие места управленческих бизнес-процессов. Если мы говорим о собираемости штрафов за нарушение правил дорожного движения, то очень полезно знать, например, сколько времени определенный сотрудник тратит на обработку того или иного документа, на каком этапе скапливается наибольшая «очередь», какая часть штрафов оплачивается, а сколько направляется в суд и пр. В отношении работы информационной системы речь по сути идет о формировании подробных логов событий, порождаемых уже не на уровне фиксации правонарушений, а непосредственно в слое прикладных систем.

  • Распространение информационной поддержки процесса на максимально возможную глубину. Если продолжить пример с собираемостью штрафов, мы не только не должны останавливаться на информационной рассылке уведомлений о факте нарушения, но не должны даже считать автоматизацию завершенной, если штраф не оплачен в течение отведенных законом девяноста дней. После этого, как известно, материалы передаются в суд, и если необходимо, подключаются судебные приставы. В конце концов сумма с должника взыскивается, и по всей этой цепочке действий должна следовать информационная поддержка.
  • Поддержка рабочих мест конкретных сотрудников и формирование информационной среды их работы. Здесь помимо привычных задач создания пользовательского интерфейса очень важно иметь массу всяких «удобств», каждое из которых направлено на повышение эффективности. Ими могут быть формирование шаблонов документов, оптимизация режимов загрузки этих шаблонов с сервера или, скажем, обеспечение доступа к данным других ведомств. Так, нарушители правил дорожного движения могут проживать не по тому адресу, где когда-то были зарегистрированы, и в таком случае может потребоваться информация из ФМС. Здесь уже приходится говорить об интеграционных возможностях программного решения, в частности о подключении к СМЭВ.

Всё вышеперечисленное привело к появлению в данном сегменте рынка принципиально новых решений для информационных систем «верхнего уровня». В качестве примера можно привести продукт компании «Ангелы АйТи», успешно решающий описанную проблематику и уже используемый в ряде регионов России. В качестве базовой платформы данного решения используется «1С». Ее возможности вполне адекватны задачам формирования сложной логики обработки информации, доступа к базам данных и построения гибкой отчетности, а также создания пользовательского интерфейса и интеграции с внешними системами.

Так, в стандартной конфигурации «из коробки» уже реализованы:

  • автоматическая загрузка в реальном времени со стационарных комплексов видеофиксации;
  • автоматическая отбраковка материалов низкого качества;
  • отслеживание статусов доставки по данным с серверов «Почты России»;
  • загрузка информации о платежах с различных источников;
  • автоматическое формирование материалов для Службы судебных приставов;
  • большой набор готовых отчетов.

При этом применение в качестве базовой платформы «1С» упрощает сопровождение, открывает широкие возможности по кастомизации и доработке, позволяет оперативно создавать и изменять отчеты.

О методологиях и стандартах

Как уже было сказано, новые задачи городского управления помимо тщательной проработки ИТ-архитектуры требуют определенного внимания к методологическим вопросам.

В ходе проектирования систем фотовидеофиксации приходится решать два типа задач:

  • подготовка строительного проекта, в соответствии с которым на рубежах фиксации монтируется оборудование, устанавливаются необходимые опоры, подключаются системы энергоснабжения и коммуникаций;
  • разработка ИТ-проекта в сфере прикладного ПО.

Разработка и оформление строительного проекта регламентируются действующей редакцией семейства ГОСТ 21 «Система проектной документации для строительства».

Что касается задач второй категории, в отечественной практике проектирования и внедрения ИТ-систем имеется хотя и несколько устаревший, но весьма широко применяемый при реализации ИТ-проектов ГОСТ 34 «Стандарты информационной технологии». Но при том, что содержательная направленность этих двух документов совершенно различна, методическое сопровождение проекта должно быть единым.

В этом смысле представляется интересной реализация проекта по созданию автоматизированной информационной системы фотовидеофиксации нарушений правил дорожного движения в Республике Мордовия, где проектировщик — компания «Смарт АйТи» — предложил разделить проектирование на два согласованных проекта:

  • разработка комплекта проектно-сметной документации на комплексы фиксации на рубежах в соответствии с ГОСТ 21;
  • проектирование ИТ-ядра Автоматизированной информационной системы фотовидеофиксации нарушений правил дорожного движения, выполненное по ГОСТ 34.

Согласование проектной документации было обеспечено как благодаря разработке необходимых частных технических заданий и требований (оба ГОСТ это допускают), так и за счет централизованного управления проектом в целом в соответствии с рекомендациями PMBok и ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом». В итоге при проектировании удалось, с одной стороны, соблюсти все требования технических регуляторов и контролирующих органов, связанных со строительством, а с другой — решить широкий спектр задач в сфере ИТ-архитектуры, прикладного ПО, интеграции информационных систем и информационной безопасности.