Города, управляемые данными Текст научной статьи по специальности «Компьютерные и информационные науки»

Города, управляемые данными

Д.Е. Намиот, Е.В. Зубарева

Аннотация—Эта статья посвящена рассмотрению вопросов стандартизации Умных Городов. В первой части работы рассматривается модель города, управляемого данными. Мы останавливаемся на архитектуре стандартов Умного Города в части инфо-коммуникационных систем. Показана определяющая роль платформ Интернета Вещей для Умных Городов. По нашему мнению, предлагаемые подходы должны найти свое отражение в отечественных разработка, посвященных этой тематике. Во второй части статьи речь идет о поиске данных при создании сервисов и приложений для Умного Города. Мы описываем спецификацию HyperCat, которая предлагает простой стандарт для описания сервисов (ресурсов) в проектах Интернета Вещей, а также простые механизмы программного поиска сервисов. Предложенная спецификация легла в основу британского стандарта в области Интернета Вещей. Этот стандарт был переведен на русский язык и может рассматриваться как один из претендентов на локализацию.

Ключевые слова—Умные Города, международные стандарты, Интернет Вещей.

I. Введение

В этой статье мы хотели остановиться на представлении и обработке данных в Умных Городах. Идея состоит в том, чтобы показать связь Интернета Вещей (IoT) и проектов Умного Города (Smart Cities). Это очень важно в свете ведущихся разработок стандартов. Как нам представляется, особенно это важно для отечественной практики, где стандарты игнорируются, либо, по непонятным причинам, все обсуждение (по крайней мере, для рассматриваемых нами областей) совершенно не соотносится с международной практикой.

Важно отметить, что с точки зрения информационных технологий, стандарты - вещь достаточно обычная. Стандартами Международной организации по стандартизации (ISO) являются, например, такие практические системы как язык SQL или C++. Но очень важно отметить, что стандарты, вообще говоря, не имеют прямого отношения к каким-либо правовым ограничениям (регуляциям). По крайней мере, это не является их основным назначением. А именно как ограничение они часто рассматриваются именно в отечественной практике. В классической трактовке, стандарты должны рассматриваться как то, что в англоязычной литературе называется "лучшая практика" (best practice). Вот упомянутые выше языки

Статья получена 15 ноября 2016.

Намиот Д.Е., МГУ имени М.В. Ломоносова, (email: dnamiot@gmail .com)

Зубарева Е.В. — МГУ имени М.В. Ломоносова; ЕГУ имени И.А. Бунина (e-mail: e.zubareva@cs.msu.ru)

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

Итак, стандарты - это лучшая практика, которая имеет какое-то экономическое выражение (экономическую оценку). Например, открытые стандарты в области Умного Города и Интернета Вещей ускоряют рост на 27% и сокращают стоимость разработок на 30% [1].

Стандарты для Умных Городов включают не только инфо-коммуникационные компоненты. И это также вполне укладывается в концепцию "лучших практик". Например, практики организации взаимодействия с жителями города и т.п. Общие описания стандартов Умного Города можно найти, например, в наших работах, опубликованных в журнале INJOIT [2,3,4].

В данной статье мы останавливаемся именно на инфо-коммуникационных технологиях (ИКТ).

Оставшаяся часть статьи структурирована следующим образом. В разделе II мы рассматриваем общую организацию стандартов Умного Города. Именно здесь будет рассмотрено понятие города, управляемого данными. В разделе III мы рассматриваем вопросы, связанные с поиском данных для систем Умного Города.

II. ГОРОДА, УПРАВЛЯЕМЫЕ ДАННЫМИ

Общая схема ИКТ компонент Умного Города приведена на рисунке 1.

Эта схема разработана ITU и используется Международной организацией по стандартизации в своих документах, посвященных Умному Городу.

Два нижних уровня на схеме относятся к Интернету Вещей (IoT). Иными словами - IoT есть уровень подготовки данных для Умного Города. То, что располагается между данными и сервисами - это уже собственно платформу Умного Города, CityOS, CitySDK - названия могут быть разными.

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

Эта простая схема, в частности, совершенно не отражает текущей отечественной практики, где о системах Интернета Вещей и Умного Города говорят именно как о наборах сервисов. При этом все сервисы рассматриваются независимо друг от друга. Это, с неизбежностью, означает, что каждый такой сервис

будет дублировать (реализовывать для своих пугают авторов отечественных дорожных карт в области собственных нужд) всю инфраструктуру сбора и Интернета Вещей и Умного Города, то как потом хранения данных. Даже если затраты на разработку не сопровождать (обслуживать) такое множество систем?

Spatial Smart City Enterprise Components

Based on ITU Focus Group on Smart Sustainable Cities

i Municipal Employees |j Public

Application Layer

Health ■ Intelligent

Pu Ы Je safely a ra d seen гНу

Ope-ri data

Urban planning

Business Layer

Vi s ца ! izalíon and I Catalogs. Decision Support I Semantics

F?

Data Access

Data Layer

Dala

Ui b::n M unie ¡pL".I Database

Sensing Layer

Dala Ingestand Quality Checking

С fly Sensor Webs

Ем

Crowdsourcing

I

Sensor networks

В

Pirones. Wearables

о о

о

(Л ff

ft> U) О CT

s

u>

o

CO u» rî

ОС-с

Рис. 1. Компоненты Умного Города

Smart City Information Enterprise

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

Тот факт, что все сервисы базируются на собираемых данных и привел к появлению термина "город, управляемый данными" [5,6,7].

За непосредственный сбор данных отвечает

платформа 1оТ. Именно по этой причине иногда их и используют как платформы для Умного Города. Пример - опеМ2М. Это было описано ранее [8,9].

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

Public Citizen Access ■ Enterprise User Access City Manager Access

Smart Application Layer

Ш

Data & Service Supporting Layer

Г

Setvcc Gathering service Priinagcrafent 5efvязе Convergence serv'ce corjumpton

Tton

Hir-T-T-T.Jl.T

Data CoSectioii & Ajywgitief»

Data Intégrât-on & Procès*

Irrte "gent Мдщ &

Management &

4drni!WFtrst)0«

fiHM Eamengea»« Dili

Zfo^-s ~ Bei а

"te-*"«! Serte

Computing and Storage Layer

Computing Resource

Storage Resource

Network Communication Layer "1

( Data Acquisition Layer

iimor RFID Actuator Camera 1

о

■о

<T> -i EIJ i—

о" э га

S

ш з" го си

п го

m 3

Рис. 2. Инженерная модель Умного Города

На рисунке 2 представлена инженерная модель Умного Города (служб ИКТ в Умном Городе) по модели ISO. В принципе, она дает достаточное представление о том, что именно должно разрабатываться (и стандартизоваться - то есть, предлагаться как лучшая практика) в рамках информационно-коммуникационных технологий для Умного Города.

Города, то одним из важнейших моментов становится вопрос поиска этих данных. А именно, как приложение (сервис, на верхнем уровне архитектурной модели) узнает о том, что есть такой-то набор данных (датасет), которые представляет определенные измерения?

Данные измерений должны быть получены, опубликованы и проиндексированы сервисом раскрытия (поисковым сервисом) - рисунок 3 [10].

III Поиск данных в Умном Городе

Поскольку данные (измерения) играют (с точки зрения ИКТ, конечно) определяющую роль для Умного

Рис. 3. Упрощенная модель поиска.

Дополнительную сложность создает тот факт, что IoT системы могут быть распределенными. В качестве примеров инициатив в области создания поисковых систем для IoT можно назвать Shodan [11] и Thingful [12].

В данной статье мы же хотели бы остановиться на стандарте поиска для IoT систем, предложенном BSI (Британский институт стандартизации) - PAS-212 [13]. Этот стандарт базируется на продукте с открытым кодом - HyperCat [14]. Стандарт переведен на русский язык и распространялся в рамках рабочей группы Росстандарта, занимающейся выработкой

отечественный стандартов для Интернета Вещей и Умных Городов [15].

Идея HyperCat базируется на модели IoT систем, представленной на рисунке 4. Так IoT системы проектировал British Telecom. В этой модели данные от различных сенсоров аккумулируются в некотором хранилище, которое обозначено на схеме как Data Hub. За коллекционирование данных отвечает IoT Gateway. Data Hub является тем элементом архитектуры, который и обеспечивает доступ к данным для аналитики и сервисных приложений.

Applications

Big data analytics

Data

storage arid exchange

Gateway & proprietary connectivity solutions

lw,r 4w

Sensing layer

Рис. 4. IoT архитектура

Third party data hub

В принципе, схожей архитектурной модели придерживается и ETSI [16].

Вот именно в таком хабе (хабах, если их несколько) и предполагается иметь описания для всех имеющихся там наборов данных. HyperCat - это стандарт, который описывает то, как должны представляться такие метаданные.

Это принципиальная позиция BSI. Согласно BSI, следующие темы подлежат стандартизации в работе с данными (с большими данными) [17]:

- стандарт на метаданные. В мире больших данных, метаданные являются основой для аналитических отчетов. Множество аналитических отчетов базируются именно на метаданных. BSI предполагает определить наилучшую практику для сбора и хранения метаданных, в том числе, обеспечить качество и полноту собранной информации, а также регламентные процедуры (принципы) для долговременного хранения метаданных (например, как долго они должны храниться). PAS-212 (HyperCat) - это типичный пример стандарта, связанного с метаданными;

- руководство "Как сделать" для Big Data. Можно описать это как примеры использования (use cases) для больших данных. Согласно BSI, этот стандарт должен помочь предприятиям стартовать с проектами Big Data.

На рисунке 5 представлена общая идеология PAS-212.

Catalogue

metadata

relation

val

relation

reí тга_1 i

catalogue ítem

href

metadata

relation reí T7al

г-------

relation reí тга.1

catalogue It-em

href

metadata

relation

relation

reí val

reí val

Рис. 5. Каталог в РЛ8-212

Кратко - это каталог мета-данных, где каждый элемент есть пара <описание, значение>. При этом предполагается использовать те же принципы, на которых строится связанность данных в сети Интернет:

доступ к данным через стандартные веб-протоколы и форматы (протокол HTTPS, формат JSON, REST-модель и т.д.). Ресурсы (каталоги, элементы каталогов) должны выявляться через URI. Для описания данных используется общая семантика.

Спецификация HyperCat [18] включает в себя следующие элементы (предположения):

Identity - в качестве идентификации для приложений и хабов данных используются URI.

Catalogues - каталог реализуется хабом данных для доступа приложений. Каждый каталог - это просто неупорядоченная коллекция ресурсов. Каждый ресурс в каталоге описывается своим URI. В качестве ресурса может выступать и другой каталог. Все HyperCat-совместимые хабы поддерживают каталог (возможно, пустой) по адресу {BASE URL}/cat. Иными словами, один адрес каталога всегда известен. А другие ресурсы уже могут быть описаны через этот известный каталог. Это дает возможность приложению (сервису) опросить (раскрыть) все метаданные. Технически каталог представляется JSON-документом с MIME- типом application/vnd. tsbiot. catalogue+json

Все URI внутри каталога должны быть уникальны. Каталог может поддерживать мета-данные как для самого себя, так и для своих отдельных объектов

Catalogue Object - объект каталога представляет собой JSON объект. Он должен содержать следующие свойства:

"items" - JSON массив элементов "item" (возможно, пустой)

"item-metadata" - JSON массив объектов метаданных

Item Object - элемент представляет собой JSON объект со следующими свойствами: "href' - идентификатор (URI)

"i-object-metadata" - JSON массив объектов метаданных

Для иллюстрации последних понятий - см. рисунок 5.

Массив метаданных должен содержать описания для обязательных отношений. Этот массив может содержать объекты с одинаковыми свойствами.

Metadata Object - объект метаданных представляет собой JSON объект, который описывает отношение между родительским объектом (каталогом или элементом каталога) и концепцией, представленной в виде URI. Все объекты метаданных должны включать следующие свойства:

"rel" - описывает отношение между родителем и сущностью. Описывается предикатом (глаголом). Представляется как URI

"val" - сущность, для которой описывается отношение. Представляется как JSON строка (возможно - URI)

Эти <rel, val> и есть пара <описание, значение>.

При описании URI можно использовать относительные адреса. В таком случае, они интерпретируются в соответствии с RFC 1808 [19]. Пример использования:

Описание {"rel": "urn:X-tsbiot:rels:isColour",

"val":"blue"} должно быть проинтерпретировано так, что свойство iColour родительского объекта имеет значение blue.

Все массивы метаданных имеют (должны включать) обязательные отношения. Во-первых, ресурс должен иметь текстовое описание:

"rel": "urn:X-tsbiot:rels:hasDescription:en" "val": описание в форме JSON строки

Дополнительно, все объекты метаданных верхнего уровня должны включать следующее отношение:

"rel: "urn:X-tsbiot:rels:isContentType " "val": "application/vnd.tsbiot.catalogue+json"

Оно описывает тип возвращаемых данных.

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

Тип данных, возвращаемых ресурсом (согласно кодировке MIME RFC-2046)

"rel": "urn:X-tsbiot:rels:isContentType " "val": строка. Например: text/csv

Ссылка на веб-страницу описания ресурса

"rel": "urn:X-tsbiot:rels:hasHomepage " "val": URL для веб-страницы

Тип данных для ресурсов каталога (согласно кодировке MIME RFC-2046 [20])

"rel": "urn:X-tsbiot:rels:containsContentType" "val": строка. Например: text/csv

Указание на поддержку поиска в каталоге "rel": "urn:X-tsbiot:rels:supportsSearch" "val":URI для поискового запроса

Поиск по каталогу осуществляется представлением поискового запроса в строке согласно RFC-1738 [21]. Параметры запроса:

"rel" - отношение. URI или строка "val" - URI или строка "href" - URI для ресурса

Операции над каталогами включают действия по созданию, удалению и чтению элементов. Сообразно модели REST, операции модификации поддерживаются через HTTP запрос POST, операция чтения - через GET

Все HTTP (HTTPS) запросы аутентифицируются по ключу, который также представляет собой URI. Ключ присутствует в заголовке HTTP запроса. Порядок генерации и распространения ключей вынесен за рамки

спецификации HyperCat. Также за рамки спецификации вынесен вопрос о распространении постоянно обновляемых данных. Подписки на обновление, использование для этого push-уведомлений или публикация в MQTT должны решаться сторонними сервисами.

Статус-код HTTP запроса возвращает информацию о запросе. Например:

204 - нет отклика 400 - неверный запрос и так далее.

В целом, получилась очень простая и компактная спецификация. У нее уже есть примеры промышленного внедрения - HyperSpace [22]. Другой большой пользователь - British Telecom [23].

Нам представляется, что данная спецификация заслуживает самого пристального внимания при выборе стандартов для Умного Города в России [24].

Библиография

[1] Намиот Д.Е., Шнепс-Шнеппе М.А. Об отечественных стандартах для Умного Города // International Journal of Open Information Technologies. 2016. -Т. 4. - №7. С.32-37.

[2] Куприяновский В. П. и др. Умные города как «столицы» цифровой экономики //International Journal of Open Information Technologies. - 2016. - Т. 4. - №. 2. - С. 41-52.

[3] Куприяновский В. П. и др. Цифровая экономика и Интернет Вещей-преодоление силоса данных //International Journal of Open Information Technologies. - 2016. - Т. 4. - №. 8. - С. 36-42.

[4] Намиот Д. Е., Куприяновский В. П., Синягов С. А. Инфокоммуникационные сервисы в умном городе //International Journal of Open Information Technologies. - 2016. - Т. 4. - №. 4. -С. 1-9.

[5] Batty M. Big data, smart cities and city planning //Dialogues in Human Geography. - 2013. - Т. 3. - №. 3. - С. 274-279.

[6] Kitchin R. The real-time city? Big data and smart urbanism //GeoJournal. - 2014. - Т. 79. - №. 1. - С. 1-14.

[7] Batty M. et al. Smart cities of the future //The European Physical Journal Special Topics. - 2012. - Т. 214. - №. 1. - С. 481-518.

[8] Шнепс-Шнеппе М. А. Как строить умный город. Часть 1. Проект "Smart Cities and Communities" в Программе ЕС Horizon 2020 //International Journal of Open Information Technologies. - 2016. -Т. 4. - №. 1.- С. 12-20.

[9] Шнепс-Шнеппе М. А. Как строить умный город Часть 2. Организация «oneM2M» как прототип в области стандартов умного города //International Journal of Open Information Technologies. - 2016. - Т. 4. - №. 2. - C. 11-17.

[10] Barnaghi P., Sheth A. On Searching the Internet of Things: Requirements and Challenges //IEEE Intelligent Systems. - 2016. -Т. 31. - №. 6. - С. 71-75.

[11] Shodan http://www.shodan.io Retrieved: Nov, 2016

[12] Thingful http://thingful.net Retrieved: Nov, 2016

[13] PAS 212:2016 Automatic resource discovery for the Internet of Things. Specification http://shop.bsigroup.com/forms/PASs/PAS-212-2016-download/ Retrieved: Nov, 2016

[14] Намиот Д. Е., Куприяновский В. П., Зубарева Е. В. Hypercat -структура и модели применения // Современные информационные технологии и ИТ-образование. — 2016. — Т. 12, № 1. - С. 208-213.

[15] Kupriyanovsky, Vasily, et al. "On Localization of British Standards for Smart Cities." International Journal of Open Information Technologies 4.7 (2016): 13-21.

[16] Grieco L. A. et al. Architecting information centric ETSI-M2M systems //Pervasive Computing and Communications Workshops (PERCOM Workshops), 2014 IEEE International Conference on. -IEEE, 2014. - С. 211-214.

[17] Намиот Д. Е. и др. Стандарты в области больших данных //International Journal of Open Information Technologies. - 2016. -Т. 4. - №. 11. - С. 12-18

[18] HyperCat specification https://hypercatiot.github.io/spec1.1.pdf Retrieved: Nov, 2016

[19] RFC 1808 https://tools.ietf.org/html/rfc1808 Retrieved: Nov, 2016

[20] RFC 2046 https://www.ietf.org/rfc/rfc2046.txt Retrieved: Nov, 2016

[21] RFC 1738 http://tools.ietf.org/html/rfc1738 Retrieved: Dec, 2016

[22] Hyperspace https://hyperspace.center/ Retrieved: Nov, 2016

[23] BT HyperCat http://portal.bt-hypercat.com/ Retrieved: Nov, 2016

[24] Куприяновский В. П., Намиот Д. Е., Куприяновский П. В. Стандартизация Умных городов, Интернета Вещей и Больших Данных. Соображения по практическому использованию в России //International Journal of Open Information Technologies. -2016. - Т. 4. - №. 2. - С. 34-40

Data-driven Cities

Dmitry Namiot, Elena Zubareva

Abstract— This article is devoted to the standardization of smart cities. In the first part of the work, we discuss a model for data-driven cities. We describe Smart Cities architecture standards in terms of information and communication systems. The determining role of the Internet of Things platform for smart cities is declared. In our opinion, the proposed approach should be reflected in national development, dedicated to this subject. In the second part of this article, we are talking about data search to create services and applications for Smart Cities. It is about HyperCat specification, which offers a simple standard for describing services (resources) in the Internet of Things projects, as well as simple software search services mechanisms. The proposed specification was the basis of British Standard in the field of the Internet of Things. This standard has been translated into Russian and can be considered as one of the contenders for the localization.

Keywords— Smart Cities, international standards, Internet of Things.