Некоторые аспекты архитектуры ПО FIWARE

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

На самом деле эта контекстная информация представляет собой промежуточную реляционную БД с методами доступа, реализованными в виде API NGSI.

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

Рисунок 1.

Можно предположить, что ответ не так уж и сложен:

1. Все эти рабочие подсистемы должны обладать открытыми стандартными интерфейсами SOA и разрешать доступ к своим БД со стороны внешнего SW.

2. Для доступа к информации, непосредственно от сенсоров используется протокол SNMP.

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

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

Для поддержки географических и геометрических данных NGSI предоставляет также определённые форматы, мало чем отличающиеся от стандартных GeoRSS.

 

Рисунок 2.

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

Похоже, что FIWARE Context Broker имплементирует несколько иной API NSGI 9/10 API. Разработчик утверждает, что брокер копирует контекстную информацию в рамках требований «умный город». Что конкретно это значить не совсем понятно. Видимо, имеется ввиду, возможность приёма данных от сенсоров по протоколу SMNP, их структурирование, хранение и утилизация. Определяется также, что это удобное средство для back-end web-программистов. Скорее всего, это набор библиотек кодов, встраиваемых в WEB сервисы WEB сервера. Не приводится данных, с какими типами WEB серверов совместимо это ПО.

Структурно модули инструментария FIWARE оформлены в виде:

­ FIWARE NGSI методы доступа и

­ CitySDK (визуальное средство разработки для программиста).

 

IoT Broker

позволяет приложениям пользователя взаимодействовать с таблицами (сущностями), а не непосредственно с сенсорами.

Способ взаимодействия:

­ формируется запрос на стороне приложения;

­ определяется ресурс, который должен предоставить информацию;

­ информация собирается и структурируется в соответствии с запросом и отправляется в качестве ответа.

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

⇐ Предыдущая1234567Следующая ⇒

Поделиться: