В фокусе
Читать
ГлавнаяРубрикиПрограммное обеспечениеПостроение программного обеспечения управляющих контроллеров на основе открытых интерфейсов IPMI, HPI, RedFish
17.12.2017

Построение программного обеспечения управляющих контроллеров на основе открытых интерфейсов IPMI, HPI, RedFish

Сергей Жуков, Игорь Починок, Auriga Inc., НИВЦ МГУ

В статье описывается построение архитектуры программного обеспечения для управляющего контроллера на основе интерфейса SAF HPI. На нижнем уровне управляющий контроллер взаимодействует c интеллектуальными контроллерами по интерфейсу IPMI и с неинтеллектуальными устройствами. На верхнем уровне управляющий контроллер поддерживает интерфейс Redfish и протокол MQTT, которые реализованы поверх интерфейса HPI; эти реализации логически отделены от внутренней архитектуры системы.

Интерфейс IPMI

Интерфейс IPMI (Intelligent Platform Management Interface) – стандарт низкоуровневого интерфейса управляющего контроллера и набор сопутствующих стандартов (протокол IPMB, формат FRU-информации и т. д.), введённый компанией Intel в 1997 году. Версия 2 опубликована в 2004 году и актуальна до сих пор. Представляет из себя набор низкоуровневых команд типа запрос-ответ.

Благодаря поддержке Intel стандарт стал очень популярен и до сих пор многие из существующих контроллеров реализуют IPMI. В частности, стандарт PICMG ATCA (Advanced Telecommunications Architecture), популярный в телекоммуникационной отрасли, основан на IPMI.

В модели IPMI каждый управляющий контроллер несёт на себе набор сенсоров, каждый из которых имеет номер и специальное описание (SDR – Sensor Data Record), значение сенсора может быть прочитано специальной командой. Изменение состояния сенсора может порождать события.

Сенсоры могут быть числовые (нести значение) и дискретные (находиться в одном или нескольких состояниях). Для числовых сенсоров задаются пороги, при выходе за пороги происходят события. Для дискретных сенсоров события происходят при изменении состояния сенсора. События сохраняются в логе (SEL – System Event Log), возможно задавать действия в ответ на события (PEF – Platform Event Filtering).

Интерфейс IPMI в настоящее время устарел и в связи с этим имеет существенные недостатки:
– интерфейс очень низкоуровневый: формат каждой команды детально расписан по байтам и битам;
– длина команды ограничена – максимум 32 байта;
– ограничено количество сенсоров на одном контроллере – максимум 1024 (но, например, для контроллеров ATCA ограничение ещё строже – максимум 768);
– отсутствует единый механизм для управляющих воздействий: изменения состояния сигналов, установки значений управляющих регистров (создаются специальные команды для каждого случая);
– размер значения в команде для числовых сенсоров – 8 бит, вычисление реального значения сенсора производится клиентом с использованием коэффициентов из описания сенсора SDR; в результате реальное значение может иметь большую погрешность.

Интерфейс RedFish

Этот интерфейс разработан организацией DMTF в 2015 году, позиционируется как замена IPMI.

Интерфейс высокоуровневый, использует HTTP и RESTful Web Services для передачи данных, XML для описания структур данных, JSON как формат данных в процессе передачи.

Используется объектная сетецентричная модель данных. Объекты содержат ссылки на другие объекты, существуют объекты – коллекции объектов. Модель данных описана схемой, которая является неотъемлемой частью стандарта. Схема поставляется в двух форматах: XML и JSON.

Для доступа к данным используются стан- дартные HTTP-операции (GET, PUT, POST, DELETE), таким образом, клиентский доступ возможен из любого Web-браузера.

Если результатом запроса является массив объектов, возможно чтение этого массива по частям, начиная с любого места.

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

Интерфейс HPI

HPI (Hardware Platform Interface) – интерфейс доступа к аппаратным платформам, разработанный организацией SAF (Systems Availability Forum). Интерфейс основан на механизме удалённого вызова процедур (RPC).

Интерфейс описывается в терминах типов данных и прототипов функций языка Си, но также существуют привязки к языкам Java и Python.

Модель данных HPI основана на IPMI, но основные недостатки её устранены:
– числовые сенсоры имеют размер 64 бита, тип целый (знаковый или беззнаковый) или плавающий;
– трансляция значений на стороне клиента не требуется, реализация HPI сразу возвращает реальное значение;
– определены элементы управления (controls) различных типов: бинарные (вкл/ выкл), дискретные, аналоговые;
– система (домен HPI) строится как набор ресурсов, каждый ресурс содержит набор сенсоров и элементов управления и может поддерживать горячую замену;
– система может содержать до 232 ресурсов;
– каждый ресурс может содержать до 232 сенсоров и до 232 элементов управления.

Интерфейс HPI можно рассматривать как хороший компромиссный вариант между IPMI и Redfish.

Пример построения архитектуры системы управления на основе HPI

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

Управляемые объекты включают в себя:
– неинтеллектуальные сенсоры и устройства, подключённые по протоколу 1-wire, I2C (сенсоры температуры, напряжения, тока, мощности, влажности, давления и т. д.);
– неинтеллектуальные дискретные сенсоры на основе сигналов GPIO (General Purpose Input/Output – сигналов ввода-вывода общего назначения);
– дискретные элементы управления на основе сигналов GPIO (включение/выключение соответствующего сигнала); – интеллектуальные устройства охлаждения с интерфейсом Modbus;
– интеллектуальные вспомогательные управляющие контроллеры с интерфейсом IPMI.
– дочерние управляющие контроллеры того же типа, подключённые к материнскому контроллеру по выделенному сетевому соединению и не имеющие внешнего интерфейса (таким образом, управляющие контроллеры образуют иерархию).

Для интерфейса с внешним миром должны были использоваться интерфейсы SNMP, Redfish и графический Web-интерфейс, а также протокол MQTT для встраивания контроллера в инфраструктуру IoT (Internet of Things – интернет вещей).

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

Архитектура программного обеспечения показана на схеме.

Для разных интерфейсов нижнего уровня отображение на модель данных HPI выглядит следующим образом:
– каждое устройство 1-wire отображается на отдельный ресурс, поддерживающий горячую замену (устройства 1-wire могут динамически добавляться на шину и удаляться с неё);
– один HPI-ресурс создаётся для всех GPIO-сигналов, все дискретные сенсоры и элементы управления принадлежат этому ресурсу;
– для устройств, подключённых по I2C, каждый набор логически связанных между собой устройств отображается как отдельный HPI-ресурс;
– каждый интеллектуальный контроллер охлаждения, подключённый по Modbus, представляет собой отдельный ресурс, его регистры отображаются на сенсоры и управляющие элементы HPI;
– каждый интеллектуальный IPMI-контроллер представляет собой отдельный ресурс, в соответствии со стандартом отображения между IPMI и HPI;
– каждый дочерний контроллер экспортирует набор HPI-ресурсов, эти ресурсы встраиваются в набор ресурсов материнского контроллера как есть, лишь с изменением номера во избежание конфликта по номерам ресурсов.

Для отображения устройств 1-wire, I2C, Modbus на HPI в составе программного обеспечения разработаны специальные модули. Для отображения интерфейса IPMI используется открытое программное обеспечение.

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

Аналогично сделана реализация протокола MQTT, для включения управляющего модуля в состав инфраструктуры интернета вещей (IoT). Модуль интерфейса с MQTT использует верхний интерфейс HPI, топики MQTT используют номера или имена ресурсов, сенсоров и элементов управления (например, часть строки топика, соответствующая значению сенсора 20 на ресурсе 2 может выглядеть как "/sensors/value/2/20").

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

Архитектура программного обеспечения управляющего контроллера

Версия для печати738 просмотров.
Оцените статью по: