Интерфейс аппаратной платформы
 |
Интерфейс аппаратной платформы ( HPI ) — это открытая спецификация, определяющая интерфейс прикладного программирования (API) для управления платформами компьютерных систем. API поддерживает такие задачи, как считывание датчиков температуры или напряжения, встроенных в процессор, настройку аппаратных регистров, доступ к инвентарной информации системы, такой как номера моделей и серийные номера, а также выполнение более сложных действий, таких как обновление встроенного ПО системы или диагностика сбоев системы.
HPI предназначен для использования с отказоустойчивыми и модульными компьютерными системами высокой доступности , которые обычно включают функции автоматического обнаружения неисправностей и аппаратное резервирование, чтобы они могли обеспечить непрерывную доступность услуг. Дополнительные функции, общие для аппаратных платформ, используемых для приложений высокой доступности, включают возможность онлайн-обслуживания и возможность обновления с помощью модулей с возможностью горячей замены.
Спецификация HPI разработана и опубликована Форумом доступности услуг (SA Forum) и размещена в свободном доступе для общественности.
История
[ редактировать ]Основным мотиватором разработки спецификации HPI стало появление модульных компьютерных аппаратных платформ и готовых коммерческих систем (COTS) в конце 1990-х и начале 2000-х годов. Сюда входили платформы CompactPCI , а позднее — платформы AdvancedTCA и MicroTCA (xTCA), стандартизированные Группой производителей промышленных компьютеров PCI (PICMG). Эти платформы включают в себя инфраструктуру управления оборудованием на основе интеллектуального интерфейса управления платформой (IPMI). Одновременно крупные поставщики корпоративных решений, такие как HP и IBM, также разработали модульные и блейд-системы.
Потребность в спецификации HPI была впервые выявлена отраслевой группой под названием «Форум высокой доступности», которая собиралась в течение нескольких месяцев в 2000 году для обсуждения вопросов, связанных с созданием компьютерных систем высокой доступности с использованием технологии открытой архитектуры . В начале 2001 года эта группа опубликовала официальный документ «Предоставление решений высокой доступности с открытой архитектурой». В результате этой работы корпорация Intel начала проект по определению стандартного API управления аппаратной платформой, получившего название Universal Chassis Management Interface (UCMI). Эта работа была передана недавно сформированному консорциуму SA Forum и опубликована как Интерфейс аппаратной платформы в октябре 2002 года. Исходная спецификация HPI, SAI-HPI-A.01.01, была первой спецификацией, опубликованной SA Forum.
Начиная с 2002 года, было опубликовано несколько обновлений спецификации HPI. Кроме того, были разработаны спецификации для доступа к реализации HPI через простой протокол сетевого управления (SNMP) и спецификации, описывающие использование HPI на платформах AdvancedTCA и MicroTCA. В таблице 1 перечислены все спецификации семейства HPI, опубликованные SA Forum.
| Этикетка с техническими характеристиками | Дата публикации | Примечания |
|---|---|---|
| САИ-ХПИ-А.01.01 | 7 октября 2002 г. | Исходная спецификация HPI |
| САИ-ХПИ-Б.01.01 | 3 мая 2004 г. | Значительный пересмотр базовой спецификации HPI. Устранены проблемы реализации и удобства использования в исходной спецификации. |
| САИ-HPI-SNMP-B.01.01 | 3 мая 2004 г. | SNMP MIB для доступа к реализациям HPI |
| САИ-ХПИ-Б.02.01 | 18 января 2006 г. | Небольшая доработка базовой спецификации HPI. Добавлены возможности FUMI, DIMI и управления нагрузкой. |
| SAIM-HPI-B.01.01-ATCA | 18 января 2006 г. | Спецификация сопоставления HPI и AdvancedTCA |
| САИ-ХПИ-Б.03.01 | 21 октября 2008 г. | Небольшая доработка базовой спецификации HPI. Улучшения FUMI; некоторые новые функции API |
| САИ-ХПИ-Б.03.02 | 20 ноября 2009 г. | Незначительные исправления базовой спецификации HPI. |
| SAIM-HPI-B.03.02-xTCA | 19 февраля 2010 г. | Значительная переработка спецификации сопоставления AdvancedTCA. Включает сопоставление для платформ MicroTCA, а также AdvancedTCA. |
Спецификации HPI и Спецификация интерфейса приложения (AIS) были разработаны отдельно в рамках SA Forum. Хотя оба они предназначены для обеспечения функциональности, необходимой для самых высоких уровней доступности услуг, их можно использовать независимо друг от друга. Спецификации AIS могут быть реализованы и использованы для промежуточного программного обеспечения кластеризации высокой доступности , которое не реализует управление аппаратной платформой, а спецификация HPI может быть реализована поставщиками платформ и использоваться непосредственно приложениями или программами управления без использования другого промежуточного программного обеспечения управления SA Forum.
Основное пересечение спецификаций AIS и HPI находится в службе управления платформой AIS (PLM). Служба PLM определяется с учетом того, что управление аппаратной платформой будет обеспечиваться посредством реализации спецификации HPI на целевой аппаратной платформе.
HPI-архитектура
[ редактировать ]Спецификация HPI не диктует и не предполагает, какие возможности управления платформой должны присутствовать в аппаратной платформе. Скорее, он обеспечивает общий и последовательный способ моделирования любых имеющихся возможностей и дает возможность пользовательским прикладным программам изучить детали доступных возможностей управления платформой.
HPI объединяет возможности управления аппаратной платформой в набор ресурсов . На каждом Ресурсе размещен набор инструментов управления, которые могут отслеживать и контролировать части аппаратной платформы. Инструменты управления абстрагируют компоненты управления, встроенные в платформу, такие как датчики температуры или напряжения, регистры конфигурации и элементы отображения, или предоставляют интерфейсы для функций управления, таких как обновление встроенного ПО и запуск диагностики. Эти инструменты управления описаны в записях данных ресурсов (RDR), которые доступны пользовательскому приложению, поэтому приложение может обнаружить конфигурацию и возможности каждого ресурса.
Хотя ресурсы HPI представляют собой абстрактные структуры, обычно они используются для моделирования возможностей управления отдельных контроллеров управления на аппаратной платформе. Например, на платформах AdvancedTCA (ATCA) каждый вычислительный блейд обычно включает в себя контроллер управления IPMI (IPMC), отвечающий за задачи управления оборудованием, связанные с этим блейдом. Интерфейс HPI для платформы ATCA обычно включает в себя ресурс для каждого IPMC.
Ресурсы в HPI организованы в домены . Часто реализация HPI реализует только один домен для всех ресурсов, но при необходимости можно разделить систему на несколько доменов. Например, в некоторых модульных системах различные модули могут принадлежать и управляться разными пользователями. Для поддержки этого с помощью HPI все Ресурсы, используемые для управления модулями, принадлежащими конкретному пользователю, могут быть размещены в одном Домене, и этому пользователю предоставляется доступ только к этому Домену.
Пользовательские программы HPI получают доступ к инфраструктуре управления платформой, открывая сеанс с определенным доменом HPI. После установления этого сеанса пользовательская программа может затем выполнять различные вызовы функций HPI для запроса или обновления информации об этом домене или о любых ресурсах, которые в настоящее время являются членами этого домена.
Хотя инструменты управления HPI организованы и управляются доменом и ресурсом, аппаратные компоненты, которыми управляют эти инструменты управления, идентифицируются индивидуально в RDR, связанных с каждым инструментом управления. Физические аппаратные компоненты в HPI называются Entities и идентифицируются с помощью пути к Entity Path. Путь к объекту содержит несколько элементов: первый элемент описывает, где находится аппаратный объект в содержащем объекте, второй элемент описывает, где этот объект находится в более крупном контейнере, и так далее. Например, резервный источник питания для шасси в системе, охватывающей несколько стоек, может иметь путь объекта POWER_SUPPLY.2,SUBRACK.3,RACK.1.
Поскольку каждый инструмент управления связан с определенным путем к сущности, один ресурс HPI может обрабатывать управление платформой для более чем одной сущности. Также возможно управление одной сущностью с помощью нескольких ресурсов HPI. Возможность произвольного сочетания ресурсов HPI и управляемых аппаратных объектов может показаться запутанной, но это важная особенность архитектуры HPI. Это связано с тем, что он позволяет моделировать сложные инфраструктуры управления, которые могут включать в себя как внутриполосные, так и внеполосные элементы управления одного аппаратного объекта, а также системы, в которых контроллер управления на одной части оборудования обеспечивает управление другой частью оборудования.
Инструменты управления
[ редактировать ]Ресурсы HPI могут содержать набор инструментов управления. Каждый инструмент управления моделирует способность отслеживать или контролировать некоторые аспекты аппаратного объекта. Набор RDR в каждом Ресурсе описывает Инструменты управления, размещенные на этом Ресурсе, включая информацию о том, что отслеживается или контролируется.
Существует семь типов инструментов управления, которые можно использовать для моделирования различных возможностей инфраструктуры управления платформой. Первые четыре: датчики, элементы управления, хранилища данных инвентаризации и сторожевые таймеры — это базовые инструменты управления, которые обычно соответствуют возможностям управления дискретной платформой. Остальные три: сигнализаторы, DIMI и FUMI, являются более сложными и инкапсулируют логические функции, которые может обеспечить инфраструктура управления платформой.
Датчики
[ редактировать ]Датчики используются для моделирования возможности мониторинга некоторых аспектов сущности. Датчики HPI созданы по образцу датчиков IPMI.
Датчик HPI сообщает информацию о состоянии отслеживаемого оборудования посредством набора до 15 отдельных битов, называемых состояниями событий. Каждое состояние события может быть подтверждено или отменено индивидуально, а при изменении состояния события могут быть созданы асинхронные события, чтобы сообщить об этом пользователю HPI. Интерпретация каждого состояния события может варьироваться в зависимости от определенной категории датчика (например, порогового значения, производительности, присутствия, серьезности) или может быть уникальной для конкретного датчика. Датчики пороговой категории имеют дополнительные возможности. Пороговые датчики сообщают, когда отслеживаемое значение выше или ниже настраиваемых пороговых значений. Для незначительных, значительных и критических отклонений от нормы в любом направлении можно определить до трех верхних и трех нижних порогов.
Помимо сообщения о состоянии отслеживаемого оборудования через состояния событий, датчик HPI также может сообщать значение, называемое показаниями датчика. Показания датчика отражают текущее значение объекта наблюдения, масштабированное в соответствующих единицах. Показания датчика могут быть целочисленными значениями, значениями с плавающей запятой или блоком произвольных данных длиной до 32 байтов.
Элементы управления
[ редактировать ]Элементы управления используются для моделирования возможности обновления некоторых аспектов сущности. В HPI определено несколько типов элементов управления, которые различаются в зависимости от типа данных, которые можно использовать при их обновлении. Цифровое управление можно включать и выключать, а также включать и выключать импульсно. Аналоговые и дискретные элементы управления могут быть установлены на 32-битное значение. Элементам управления «Поток» и «Текст» можно передавать большие объемы данных для управления миганием светодиода, звуковым сигналом или отображением данных на панели управления. Элементы управления OEM (зависящие от поставщика) могут отправлять блок данных, которые могут использоваться управляемым объектом способами, зависящими от реализации.
Репозитории данных инвентаризации (IDR)
[ редактировать ]Репозитории данных инвентаризации используются для сообщения или установки идентификационной и конфигурационной информации для аппаратных объектов. Обычно такие элементы, как номер модели, серийный номер и данные базовой конфигурации, хранятся в ПЗУ или флэш-памяти аппаратного объекта. Эту информацию можно прочитать, а в некоторых случаях обновить, через репозиторий данных инвентаризации HPI.
Сторожевые таймеры
[ редактировать ]Сторожевые таймеры — это устройства, которые часто реализуются с помощью специального оборудования в системах высокой доступности. Эти устройства настроены на автоматическое прерывание, сброс или включение и выключение объекта через определенный период времени, если он не был предварительно сброшен программно. Целью устройства сторожевого таймера является обеспечение механизма обнаружения неисправностей. Инструмент управления таймером HPI Watchdog предназначен для взаимодействия с аппаратным механизмом такого типа. Он очень близок к сторожевому таймеру IPMI.
оповещатели
[ редактировать ]Сигнализаторы — это логические инструменты управления, которые используются для взаимодействия с функцией отображения сигналов тревоги на аппаратной платформе. Поскольку на разных аппаратных платформах используется широкий спектр аппаратных средств отображения сигналов тревоги, таких как светодиоды , звуковые оповещения, панели текстового отображения и т. д., сложно написать прикладную программу для отображения информации о тревогах независимым от платформы способом. Инструмент управления сигнализатором HPI предоставляет абстрактный интерфейс для передачи информации о сигналах тревоги в реализацию HPI или базовую инфраструктуру управления, которая затем может предпринять соответствующие действия для отображения этой информации на конкретной платформе.
Инструменты управления инициаторами диагностики (DIMI)
[ редактировать ]DIMI — это инструменты логического управления, используемые для координации работы встроенного или программного обеспечения для онлайновой или автономной диагностики на различных аппаратных объектах. DIMI предоставляет пользовательской программе HPI информацию, указывающую, какое влияние на обслуживание будет оказывать выполнение диагностики, и предоставляет общий интерфейс для запуска, остановки и мониторинга выполнения диагностических программ. Эта функция интегрирована с HPI, чтобы помочь стандартизировать автоматическую диагностику и устранение неисправностей, а также обеспечить удобство обслуживания в режиме онлайн.
Инструменты управления обновлением встроенного ПО (FUMI)
[ редактировать ]FUMI — это инструменты логического управления, которые используются для поддержки установки обновлений встроенного ПО на программируемые аппаратные объекты. Для аппаратных объектов, которые включают встроенное ПО, обновляемое на месте, FUMI предоставляет информацию об установленных на данный момент версиях встроенного ПО и предоставляет стандартный интерфейс для идентификации новой версии для загрузки и координации процесса обновления, включая возможное резервное копирование и откат. к предыдущим версиям, если необходимо.
Возможности на уровне ресурсов
[ редактировать ]В дополнение к набору инструментов управления, описанному выше, ресурс HPI может также предоставлять до четырех дополнительных возможностей управления. Эти возможности уровня Ресурса по сути представляют собой специальные Инструменты Управления, из которых может быть не более одного каждого типа, поддерживаемого Ресурсом. Предоставляет ли конкретный Ресурс эти различные возможности и к какому Объекту они применяются, описывается в записи данных, доступной пользователю HPI для Ресурса. В этой записи определен один путь к сущности, поэтому любая из этих возможностей, если она присутствует, будет применяться к одной и той же сущности.
- на уровне ресурса Возможность управления питанием действует как специализированный элемент управления для включения или выключения питания назначенного объекта.
- на уровне ресурса Возможность сброса действует как специализированный элемент управления, вызывающий операцию аппаратного или мягкого сброса на назначенном объекте или, если поддерживается, удержание сигнала сброса в утвержденном состоянии, чтобы предотвратить работу объекта.
- на уровне ресурсов Возможность управления нагрузкой действует как специализированный элемент управления, который взаимодействует с программой начальной загрузки назначенного объекта для определения того, какая операционная система или другое программное обеспечение должно быть загружено при выполнении операции начальной загрузки.
- на уровне ресурса Возможность управления конфигурацией предоставляет пользователю HPI возможность указать ресурсу на сохранение или восстановление информации о конфигурации, такой как пороговые уровни датчиков, на постоянный носитель данных или с него.
Доменные функции
[ редактировать ]
Пользовательские программы получают доступ к управлению платформой на основе HPI, открывая сеанс с доменом. Пользовательская программа может открыть сеанс с определенным доменом, указав идентификатор домена , или, что чаще, она может открыть сеанс с доменом по умолчанию. После установления сеанса пользовательская программа может получить доступ к различным функциям уровня домена или к любому из ресурсов, которые в данный момент перечислены как члены домена. Поскольку сеанс разрешает доступ только к ресурсам, которые в настоящее время являются членами домена, контроль доступа пользователей может быть реализован с помощью реализации HPI путем ограничения того, какие ресурсы являются членами каждого домена, а также ограничения того, каким пользователям разрешено устанавливать сеансы с этими доменами.
Одной из наиболее важных функций домена является предоставление информации через таблицу присутствия ресурсов (RPT) обо всех ресурсах, которые являются членами домена. Вторая таблица, справочная таблица доменов (DRT), предоставляет информацию о других доменах HPI, доступ к которым можно получить, открыв дополнительные сеансы.
Интерфейс HPI предоставляет три службы на уровне домена, которые пользовательская программа может использовать, чтобы быть в курсе исключительных условий на аппаратной платформе. Наиболее важным из них является Служба управления событиями . Пользователь может запросить пересылку событий из Домена в любом открытом сеансе. Когда важные события происходят с аппаратными объектами, контролируемыми любым из ресурсов, которые являются членами домена, сообщения о событиях генерируются и ставятся в очередь для всех открытых сеансов, которые сделали такой запрос. Благодаря этому механизму пользовательские программы могут получать информацию об изменениях в управляемой платформе без необходимости постоянного опроса статуса. События также могут храниться в журнале событий домена и извлекаться позднее для исторического анализа. Наконец, таблица сигналов тревоги домена доступна пользовательской программе и сообщает о текущих состояниях тревоги, присутствующих в любом из ресурсов, которые являются членами домена.
Управление горячей заменой
[ редактировать ]Ключевой особенностью спецификации HPI является способ обработки динамической реконфигурации или действий «горячей» замены на управляемой платформе. Под горячей заменой подразумевается возможность добавлять или удалять аппаратные компоненты на работающей платформе. HPI называет аппаратный объект, который можно заменять в горячем режиме, как модуль, заменяемый на месте, или FRU. Часто, особенно в системных архитектурах, таких как AdvancedTCA, FRU включают в себя собственные контроллеры управления платформой. Таким образом, горячая замена FRU может одновременно изменить как набор управляемых аппаратных объектов, так и инфраструктуру, доступную для этого управления.
Подход HPI к управлению горячей заменой отражает это путем моделирования добавления или удаления аппаратного объекта путем добавления или удаления ресурса в домене. Если FRU не включает в себя собственный контроллер управления, ресурсу могут не быть назначены какие-либо возможности управления, но он все равно используется для сообщения о присутствии FRU в системе. С другой стороны, если FRU включает в себя контроллер управления, то Ресурс, добавляемый в Домен, может содержать новые Инструменты Управления или другие возможности и делать их доступными для пользователя HPI.
Ресурс, связанный с FRU, всегда будет находиться в одном из пяти состояний горячей замены, которые доступны для чтения пользователем HPI: нет, неактивен, ожидается вставка, активен, ожидается извлечение . Ресурс никогда не сообщает о состоянии «Нет присутствия» , поскольку, когда FRU отсутствует в системе, Ресурс не должен существовать как член какого-либо домена. Остальные четыре состояния применимы к FRU, физически присутствующим в системе, независимо от того, полностью ли они работоспособны. Когда ресурс переходит в новое состояние «горячей замены», событие HPI отправляется пользовательским программам, которые запросили уведомления о событиях.
Ресурсы HPI, моделирующие FRU с возможностью горячей замены, могут быть настроены для поддержки неуправляемой горячей замены или управляемой горячей замены . Ресурс, который поддерживает неуправляемую горячую замену, сообщит о своем текущем состоянии горячей замены, но пользователь не имеет контроля над операциями горячей замены FRU. Если ресурс поддерживает управляемую горячую замену, тогда пользовательская программа может взаимодействовать с реализацией HPI и базовой инфраструктурой управления платформой для координации действий, необходимых для интеграции вновь добавленных FRU или деактивации FRU, удаляемых из системы.
Обратная совместимость
[ редактировать ]Целью SA Forum является обеспечение обратной совместимости новых версий его спецификаций с предыдущими версиями. В случае со спецификацией HPI это означает, что пользовательские программы, написанные для работы с реализациями HPI определенной версии, должны продолжать работать без изменений с реализациями HPI, поддерживающими более позднюю версию спецификации. Эта цель была достигнута с помощью спецификаций HPI, опубликованных после спецификации SAI-HPI-B.01.01. Спецификации HPI серии «B» не имеют обратной совместимости со спецификацией SAI-HPI-A.01.01.
Для достижения обратной совместимости спецификаций HPI используется несколько стратегий:
а) Функции, определенные в более ранних версиях спецификации HPI, включены в более поздние версии без изменения прототипа функции. Устаревшие функции сохранены, но в спецификацию включен совет о том, что их не следует использовать новыми пользовательскими программами.
б) Новые функции могут быть добавлены в новые версии спецификации HPI, если их использование не требуется существующими программами.
в) Различные перечисления, которые передают такие данные, как типы аппаратных объектов, типы датчиков и т. д., объявлены в спецификации HPI как открытые. Список кодов возврата ошибок, которые могут возвращать функции HPI, также объявлен открытым. Новые версии спецификации HPI не удаляют и не изменяют существующие перечисляемые значения, но могут добавлять новые значения в открытое перечисление. Пользовательские программы должны принимать значения, которые в данный момент не определены, и рассматривать их как «действительные, но неопределенные». Таким образом, программа может продолжать работать, когда она используется с реализацией, построенной на более новой версии спецификации HPI, которая могла определять новые значения для перечисления.
г) Структуры данных, передаваемые от функций HPI пользователю, не могут увеличиваться в длине в новых версиях спецификации HPI или изменять формат данных, который был определен в предыдущих версиях. Однако ранее неопределенные биты в битовых полях могут быть определены в новых версиях спецификации HPI, а неиспользуемое пространство в объединениях может использоваться до тех пор, пока программы, которые не распознают новые биты или новое использование неиспользуемого пространства, будут продолжать работать. правильно.
e) Структуры данных, передаваемые в функции HPI от пользователя, могут измениться в новых версиях спецификации HPI, при условии, что изменения вносятся таким образом, что существующая программа, передающая ранее определенную структуру, будет продолжать работать правильно.
Спецификация сопоставления HPI и xTCA
[ редактировать ]Поскольку HPI широко используется в системах AdvancedTCA, в январе 2006 года SA Forum опубликовал спецификацию сопоставления под названием SAIM-HPI-B.01.01-ATCA. Целью этой спецификации является предоставление рекомендаций для разработчиков интерфейсов управления HPI по рекомендуемому способу. смоделировать эту сложную системную архитектуру с помощью HPI. В феврале 2010 года была опубликована новая спецификация сопоставления SAIM-HPI-B.03.02-xTCA, которая пересматривает это сопоставление и распространяет его на системы MicroTCA.
Спецификация сопоставления HPI и xTCA определяет способ представления управляемости платформы xTCA в HPI в одном домене HPI. Указывается именование Entity Path для компонентов системы xTCA, а также определяются инструменты управления, которые отражают информацию управления платформой и функции управления, доступные на этих платформах.
Спецификация сопоставления также определяет ресурсы для шасси xTCA, менеджера полки, менеджера несущей и других FRU. В исходной версии спецификации ресурсы были определены и необходимы для всех «слотов» в корпусе или на несущих платах, которые потенциально могут размещать FRU. В обновлении, опубликованном в 2010 году, эти ресурсы слотов стали необязательными.
Спецификация сопоставления HPI и xTCA предназначена для двух аудиторий. В первую входят разработчики платформ, которые хотят включить интерфейс HPI в платформу AdvancedTCA или MicroTCA. Спецификация предоставляет шаблон для моделирования систем.
Вторая аудитория состоит из пользователей HPI, которые хотят создавать портативные приложения или промежуточные программы для нескольких платформ AdvancedTCA или MicroTCA. Однако пользователям HPI, которые хотят предоставить переносимые программы как для xTCA, так и для других архитектур аппаратных платформ, не обязательно ссылаться на спецификацию сопоставления HPI и xTCA. Это связано с тем, что реализации HPI, соответствующие спецификации преобразования HPI в xTCA, будут предоставлять базовые возможности управления платформой таким образом, чтобы их можно было обнаружить и использовать через стандартный интерфейс HPI. Некоторые возможности управления платформой, уникальные для платформ xTCA, невозможно использовать без ссылки на спецификацию сопоставления, но они могут быть разумно проигнорированы большинством пользовательских приложений HPI общего назначения.
реализации HPI
[ редактировать ]Было создано несколько широко распространенных реализаций спецификации HPI, в первую очередь поставщиками платформ, которые создают компьютерные системы AdvancedTCA или другие компьютерные платформы высокой доступности. В большинстве реализаций сам прикладной программный интерфейс HPI предоставляется через библиотеку, связанную с прикладными программами. Этот библиотечный модуль обычно взаимодействует с сервером HPI, работающим как процесс-демон , который выполняет функции доменов и ресурсов HPI, взаимодействуя при необходимости с базовой инфраструктурой управления.
Некоторые реализации HPI основаны на с открытым исходным кодом реализации спецификации HPI , называемой OpenHPI . OpenHPI также следует общему дизайну, показанному на рисунке 6, в том смысле, что он включает библиотечный модуль, который связывается с прикладными программами, и модуль-демон, с которым взаимодействуют библиотечные модули. Процесс демона OpenHPI предназначен для интеграции с одним или несколькими подключаемыми модулями , которые обеспечивают нисходящую связь с различными инфраструктурами управления платформой.
Реестр реализации форума SA [ постоянная мертвая ссылка ] это процесс, который позволяет регистрировать реализации спецификаций SA Forum и делать их общедоступными. Членство не требуется для регистрации реализаций. Реализации, которые были успешно зарегистрированы, могут называться «Зарегистрированы на форуме доступности услуг».