CC BY
229
Города, управляемые данными
Д.Е. Намиот, Е.В. Зубарева
Аннотация—Эта статья посвящена рассмотрению вопросов стандартизации Умных Городов. В первой части работы рассматривается модель города, управляемого данными. Мы останавливаемся на архитектуре стандартов Умного Города в части инфо-коммуникационных систем. Показана определяющая роль платформ Интернета Вещей для Умных Городов. По нашему мнению, предлагаемые подходы должны найти свое отражение в отечественных разработка, посвященных этой тематике. Во второй части статьи речь идет о поиске данных при создании сервисов и приложений для Умного Города. Мы описываем спецификацию HyperCat, которая предлагает простой стандарт для описания сервисов (ресурсов) в проектах Интернета Вещей, а также простые механизмы программного поиска сервисов. Предложенная спецификация легла в основу британского стандарта в области Интернета Вещей. Этот стандарт был переведен на русский язык и может рассматриваться как один из претендентов на локализацию.
Ключевые слова—Умные Города, международные стандарты, Интернет Вещей.
I. Введение
В этой статье мы хотели остановиться на представлении и обработке данных в Умных Городах. Идея состоит в том, чтобы показать связь Интернета Вещей (IoT) и проектов Умного Города (Smart Cities). Это очень важно в свете ведущихся разработок стандартов. Как нам представляется, особенно это важно для отечественной практики, где стандарты игнорируются, либо, по непонятным причинам, все обсуждение (по крайней мере, для рассматриваемых нами областей) совершенно не соотносится с международной практикой.
Важно отметить, что с точки зрения информационных технологий, стандарты - вещь достаточно обычная. Стандартами Международной организации по стандартизации (ISO) являются, например, такие практические системы как язык SQL или C++. Но очень важно отметить, что стандарты, вообще говоря, не имеют прямого отношения к каким-либо правовым ограничениям (регуляциям). По крайней мере, это не является их основным назначением. А именно как ограничение они часто рассматриваются именно в отечественной практике. В классической трактовке, стандарты должны рассматриваться как то, что в англоязычной литературе называется "лучшая практика" (best practice). Вот упомянутые выше языки
Статья получена 15 ноября 2016.
Намиот Д.Е., МГУ имени М.В. Ломоносова, (email: dnamiot@gmail .com)
Зубарева Е.В. — МГУ имени М.В. Ломоносова; ЕГУ имени И.А. Бунина (e-mail: [email protected])
программирования и есть, между прочим, хороший пример такой интерпретации. Лучшая практика по организации доступа к данным - язык 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.
