Статьи

Что нужно для того, чтобы город был умным?

С учетом шума вокруг Умных городов, и побыв архитектором в Smart City Solutions, у меня появилась идея написать о некоторых технологиях Умных городов. Я решил начать с архитектуры технологии и рассказать о ней в этой и следующей статье. Об использовании разного рода решений для умных городов будет написано в следующих статьях.

Итак, что же делает город умным?

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

Это определение охватывает большую часть из вариантов умных городов.

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

Что нужно для того, чтобы город был умным?

Я начну с нижнего блока – Интеграция. Будем двигаться снизу вверх.

Этот блок взаимодействует с приложениями и сенсорами.

Приложения в свою очередь делятся на две группы: Внутригородские приложения и Внешние приложения.

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

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

Уровень интеграции должен быть достаточно гибким для того, чтобы отвечать различным механизмам взаимодействия разных приложений. Например, есть два приложения: одно написано на платформе Java, другое – Microsoft.NET. Если им нужно обменяться данными, то для этого необходим определенный механизм. Такими механизмами могут быть веб-сервисы, интеграция на основе очередей, базы данных, прямые запросы API, файловая интеграция. Если капнуть глубже, то для этих интеграций существую различные протоколы: SOAP/ HTTP, JMS, JDBC и так далее. Но я это пропущу ради простоты.

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

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

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

Блок данных можно разбить на три: OLTP, OLAP и хранилище данных. Теперь коротко о них (сами по себе это целые темы, но придержусь краткости).

OLTP-репозиторий: OLTP расшифровывается, как Online Transaction Processing (Онлайн обработка транзакций). Как можно предположить из названия, он хранит данные транзакций от приложений. Приложения, которые работают с транзакциями, например, биллинговое приложение для оплаты электроэнергии, приложения утилизирующей компании и разного рода банковские приложения будут использовать базы данных OLTP.

OLAP-репозиторий: OLAP расшифровывается, как Online Analytic Processing (Онлайн анализ данных). Эти базы данных подходят для анализа данных. Представьте, база OLTP хранит более 1 Тб данных с двумя миллионами записей, и Вам нужно запустить анализ. База OLTP не подойдет для обработки такого рода запросов, в этом случае лучшим решением будет OLAP.

Репозиторий данных: этот репозиторий хранит документы, относящиеся к операциям города с необходимыми мета тегами. Мета теги содержат информацию, описывающую документы. Например, при загрузке плана здания возникает необходимость в механизмах его размещения, обновления, архивирования и удаления. Информация может быть следующей: ID документа, дата создания, название документа, имя строителя и так далее. Эта информация называется мета тегами. Если Вы все еще не поняли что такое мета теги, не переживайте, можете продолжать читать, потому что я больше не буду ссылаться на эту информацию.

Перейдем к следующему блоку Механизм корреляции данных и процессор правил.

Механизм корреляции данных нацелен на корреляцию данных, полученных из разнообразных источников. Система должна позволять создавать логику корреляции.

Процессор правил: как можно предположить из названия, здесь создаются правила. Простые правила, как “если” значение собранного налога меньше, чем x процентов от общего дохода “тогда” отправить уведомление властям. Также система должна позволять создавать сложные правила.

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

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

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

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

Аналитический блок – это блок для городских властей, где они могут создавать отчеты, информационные панели, получать ключи показателей эффективности (KPI), анализировать данные. Теперь угадайте: из какого репозитория будут браться данные? Правильно, данные будут браться с репозитория OLAP. Аналитический блок должен поддерживать диагностическую, описательную и прогнозную аналитику. Коротко о них.

Описательная аналитика: используется для анализа того, что случилось с организацией в прошлом.

Диагностическая аналитика: используется для анализа того, каким образом и почему что-либо произошло с организацией.

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

Чтобы больше узнать о них с примерами, можете прочесть мою статью Analytics to Predictive Analytics”. 

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

Геопространственная визуализация: позволяет визуализировать операции города на карте географической информационной системы (ГИС). Этот блок будет накладывать на карту ГИС информацию, полученную из анализов, репозитория данных, блока корреляции и конфигурации правил для определения состояния операций города. На карту также будут накладываться предупреждения и уведомления, что позволит городским властям визуализировать проблемы в нужном месте и направить туда необходимые ресурсы. Примером карт ГИС могут послужить Google Maps и ESRI.

Для иллюстрации того, о чем я говорю, ниже приведен простой пример, показывающий отображение дорожной обстановки на ГИС-карте. Темно-красный цвет говорит о том, что в этом месте пробка.

Что нужно для того, чтобы город был умным?

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

Что нужно для того, чтобы город был умным?

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

Теперь перейдем к последнему блоку – Портальная и мобильная технологии.

Портал: Этот компонент будет объединять разные части аналитической, геопространственной, расширенной визуализации, оптимизации, стандартных операционных процедур, предупреждений (сгенерированных механизмом корреляции и конфигурации правил) в одном месте с ролевым доступом. Каждому компоненту технологии будет соответствовать портлет (мини-окно) на портале.

Ниже представлен снимок того, как будет выглядеть портал. Как Вы можете видеть, здесь присутствуют портлеты панели управления, геопространственной визуализации, оптимизации и предупреждений.

Что нужно для того, чтобы город был умным?

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

Мобильная технология: важность мобильной технологии сложно переоценить в наше время. Этот компонент решения позволит получать доступ к порталу гражданам города, властям и организациям при помощи мобильного телефона или планшета. При помощи этого компонента возможно обеспечить доступ к страницам портала с мобильного или планшета с учетом форм-факторов (форма и размер).

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

Это было своего рода обобщение по архитектуре технологии умного города.

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

 

Оригинал статьи. Автор: Kanumury Radhesh.

Оставить комментарий