Интерфейс аппаратной платформы - Википедия - Hardware Platform Interface
 | Эта статья не цитировать любой источники. (Март 2017 г.) (Узнайте, как и когда удалить этот шаблон сообщения) |
В Интерфейс аппаратной платформы (HPI) - открытая спецификация, определяющая интерфейс прикладного программирования (API) для управления платформой компьютерных систем. API поддерживает такие задачи, как считывание датчиков температуры или напряжения, встроенных в процессор, настройку регистров оборудования, доступ к информации инвентаризации системы, такой как номера моделей и серийные номера, и выполнение более сложных действий, таких как обновление прошивки системы или диагностика сбоев системы.
HPI разработан для использования с отказоустойчивой и модульный высокая доступность компьютерные системы, которые обычно включают в себя функции автоматического обнаружения неисправностей и аппаратное резервирование, чтобы они могли обеспечивать постоянную доступность услуг. Дополнительные функции, характерные для аппаратных платформ, используемых для приложений с высокой доступностью, включают возможность оперативного обслуживания и обновления с помощью модулей с возможностью горячей замены.
Спецификация HPI разработана и опубликована Форум доступности услуг (SA Forum) и сделана в свободном доступе для общественности.
История
Основным мотивом для разработки спецификации HPI было появление модульных компьютерных аппаратных платформ и готовых коммерческих (COTS) систем в конце 1990-х - начале 2000-х годов. Это включало CompactPCI платформы, а затем AdvancedTCA и MicroTCA (xTCA) платформы, стандартизированные Группа производителей промышленных компьютеров PCI (PICMG). Эти платформы включают инфраструктуры управления оборудованием на основе Интеллектуальный интерфейс управления платформой (IPMI). Одновременно с этим основные поставщики Enterprise, такие как HP и IBM, также разрабатывали модульные и блейд-системы.
Потребность в спецификации HPI была впервые выявлена отраслевой группой под названием «Форум высокой доступности», которая собиралась в течение нескольких месяцев в 2000 году для обсуждения вопросов, связанных с построением компьютерных систем высокой доступности с использованием открытая архитектура технологии. Эта группа опубликовала официальный документ, «Предоставление решений высокой доступности с открытой архитектурой» в начале 2001 года. В результате этой работы, Корпорация Intel начал проект по определению стандартного API управления аппаратной платформой под названием Универсальный интерфейс управления шасси (UCMI). Эта работа была перенесена в недавно сформированный консорциум SA Forum и опубликована как Hardware Platform Interface в октябре 2002 года. Исходная спецификация HPI, SAI-HPI-A.01.01, была первой спецификацией, опубликованной SA Forum.
Начиная с 2002 г. было опубликовано несколько обновлений спецификации HPI. Кроме того, спецификации для доступа к реализации HPI через Простой протокол управления сетью (SNMP) и разработаны спецификации, описывающие использование HPI на платформах AdvancedTCA и MicroTCA. В таблице 1 перечислены все спецификации, опубликованные SA Forum в семействе HPI.
| Этикетка со спецификацией | Дата публикации | Примечания |
|---|---|---|
| SAI-HPI-A.01.01 | 7 октября 2002 г. | Оригинальная спецификация HPI |
| SAI-HPI-B.01.01 | 3 мая 2004 г. | Существенное изменение базовой спецификации HPI. Исправлены проблемы с реализацией и удобством использования в исходной спецификации |
| SAI-HPI-SNMP-B.01.01 | 3 мая 2004 г. | SNMP MIB для доступа к реализациям HPI |
| SAI-HPI-B.02.01 | 18 января 2006 г. | Незначительное изменение базовой спецификации HPI. Добавлены возможности FUMI, DIMI и управления нагрузкой. |
| SAIM-HPI-B.01.01-ATCA | 18 января 2006 г. | Спецификация сопоставления HPI с AdvancedTCA |
| SAI-HPI-B.03.01 | 21 октября 2008 г. | Незначительное изменение базовой спецификации HPI. Улучшения FUMI; некоторые новые функции API |
| SAI-HPI-B.03.02 | 20 ноября 2009 г. | Незначительные исправления в базовой спецификации HPI |
| SAIM-HPI-B.03.02-xTCA | 19 февраля 2010 г. | Существенная переработка спецификации отображения AdvancedTCA. Включает отображение для платформ MicroTCA, а также AdvancedTCA. |
Спецификации HPI и Спецификация интерфейса приложений (AIS) были разработаны отдельно в рамках форума SA. Хотя оба они предназначены для реализации функций, необходимых для наивысшего уровня доступности услуг, их можно использовать независимо друг от друга. Спецификации 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 называются Сущности и идентифицируются с помощью пути к сущности. An Путь к сущности содержит несколько элементов, причем первый элемент описывает, где находится аппаратная сущность в содержащей сущности, второй элемент описывает, где эта сущность находится в более крупном контейнере, и так далее. Например, резервный источник питания для шасси в системе, охватывающей несколько стоек, может иметь путь объекта 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.
Сторожевые таймеры
Сторожевые таймеры - это устройства, которые часто реализуются с помощью специального оборудования в системах высокой доступности. Эти устройства настроены на автоматическое прерывание, сброс или включение и выключение Entity через определенный период времени, если он не был сначала перезагружен программно. Цель сторожевой таймер устройство должно обеспечивать механизм обнаружения неисправностей. Инструмент управления сторожевым таймером HPI разработан для взаимодействия с подобным аппаратным механизмом. Он очень похож на сторожевой таймер IPMI.
Оповещатели
Оповещатели - это инструменты логического управления, которые используются для взаимодействия с функцией отображения аварийных сигналов на аппаратной платформе. Поскольку широкий спектр оборудования для отображения сигналов тревоги, например Светодиоды, звуковые оповещения, текстовые панели отображения и т. д. используются на различных аппаратных платформах, поэтому сложно написать прикладную программу для отображения информации о сигналах тревоги независимым от платформы способом. Инструмент управления сигнализатором HPI предоставляет абстрактный интерфейс для передачи информации об аварийных сигналах реализации HPI или базовой инфраструктуре управления, которая затем может предпринять соответствующие действия для отображения этой информации на конкретной платформе.
Инструменты управления диагностическим инициатором (DIMI)
DIMI - это инструменты логического управления, используемые для координации работы встроенного или автономного диагностического микропрограммного обеспечения или программного обеспечения на различных аппаратных объектах. DIMI предоставляет информацию для пользовательской программы HPI, которая указывает, какое влияние на обслуживание окажет запущенная диагностика, и предоставляет общий интерфейс для запуска, остановки и мониторинга выполнения диагностических программ. Эта функция интегрирована с HPI, чтобы помочь стандартизировать автоматическую диагностику и устранение неисправностей, а также обеспечить возможность обслуживания в режиме онлайн.
Инструменты управления обновлением прошивки (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 используется несколько стратегий:
a) Функции, определенные в более ранних версиях спецификации HPI, включены в более поздние версии без изменений в прототипе функции. Устаревшие функции сохраняются, но в спецификацию включен совет, что они не должны использоваться новыми пользовательскими программами.
б) Новые функции могут быть добавлены в новые версии спецификации HPI, если их использование не требуется существующими программами.
c) Различные перечисления, которые сообщают такие данные, как типы аппаратных объектов, типы датчиков и т. д., объявлены в спецификации HPI как открытые. Список кодов возврата ошибок, которые могут возвращать функции HPI, также объявлен как открытый. Новые версии спецификации HPI не удаляют и не изменяют какие-либо существующие перечисляемые значения, но могут добавлять новые значения в открытое перечисление. Пользовательские программы должны принимать значения, которые в настоящее время не определены, и рассматривать их как «действительные, но не определенные». Таким образом, программа может продолжать работать, когда она используется с реализацией, построенной на более новой версии спецификации HPI, которая может определять новые значения для перечисления.
d) Структуры данных, передаваемые из функций HPI пользователю, не могут увеличиваться в длине в новых версиях спецификации HPI или изменять формат данных, который был определен в предыдущих версиях. Однако ранее неопределенные биты в битовых полях могут быть определены в новых версиях спецификации HPI, и неиспользуемое пространство в объединениях может использоваться, если программы, которые не распознают новые биты или новое использование неиспользуемого пространства, будут продолжать работать. правильно.
e) Структуры данных, переданные в функции HPI от пользователя, могут измениться в новых версиях спецификации HPI, если изменение сделано таким образом, что существующая программа, передающая ранее определенную структуру, будет продолжать работать правильно.
Спецификация сопоставления HPI to xTCA
Поскольку HPI широко используется в системах AdvancedTCA, SA Forum опубликовал в январе 2006 года спецификацию сопоставления, обозначенную SAIM-HPI-B.01.01-ATCA. Цель этой спецификации - предоставить рекомендации для разработчиков интерфейсов управления HPI по рекомендуемому пути. для моделирования этой сложной системной архитектуры с помощью HPI. В феврале 2010 года была опубликована новая спецификация сопоставления, SAIM-HPI-B.03.02-xTCA, которая изменяет это сопоставление и распространяет его на системы MicroTCA.
Спецификация сопоставления HPI с xTCA определяет способ представления управляемости платформы xTCA в HPI в одном домене HPI. Указывается имя пути к объекту для компонентов системы xTCA и определены инструменты управления, которые отражают информацию об управлении платформой и функции контроля, доступные на этих платформах.
Спецификация сопоставления также определяет ресурсы для шасси xTCA, диспетчера полок, диспетчера оператора связи и других FRU. В исходной версии спецификации Ресурсы были определены и требуются для всех «Слотов» в шасси или на несущих картах, которые потенциально могут содержать FRU. В обновлении, опубликованном в 2010 году, эти ресурсы слота стали необязательными.
Спецификация сопоставления HPI to 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 Forum[постоянная мертвая ссылка ] это процесс, позволяющий регистрировать и делать общедоступными реализации спецификаций SA Forum. Для регистрации реализаций членство не требуется. Реализации, которые были успешно зарегистрированы, могут упоминаться как «Зарегистрированные на форуме доступности услуг».